Keep role grants within the caller’s authority
People can delegate responsibilities they hold without being able to create a more powerful account or integration. Wildo checks requested roles when members and machine credentials receive their authority.
Inherited responsibilities count too: an administrator can grant the member role they already include, while a higher owner role remains outside their authority.
Example — An administrator creates an integration
An organization administrator gives a service the member role it needs. Asking for the owner role is refused before the credential is created.
For engineers
The OAuth-client mint handler checks the caller-authored roles before generating secret material. The core create still performs persistence, and the postfix returns the plaintext secret once:
This implementation excerpt from oauth-clients.custom-impl.backend.service.ts shows the decision in context; explanatory source comments are omitted.
export function buildOAuthClientMintHandlers(scope: ApiKeyScope, roleHierarchyResolver: RoleHierarchyResolver): OAuthClientImplHandlers {
return {
prefixCoreOperations: async (_id, input, executionContext, _operationPath, utils) => {
assertRequestedRolesWithinCallerCeiling(executionContext, (input as { roles?: string[] }).roles, utils.errorBuilder, roleHierarchyResolver);
const { plainSecret, secretPrefix, hashedSecret } = generateOAuthClientSecretMaterial(scope);
PLAINTEXT_SECRET_BY_EC.set(executionContext, plainSecret);
return { ...(input as Record<string, unknown>), secretPrefix, hashedSecret };
},
postfixCoreOperations: async (_id, createdClient, executionContext, _operationPath, _utils) => {
if (!createdClient || typeof createdClient !== 'object') return createdClient;
const plainSecret = PLAINTEXT_SECRET_BY_EC.get(executionContext);
PLAINTEXT_SECRET_BY_EC.delete(executionContext);
if (!plainSecret) return createdClient;
return { ...(createdClient as Record<string, unknown>), plainSecret };
},
};
}
Extend the same check to application resources
The framework wires assertRequestedRolesWithinCallerCeiling into its membership, unit-assignment, application-role and credential creation paths. If an application introduces another resource whose caller-settable roles confer authority, call the assertion from its create and roles-changing update handlers too.
Use createRoleHierarchyResolver to read the live, application-configured hierarchy. Pass the roles as the caller authored them, before adding policy defaults. Otherwise a default role supplied by the framework would be mistaken for a privilege the person asked to grant.
Keep scope and privilege checks separate
The ceiling compares effective roles across the caller’s organization-wide memberships. A unit-scoped administrator role does not become organization-wide grant authority. The surrounding operation authorization answers where the caller may write; this check answers how high they may grant.
Internally initiated provisioning and an application-scoped super-administrator are deliberate exceptions. Credential roles are fixed at creation: rotation changes secret material, not the roles the credential carries.