CODEWITHSUNDEEP
oauth-2.0openid-connectopenid-provider
Ricou
Ricou

Reputation: 1026

Oauth2 : a Data Provider whith multiple OpenId Provider

Imagine a DataProvider secured by OAuth2. This DataProvider accepts OAuth2 tokens from multiples OpenId Provider. When a RP (Client) calls this DataProvider with an Access Token, how the DataProvider can know the DataProvider to contact to check the Access Token ?

Upvotes: 1

Views: 263

Answers (2)

Hans Z.
Hans Z.

Reputation: 53918

OAuth 2.0 was designed for a world where the Resource Server (RS, which you call DataProvider) and the Authorization Server (AS, what you refer to as OpenID Provider) live in the same security domain.

Using hints to find the AS out of multiple ASes is non-standard behavior. Assuming that all ASes will use the same access token type, format and claims e.g. scopes is also a stretch. UMA 2.0, a profile of Auth 2.0 can actually help here https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html but is not widely adopted.

A better architectural approach is to setup an AS Server in your domain that issues an access token keyed off of the remote ASes.

Alternatively you can implement the OpenID Connect profile of OAuth 2.0, an identity layer on top of OAuth 2.0, which allows for multi-provider setups because the id_token in there spells out who the issuer is by the iss claim, a reference to the Provider and the interaction with a so-called UserInfo endpoint in the Provider's domain has been standardized.

Upvotes: 1

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13059

It is viable to create a backend which can accept OAuth tokens from multiple issuers. For this you need a layer to filter out requests and validate access tokens. If you are from JAVA EE background think this as a filter which protects all OAuth protected endpoints (ex:- Servlets).

Selection of authorization server (the party which issued OAuth token) can be done in several way.

First, request sender (probably a client) can pass a hint with OAuth token to data provider. You could utilize a dedicated header for this with a prior agreement with clients and data provider (server end). For example, auth-source:azure-ad to denote OAuth token was issued by azure ad authorization server. Note that in this approach you will need to agree on supported header values as well.

Second is to detect authorization server through issuer claim (iss claim). For this your access token must be in JWT format. As per current situation, many services issue access tokens in JWT format (ex:- Azure AD does this). JWT being a self-contained token should contain iss claim which denote the JWT issuer, the authorization server.

Upvotes: 0

Related Questions