Hi I’d appreciate your input in just one word or one sentence on a few points regarding OAuth 2.0 Token Exchange integration—I’ll figure out the rest on my own.
*Use Case:* Token Exchange Delegation Flow Alice encounters an issue with the Acme Client Application and wants to delegate authorization to the Administrator of the Acme Client Application to reproduce the issue. *Questions:* 1. How does the Subject Resource Owner know the `sub` of the Actor Resource Owner to delegate to a specific Actor? - For example, if the Acme Client uses a generic Actor Resource Owner `sub` like `ad...@acme.com`, and the Subject Resource Owner clicks "Give permission to Admin," how would an agent (e.g., Bob) log in as ` ad...@acme.com`? Sharing the credentials of `ad...@acme.com` with all agents is a security risk. 2. On what basis does the Authorization Server add the `may_act` claim as the Actor Resource Owner in the Subject's access token? - One possible solution is for the Client to use the `claims.user_info.may_act` parameter in the Authorization Request with `essential=true` when making the Authorization Request on behalf of the Subject Resource Owner. The Authorization Server must support the `may_act` claim for this to work. 3. What triggers the Client to request the `actor_token` with the Actor User's consent? - A possible solution is for the Actor Resource Owner to log in to the Client with their credentials. There could then be a "Reproduce the issue" for the Actor, and upon clicking it, the Client uses the Authorization Code flow to obtain the `actor_token`. The Client can then retrieve the `subject_token` from the database and make the Token Exchange request using both tokens. 4. Assuming the `subject_token` and `actor_token` are issued by the same Authorization Server, what validations does the Authorization Server perform on both tokens? - In my view, the Authorization Server should at least perform signature verification, as well as validation of the `exp` and `nbf` claims. The `iss` claim should correspond to the Authorization Server itself, and the `aud` claim should represent the same set or subset of `Audience (Resource Servers)` configured in the Authorization Server. 5. What is set as the `aud` in the returned `access_token` when both `resource` and `audience` are included in a Token Exchange request? - I believe the `resource` and `audience` parameters in the Token Exchange request are mutually exclusive. If `resource` is provided as a URI, there is no need for the `audience` parameter, which is just a logical string. 6. Does upscoping pose a security risk? For instance, if the Resource Owner consents to `scope1 scope2` but upscoping results in an `access_token` with `scope3 scope4` without user consent, how can this be mitigated? - Upscoping is only suitable for trusted clients in enterprise setup. One solution is to implement Client-Restricted Scopes. However, even with restricted scopes, there is no explicit user consent for the upscoped scopes. 7. As per my understanding, the `subject_token` is typically initiated by the Client and passed to the Resource Server. However, in [RFC 8693, Example 2]( https://datatracker.ietf.org/doc/html/rfc8693#name-subject-token-claims), the `subject_token.aud` is shown as `"https://as.example.com"`. How is this possible? Shouldn't the `aud` claim only refer to the Resource Server? - Is this a typo? 8. Does the Token Exchange Delegation Flow share similarities with UMA (User-Managed Access)? - I think UMA is more dynamic in nature, while Token Exchange is more static and reliant on predefined relationships or scopes. Is this interpretation correct? -- Arjun Balla
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
