Integrate External Authorization Evaluation for token issuarance via AuthZen Protocol #2209
Description
Who Are We Solving This For?
- Enterprises with existing centralized policy engines (e.g., OPA, Cedar, Topaz) who want their IdP to defer authorization decisions to an external Policy Decision Point (PDP) rather than maintaining duplicate policy logic.
- Platform teams adopting decoupled authorization architectures where the IdP handles authentication and token issuance but a dedicated authorization service owns the policy evaluation.
- Organizations with complex, context-aware policies (e.g., time-of-day, risk score, request context, relationship-based rules) that go beyond what a built-in permission model can express.
Why Should We Solve This?
The fine-grained authorization model (see linked parent issue) provides a solid built-in evaluation engine. However, many enterprises already invest in dedicated authorization infrastructure and do not want authorization logic fragmented across systems. AuthZen is emerging as the interoperability standard for authorization evaluation, backed by the OpenID Foundation. Supporting it positions Thunder as a composable IdP that can participate in a best-of-breed security stack rather than requiring teams to consolidate all policy logic inside the IdP.
Implementation is not a priority for the immediate milestones, but should be designed as an extension point so the built-in evaluation engine and external evaluation via AuthZen are interchangeable per resource or policy.
Proposed Solution
1. AuthZen Evaluation Endpoint Integration
Implement an outbound integration to an external PDP compliant with the AuthZen Access Evaluation API. When a token request requires authorization evaluation, the IdP constructs an AuthZen evaluation request containing the subject (user/application/agent), the resource, the action (requested permissions), and optional context, and sends it to the configured PDP.
2. Evaluation Request Mapping
Map Thunder's internal authorization model to the AuthZen request format:
- Subject: Entity identifier and type (user, application, agent) plus relevant attributes
- Resource: Resource identifier from Thunder's resource registry
- Action: Requested permissions
- Context: Optional additional context (e.g., grant type, client metadata, IP, risk signals)
3. Response Handling
Process the PDP's evaluation response (permit/deny) and apply it to token issuance:
- If permitted, include the authorized permissions in the issued token
- If denied, reject the token request or reduce the granted permissions (configurable)
- Handle PDP errors and timeouts gracefully with configurable fallback behavior (fail-open or fail-closed)
4. Admin Configuration
- Admin can register one or more external PDP endpoints
- Admin can configure which resources or entity types route evaluation to the external PDP vs. the built-in engine
- Admin can configure timeout, retry, and fallback policies per PDP
- Admin can enable/disable external evaluation globally or per resource
5. Auditability
Log all external evaluation requests and responses, including the PDP endpoint called, the evaluation input, the decision returned, and latency. This ensures full traceability even when authorization decisions are made externally.
Acceptance Criteria
- IdP can call an AuthZen-compliant PDP for authorization evaluation during token issuance
- Evaluation requests correctly map entity, resource, action, and context to the AuthZen format
- Permit/deny responses from the PDP are reflected in token issuance decisions
- PDP errors and timeouts are handled with configurable fallback behavior
- Admin can route specific resources or entity types to external vs. built-in evaluation
- All external evaluation events are logged with full request/response context
Related Issues
- Parent: Implement Fine-Grained Authorization for Users, Applications, and Agents
- [#2197](Support RFC 8707 Resource Indicators for OAuth 2.0 #2197) — RFC 8707 Resource Indicators support
References