Authorization at token issuance
SecureAuth Connect makes the authorization decision when a token is issued, not inside each application at request time. Applications verify the token, read its claims, and act. Policy changes take effect on the next token issued, and tokens carry only the scopes and permissions that were actually granted.
Why move authorization to the token
- Decisions live in one place. Rules attach to scopes, clients, and APIs in the authorization server instead of being scattered across application code.
- Applications don't carry access logic. Services verify the token and read claims. Rule changes don't require code changes in each application.
- Tokens stay narrow. A token carries only the scopes and permissions the user actually needs. If a token leaks, the damage is bounded by what was authorized.
- Recovery stays in the authorization flow. When a decision requires MFA, consent, or a step-up, it runs before the token is issued rather than surfacing as a 403 inside an application.
Runtime vs token-time authorization
| Aspect | Runtime authorization | Token-time authorization |
|---|---|---|
| Where the decision is made | Inside each application | In the authorization server |
| Where rules live | Application code, or a central service called per request | Policies attached to scopes, clients, and APIs |
| What the application does | Translates roles and scopes into internal checks | Verifies the token and reads claims |
| How policy changes propagate | Code changes and coordinated releases | Applied to the next token issued |
| Token contents | Broad: role and scope lists | Narrow: what was explicitly authorized |
| Recovery flows (MFA, step-up, consent) | Surface as errors from the application | Handled in the authorization flow |
| Blast radius of a leaked token | What the user could do | What was explicitly authorized |
Four mechanisms for token-time authorization
| Mechanism | Granularity | Use case |
|---|---|---|
| Access token scopes | Coarse | Govern which application can request access to which service. Attach policies to scopes to decide who can grant, request, or consent. |
| Dynamic scopes | Per-resource | Include a resource identifier inside the scope itself, for example account.list.05542. The token authorizes a specific object, not a category. |
| Scope-based policies | Conditional grant | Attach grant rules to scopes for human users, machine users, third-party developers, and dynamically registered clients. |
| Rich Authorization Requests (RAR) | Transaction-specific | Specify exact details such as a payment amount, a specific medical record, or files being shared. Use when scopes cannot express what the user must see and approve. |