What are the main differences between grant types "urn:ietf:params:oauth:grant-type:jwt-bearer (https://www.rfc-editor.org/rfc/rfc7523) and "urn:ietf:params:oauth:grant-type:token-exchange" (https://www.rfc-editor.org/rfc/rfc8693).
Difference between jwt-bearer and token-exchange grant types
Asked Answered
- "urn:ietf:params:oauth:grant-type:jwt-bearer" is a URN defined as a JWT Bearer Token by OAuth 2.0 Authorization server (uses OAuth2.0 Authorization grant type ).
- "urn:ietf:params:oauth:grant-type:token-exchange" is a URN defined as a JWT Bearer Token by OAuth 2.0 Authorization server (uses OAuth2.0 Token Exchange grant type).
Notes:
- jwt-bearer means whoever bearing the JWT token shall be given access to the requested resource.
- token-exchange is basically used for user impersonation and delegation purpose. Typically used by a support person who exchange his/ her JWT bearer token to impersonate as an end-user to request the end-user's resource to help in live-debugging of issue (or) exchange another JWT bearer token for a given token for a downstream systems.
For Token Exchange rather than user impersonation or delegation purpose, this line from the specification made more sense. "facilitates the sharing of identity and security information in heterogeneous environments or across security domains" –
Figuration
I'd say a much more likely scenario for token-exchange grant-type usage is in a distributed system context when a user makes a request to a resource from which that resource needs to make a downstream request to another service which also requires user verification. This approach allows for a more robust security practice as it ensures a token is exchanged at the IDP for downstream access. It also means you can further fine tune the claim for the downstream service –
Krahling
token-exchange is a standardised grant-type however Microsoft uses a similiar flow called "on-behalf-of" see learn.microsoft.com/en-us/azure/active-directory/develop/… for reference –
Krahling
@MatthewBrent, MS On-Behalf-Of at its best serves only a subset of the Token exchange (RFC 8693) functionality – it issues a new
access_token
for a new client based on an existing one (as you request on behalf of that client). –
Isotron © 2022 - 2024 — McMap. All rights reserved.