How to implement an OAuth resource server to validate access tokens from different authorization servers?

huggie 0
Viewed 43

If I want to implement a resource server which can take multiple generic authorization servers, how can I make sure my resource server can validate the these access tokens from different servers?

+------+              +----------+
| Auth |              | Resource |
+------+              +----------+
         \            /
           +--------+
           | Client |
           +--------+

Despite the limited drawing above, say the client goes through the usual authorization code flow to eventually obtain an access token from the auth server and then send it to the resource server to fetch resource which belongs to a particular user which authorizes the client to fetch resource on behalf of the user.

It is not just OAuth authorization server I'm intending to support. I'm actually assuming it's an generic OpenID connect Identity server (IdP). So Auth could be Google's openID, or Microsoft's Identity Provider, or some third party generic OpenID IdP which I may not have control over its implementation.

I'm also not in control of the client, which is some third party server application which want to consume the API from the resource server.

I am trying to implement the resource server. The question is, how do I know which OAuth authorization server (or OpenID connect IdP) provided the access token that I'm suppose to validate? Does OAuth protocol say anything about this?

openid-connect oauth-2.0
1 Answers

Usually the Resource server (The API that you tries to protect) has a fixed dependency on one IdP, it would be very confusing if an API accepted tokens from multiple providers. You typically have one IdP inside your organization that issues tokens that your services trust.

For in ASP.NET core, the API downloads the public keys from this service and uses it to validate the signature of the incoming access token.

Then inside the token there is also typically an audience claim that indicates to whom the access token was intended for and the API can verify that as well.

You can connect so that you through your IdP you can authenticate users using external identity providers, like this picture shows:

enter image description here

Tore Nestenius0
Related