Return to Question

A                       C                       B
[client]                [identity provider]     [resource server]
|                       |                       |
|----- OAuth2 flow ---->|                       |
|<---- id-token --------|                       |
|                       |                       |
|--- get access-token ->|                       |
|<-- access-Token ------|                       |
|                       |                       |
|                       |                       |
|----- API-request/Bearer access-token--------->|
|                       |                       |
|                       | (token-introspection) |
|                       |<--- access-token -----|
|                       |----- user-info ------>|
|                       |    (incl. scopes)     |
|                       |                       |
|<---- response-data ---------------------------|

A                       C                       B
[client]                [identity provider]     [resource server]
|                       |                       |
|----- OAuth2 flow ---->|                       |
|<---- id-token --------|                       |
|                       |                       |
|--- get access-token ->|                       |
|<-- access-Token ------|                       |
|                       |                       |
|                       |                       |
|----- API-request/Bearer access-token--------->|
|                       |                       |
|                       | (token-introspection) |
|                       |<--- access-token -----|
|                       |------ response ------>|
|                       |   (incl. audience)    |
|                       |                       |
|<---- response-data ---------------------------|

Examples for Option 3:

• choreo

Client A will after an OAuth2 flow send the id-token to resource-server B which has to verify the validity of the id-token and in case it is valid will issue an access-token in exchange. Again the audience of the id-token must be verified such that the access-token created really meant for client A. The audience claim would limit the scope and would limit the possibilities client A has. Now the actual scope could be encoded in a based access-token for example. The question here is whether this is actually a valid possibility for OAuth2 and whether it could be considered in line with RFC8693 (Token Exchange). A potential benefit of

Client A will after an OAuth2 flow send the id-token to resource-server B which has to verify the validity of the id-token and in case it is valid will issue an access-token in exchange. Again the audience of the id-token must be verified such that the access-token created really meant for client A. The audience claim would limit the scope and would limit the possibilities client A has. Now the actual scope could be encoded in a based access-token for example. The question here is whether this is actually a valid possibility for OAuth2 and whether it could be considered in line with RFC8693 (Token Exchange). A potential benefit of this approach would be to have simplify the case when supporting multiple identity providers simultaneously. Also the resource server B would be able to handle request independent once an access token has been provided.