Implement Fine-Grained Authorization for Users, Applications, and Agents #2210
Description
Description:
Introduce a fine-grained authorization model that goes beyond role-based access control. Administrators should be able to define resources, assign granular permission levels to those resources, and authorize any entity type (user, application, or agent) to access them. Authorized permissions should be requestable during OAuth2 token flows and included in issued tokens.
Scope
1. Resource and Permission Definition
Define protected resources and their associated permission levels through the management plane. For example, a resource documents might have permissions like read, write, delete, share. This model should be flexible enough to represent APIs, data objects, features, or any logical resource.
2. Entity-to-Resource Authorization
Authorize any entity — user, application, or agent — to specific permissions on specific resources. This creates a direct binding between an entity and what it is allowed to do on a given resource, independent of roles.
3. Request Permissions in Token Flows
Entities should be able to request specific resource permissions during token requests. Supported all applicable grant types, including: Authorization Code, Client Credentials,Token Exchange (RFC 8693), JWT Bearer Authorization Grant (RFC 7523)
- Support Resource indicators (RFC 8707) for specifying the target resource — tracked separately in [#2197](Support RFC 8707 Resource Indicators for OAuth 2.0 #2197).
4. Authorization Evaluation
When a token is requested with specific permissions, the IdP must evaluate whether the requesting entity is authorized for those permissions on the target resource.
- Server-side evaluation: The IdP evaluates authorization internally against the configured entity-resource-permission bindings.
- External AuthZ integration (AuthZen): Delegate evaluation to an external authorization server over the AuthZen protocol. Not in current scope — see Integrate External Authorization Evaluation for token issuarance via AuthZen Protocol #2209.
5. Issue Tokens with Authorized Permissions
After a successful evaluation, the issued token must contain only the permissions the entity is authorized for. If the entity requests permissions it is not entitled to, the token should either be issued with the reduced permissions. The token claims should be structured so that resource servers can enforce access decisions locally.
Acceptance Criteria
- Admin can define resources and their permission levels
- Admin can assign specific resource permissions to users, applications, and agents
- Entities can request resource permissions during supported token flows
- IdP evaluates authorization and issues tokens containing only permitted permissions
- Requests for unauthorized permissions are handled gracefully (reduced grant or denial)
- Token claims are structured for downstream enforcement by resource servers
- All authorization evaluation decisions are logged for audit
Related Issues
- [#2197](Support RFC 8707 Resource Indicators for OAuth 2.0 #2197) — RFC 8707 Resource Indicators support
- TBD — External authorization evaluation via AuthZen (separate issue to be created and linked)
References
- [RFC 8707 — Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707)
- [RFC 8693 — OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)
- [RFC 7523 — JWT Bearer Profile](https://datatracker.ietf.org/doc/html/rfc7523)
- [AuthZen — OpenID AuthZen Interop Profile](https://openid.net/specs/authzen-interop-1_0.html)