OAuth - How can I use 2 (or more) different grant types for different sets of APIs

[#1]

I have certain APIs (ex: Catalog API) that need client credentials and there are certain APIs that are user specific (ex: Purchase History API) and I want to enforce password grant

To take it to the next level, I have certain apps (internal, native apps), where password flow is ok, but for other apps, I want to enforce auth code flow.

Is scopes the best way to address this scenario, or are there better ways?

What is the best way to design my OAuth proxies and the Access Token Validation policies in the actual API Proxies?

[jdsa]

You cannot enforce grants that a client should use. Clients use different grant types depending on what kind of client they are i.e. web client vs mobile client vs html 5 ui vs command line client.

You can use any grant type to get a token. The grants get you tokens.

So is your question "How do you use tokens obtained by different grants for different sets of APIs?", then your answer will be using scopes. Each API has a set of scopes and tokens obtained by either grant should contain the scopes relevant to the API.

- Joel

[#3]

"You cannot enforce grants that a client should use" - I agree, but you can reject requests if they ask any grant type they are not allowed to. Is that not the same result?

[DChiesa · Accepted solution]

You have some APIs that access personal information, and therefore require a password grant or a authorization code grant. And you have some APIs that do not access personal information.

Yes, you could use token scope to govern this. And that's what I would do.

As far as I know there is no direct way to configure the OAuthV2 policy with VerifyAccessToken operation to check the grant_type that was used when the token was generated. Mapping one scope to grant_type password and another scope to authorization code, is a way to accomplish this indirectly.

In other words:

When you generate the token for Client credentials grant, you can issue scope = "A B Cred"

When you generate the token for password grant, you can give it scope "A B Pwd"

When you generate the token for authz code, you can give it scope "A B Code"

A and B scopes can be anything, they might have a meaning that is specific to the proxy in question. (And of course the names need not be A and B - they are just strings, you can use any label you like). The final scope attached to each token would implicitly identify the originating grant_type. I suppose you would accomplish this with three different configurations of the OAuthV2 policy / GenerateAccessToken operation.

Inquiring the transaction history would require scope Pwd or scope Code. Reading the product catalog might require scope Cred Pwd or Code. You would enforce the former (scope Pwd or Code) with an OAuthV2 policy like so:

<OAuthV2 name="OAuthV2-VerifyAccessToken-Pwd-or-Code">
  <Operation>VerifyAccessToken</Operation>
  <!-- a space-separated list of scope names. -->
  <Scope>Pwd Code</Scope> 
</OAuthV2>

The doc says:

If more than one scope is specified (for example, <Scope>A B C</Scope>), then the policy will succeed if the access token includes any one of those scopes (like a logical 'OR' evaluation).

The scope is not enough to ascertain which transaction history the call should return. For that you need the identity of the user that was authenticated during generation of the password-grant token, or the authz-code token. I suppose that at the time of GenerateAccessToken, you will want to attach the username as a custom Attribute to the new token.