Search code examples
oauthoauth-2.0openidopenid-connect

Accepting tokens from multiple authorization servers

scenario diagram

While educating myself about OpenID Connect the following scenario raised some questions. Most documentation available online about OIDC/OAuth assumes that a Resource Server is only accessed from a Client within the same “Authorization Realm”, meaning that the Client and all Resource Servers are protected by the same OIDC Provider (OP).

In the given scenario, the Client is protected by OP A and requires User A to login at OP A before being able to use the Client. By doing this, the Client also receives an Access Token from OP A which enables it to access Resource Server A on behalf of the user. So far so good.

User A also has an account in the Authorization Realm B and the Client needs to access the Resource Server B which is protected by OP B.

This Resource Server B is an API which calls other API's within the same Authorization Realm B. All these APIs/Resource Servers do not know anything about OIDC Providers outside their own Authorization Realm B. Resource Server B could not only be accessed from the Client from Realm A, but also from N amount of Clients from various Authorization Realms. In my current understanding, all Resource Servers in Realm B would have to accept tokens from the various OP's.

Which would mean:

  • A lot of configuration in all the APIs
  • Every time a new realm is added or removed, the configuration has to be updated for all APIs

I understand that Client A could obtain two Access Tokens. One from OP A und one from OP B. Common authorization libraries do not support this out of the box and this would increase the complexity the Client has to handle (managing/refreshing multiple tokens/sending the right token to the right endpoint). Also, it is not clear to me how the OIDC flow would look like when working with two tokens from two OP's.

  1. The Client would redirect the user to OP A for authentication (because the Client itself is protected by OP A).
  2. After receiving the ID and Access Token the user is allowed to use the Client and the Client has the necessary token for API A.
  3. The Client would also request an Access Token from OP B which means the user has to authenticate at OP B
  4. The user would either have to provide username/password at OP B or, if we use identity federation, OP B would redirect to OP A where the user already has a session, resulting in an Access Token from OP B for API B
  5. The Client would use token B for calls to API B and token A for calls to API A

Are there other solutions to accept requests from Clients protected by another OP using OAuth/OIDC? It is obvious that there must be some sort of trust setup between the two realms. But how can this be achieved without affecting all the Resource Servers in realm B?

Solution

  • The simplest option tends to involve federated authentication:

    • User in realm A uses a UI owned by realm B
    • The UI redirects to Realm B OIDC provider
    • The UI redirects further to Realm A's OIDC provider
    • User authenticates with Realm A credential
    • A Realm A token is posted to the Realm B OIDC provider
    • A Realm B token is returned to the UI
    • The UI sends the Realm B token to a Realm B API

    This in itself has pretty expensive prerequisites including trust to be configured between Realm A and Realm B OIDC providers. Once complete the code in UIs and APIs is pretty simple and the responsibilities are in the right places.

    Other options, such as allowing logins in Realm A then calling APIs in both Realm A and Realm B are often impossible to implement in a good way in practice.

    A lot of people want to do this sort of thing though - and maybe emerging standards such as JWT Bearer Token Exchange will help in the coming couple of years.