[Design Discussion] RFC 8707 Resource Indicators Support #2198
Replies: 4 comments
-
Current Blockers1. Single-value 2. Permission string collisions across Resource Servers Example: Both produce 3. Resource Server identifier is not a URI |
Beta Was this translation helpful? Give feedback.
-
Analysis of Suggested SolutionsSolution 1: Multi-audience
|
Beta Was this translation helpful? Give feedback.
-
|
Below will be the final approach. It's refine of the above. Main focus is not to use and URI attribute directly Refined Approach:
|
Beta Was this translation helpful? Give feedback.
-
Open Questions from ImplementationA few decisions that came up during implementation and need to be finalized: 1. 2. Default 3. Behavior when the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Related Feature Issue
#2197
Problem Summary
Thunder cannot audience-restrict access tokens to specific Resource Servers. RFC 8707 introduces a
resourceparameter that lets clients indicate the target service, enabling the authorization server to mint tokens with appropriateaudclaims. The key design question is whether this parameter maps to Thunder's "Resource Server" or its sub-level "Resource" entity.High-Level Approach
resourceparameter support to the authorization and token endpoints.resource→ Thunder's Resource Server entity (rationale below in Alternatives).identifierfield to the Resource Server model for administrators to set (e.g.,https://api.example.com/booking/).audin issued JWTs to the Resource Server URI; downscope permissions to only those relevant to the target Resource Server.invalid_targeterror for unknown or malformed resource values.refresh_tokengrants, allow narrowing to a subset of originally authorized resources; refresh token stays bound to the full grant.Architecture Overview
Authorization Endpoint: Accepts
resourceparameter (one or more absolute URIs), resolves against registered Resource Server identifiers, binds resource context to the authorization code grant.Token Endpoint: Accepts
resourcefor all grant types. Issues access tokens withaudset to resolved Resource Server URI(s). Downscopes token permissions to the target Resource Server.Resource Server Entity: New
identifierfield (absolute URI) added to the model. This is what clients pass asresourceand what appears asaudin JWTs.Relationship to Existing Permission Model:
resourceanswers where (audience); scopes/permissions answer what (access rights). These remain orthogonal. The permission hierarchy (Resource Server → Resources → Actions) is unchanged.Security Considerations
invalid_target.Impacted Areas
audclaim)Alternatives Considered
Alternative 1: Map
resourceto Thunder's sub-level Resourcecreate,listin the Booking API example) have no Resource entity to map to. Forces awkward workarounds synthetic root resources, disallowing direct Resource Server actions, or dual authorization paths.https://cal.example.com/,https://apps.example.com/scim/), not sub-resource paths.Alternative 2: Encode resource identity in scope values
Questions for Community Input
identifierbe required or optional? Behavior when a client sendsresourcebut the target has no URI?,resource_uri,audience_uri`?Beta Was this translation helpful? Give feedback.
All reactions