CODEWITHSUNDEEP
web-servicesapioauth-2.0soaorchestration
user1759368
user1759368

Reputation: 61

OAuth 2.0 multiple scopes (client credentials case)

In an OAuth 2.0 setting, suppose you have an application doing an 'Access Token Request' following the 'Client Credentials Grant' flow. In other words, we have an application A accessing some APIs exposed by other applications; as specified by Oauth 2.0, in this case 'application A' use only its client credentials and not the credential of a user.

Now, suppose that application A wants to access the APIs exposed from two or more applications, let's say application B and C (for example: application A orchestrates the access to B and C's APIs to provide a composed service). Also B and C are in different domains, for example b.com and c.com, but A, B and C share a common OAuth Authorization Server.

  1. Is it possible for A to request a single access token that has in its scope both the resources in the b.com and c.com domains so that A can access B and C with the same token?

  2. How can you obtain this?

  3. If this is not possible, is there any best practice to manage a similar case?

Please note that I know that the OAuth 2.0 specs allows to specify multiple scopes while requesting or issuing a token, but the point here is that B and C are in different domains, for example b.com and c.com.

Thanks and kind regards,

Corraz

Upvotes: 3

Views: 3078

Answers (1)

Jan Gerlinger
Jan Gerlinger

Reputation: 7415

  1. Yes, this is certainly possible.
  2. From the specification:

The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification, but generally involve an interaction or coordination between the resource server and the authorization server.

So this completely depends on your implementation and the type of your tokens, you just have to make sure that the access token was issued by your authorization server and is still valid. Having different domains does not have any influence on this.

Probably the most widely used pratice is doing a database lookup on your resource server to see if the access token is stored there (and thus valid) and having that table synced with your authorization server (or directly use the same database for A, B and C). 3. See 1. ;)

Upvotes: 1

Related Questions