Erick T
Erick T

Reputation: 7449

Can I use OAuth Token as an alternative to Ocp-Apim-Subscription-Key?

I am looking at using Azure API Management to provide a consistent front end to a number of backend APIs.

Most of the APIs are secured using OAuth 2.0 application flow (ClientID + Client Secret, with the backend API checking claims/scopes). This works great, but when clients use these APIs via APIM, they need to provide an APIM Subscription Key and an OAuth 2.0 Token. I understand that the APIM Subscription Key is used to identity clients to APIM (for the purposes of rate limiting, logging, and the like), and the Token is used for the backend authentication/authorization.

Is there any way that a Client ID could be used as an alternative to the APIM Subscription Key? That is, a client doesn't need to provide a APIM Subscription Key, and the OAuth 2.0 token identity is used for all APIM features (e.g., limit rate by Client ID).

Upvotes: 3

Views: 2749

Answers (2)

CompaNova
CompaNova

Reputation: 1

It looks a little bit hacky, but here is how you could change the rate limit for a particular clientId

  1. You could assign a valid jwt token to the variable using the output-token-variable-name attribute. Something like this: <validate-jwt header-name="Authorization" output-token-variable-name="jwt">
  2. Use this value in the rate-limit-by-key policy:

<choose>
  <!-- Set a different rate for a specific client -->
  <when condition="@(((Jwt)context.Variables["jwt"]).Claims["cid"][0] == "<specific clientId>")" >
    <rate-limit-by-key calls="10000" renewal-period="60" counter-key="@{           var jwt = (Jwt)context.Variables["jwt"];           return jwt.Claims["cid"][0];         }" />
  </when>
  <otherwise>
    <rate-limit-by-key calls="1000" renewal-period="60" counter-key="@{           var jwt = (Jwt)context.Variables["jwt"];           return jwt.Claims["cid"][0];         }" />
  </otherwise>
</choose>    

Upvotes: 0

Vitaliy Kurokhtin
Vitaliy Kurokhtin

Reputation: 7810

It is not possible to use OAuth token to identify client, but you can use it for rate-limiting and logging (of sorts). STart by creating a new product that does not require subscription, any API added to that product becomes anonymously accessible. To counter that you can place validate-jwt policy on that product to require OAuth token and check it's claims, or if you're really don't care about token contents just want to know that it is there you can use check-header policy.

Using policy expressions you can do context.Headers.GetValueOrDefault("Authorization").AsJwt() to parse provided header into JWT object model, inspect its claims, and use it in rate-limit-by-key and quota-by-key policies to implement throttling per client.

To make logging work there is no other way at the moment rather that to rely on log-to-eventhub policy and log necessary information yourself. That does mean that you need to maintain EventHub instance and further infrastructure to read records from it and store them somewhere. Some changes are coming to broaden logging capabilities that will make this easier though.

Upvotes: 2

Related Questions