3

I would like to ask a question about OAuth2 with an external identity provider.

Assume a scenario with the following roles: Client A, Resource Server B, Identity Provider C. Furthermore assume that Client A is a web-application which makes the usage of a combination of client-id and client-secret useless (because secret is easily accessible for example with browser page inspection tools).

A user authenticates himself in the client C using his credentials against identity provider as such the client C receives an identity token. Now client A should call APIs of resource server B.

Now assume that the identity provider C is unaware of the resource server B (this is what I would refer to as an external identity provider). For example the identity provider C would be google. If the resource server that should be consumed would be the google API for example then it is clear that the google identity provider would be able issue an access-token to client A that can be used to use the API. Now however the resource server is outside of google and therefore goolge cannot issue an access-token for resource server B.

So far I see the following options to facilitated that client A can use the API on resource server B with an external identity provider I:

Option 1: Use ID-token as access token

In this approach client A would first obtain an id-token from the identity provider C. He can directly use this as bearer token and query the API of resource server B.

A                       C                       B
[client]                [identity provider]     [resource server]
|                       |                       |
|----- OAuth2 flow ---->|                       |
|<---- id-token --------|                       |
|                       |                       |
|                       |                       |
|----- API-request/Bearer id-token------------->|
|                       |                       |
|                       |  (verify Id-Token)    |
|                       |<----- id-token -------|
|                       |------ success ------->|
|                       |                       |
|<---- response-data ---------------------------|

Using id-token directly as access-token as suggested as a valid option in this answer regarding external identity providers but discouraged in this auth0 blog entry about id-tokens vs. access-token. With this approach no scopes are defined but with the audience which identifies the client the scope is given can be deduced. For example when using google as a service provider the verification of the id-token happens with the client-id as audience as described here. The audience claim would limit the scope and would limit the possibilities client A has.

Option 2: Accept access-token from identity provider

A step option would be that still client A would obtain an id-token from identity provider C. But then he would also ask for any access token from identity provider C and use this access-token to query the API. The access-token is not readable by resource server B but it would be used to obtain again the identity token from identity provider C through means of a token introspection. With a successful token-introspection resource server B knows that the given request token is valid.

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 ---------------------------|

This approach is very similar to Option 1 with the benefit that really access-tokens are used. From a security point of view there is however not really a difference with Option 1. Resource server B is able through token inspection to also verify the audience and can ensure the access token has been created for client A. It is important here that the audience is verified and not just "any" valid access token is accepted. Again the audience claim would limit the scope and would limit the possibilities client A has.

Option 3: Issue own access-token for the given service

In this approach the resource server B issues its own access token in exchange for a valid identity token.

A                       C                       B
[client]                [identity provider]     [resource server]
|                       |                       |
|----- OAuth2 flow ---->|                       |
|<---- id-token --------|                       |
|                       |                       |
|                       |                       |
|           (request access token)              |
|------------------ id-token ------------------>|
|                       |                       |
|                       |  (verify Id-Token)    |
|                       |<----- id-token -------|
|                       |------ success ------->|
|                       |                       |
|<--------------- access-Token -----------------|
|                       |                       |
|                       |                       |
|----- API-request/Bearer access-token--------->|
|<---- response-data ---------------------------|

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.

Examples for Option 3:

The question:

The actual questions now is: Which options would be a valid OAuth2 implementation? What would be the recommended option and why? Do further options valid in OAuth2 exist? Is there a description of a canonical solution for the case of an external id-provider?

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.