Roles, permissions and enforcement

Access to an application is decided by group membership. Every OIDC client and every SAML service provider has a set of attached groups, and a person may sign in only if they belong to at least one of them. The gate is default-closed in the strict sense: an application with no attached groups admits nobody, so a half-configured application fails safe instead of standing open to everyone.

What that person may then do inside your API is a separate model. A resource server represents one of your APIs and owns an immutable audience string, a permission is an action string belonging to one resource server, a role bundles permissions, and a role reaches a user either directly or through a group.

A third, independent system decides which profile data reaches a token: scopes over a typed attribute schema. Passing the access gate says nothing about which permissions you hold, and holding a permission says nothing about which profile claims are released.

By default an access token is audienced to your own client and carries no permissions at all. To get a token for one of your APIs, the application requests that resource server's audience, using either the audience parameter or the resource parameter of RFC 8707; if both arrive, the resource form wins.

Two gates apply, and both fail closed. Your application must hold a grant to request that audience at all, and an unknown API is indistinguishable from an ungranted one. The token endpoint is the canonical enforcement point, because the audience rides through the authorize request as a forgeable query parameter and is re-validated at the exchange.

Whether a permissions claim appears at all depends on the resource server's enforcement flag. Turning it off gives you correctly audienced tokens with no permissions, which is what you want when your API does its own authorization but still needs to confirm that a token was meant for it.

SenseCrypt emits permissions and never enforces them. Your API verifies the token against the tenant's key set by kid, checks that the audience equals its own audience string, and authorizes each request against the permissions array. That is the whole contract, and it is the same contract any standards identity provider offers.

There are exactly two places SenseCrypt enforces authorization itself, and naming them stops anyone assuming a third. The first is the sign-in gate. The second is the admin console and Management API, which run a separate capability model of their own, unrelated to the roles you hand your end users, with its own tables and its own enforcement.

Reserved protocol claims are protected in both directions. A tenant administrator cannot define a custom attribute called sub, or scope, or permissions and have it overwrite a server-minted claim: reserved keys are rejected and stripped at the sink. What appears in the protocol claims came from SenseCrypt, not from tenant configuration.

You need this model only if you want SenseCrypt to tell your API what a person may do. If you only need to know who they are and which applications they may reach, the access gate is enough on its own and resource servers can wait until there is a reason for them.

When you do want it, the order is short: create the resource server with its audience, define the permissions your API understands, bundle them into roles, assign roles to people or to groups, then grant your application the right to request that audience. Every step is a console action or a Management API call, so the whole model can live in your infrastructure code.

Every definition in this model is scoped to a single tenant. The word administrator can therefore carry a completely different set of permissions in one customer's tenant than in the next, and no operator in either one can see or alter the other's version of it.