How to populate flow variables when oauth fails

[archanamalakala]

We have Get OAuth 2.0 info policy to get the app or client info for a given access token but I could find the flow variables getting populated if OAuth fails ,my requirement is that if a verify access token fails we have to know for which app it failed for ? How can I achieve this  when the flow variables are not been populated  after OAuth failing with 401?

[dchiesa1]

I think it is not possible to populate variables for the particular app, for the general case in which a token is invalid.  But you may be able to get data in the specific cases in which the token is invalid because it's expired or revoked.

A token can be invalid for various reasons, among the most common are:  it's expired, it's revoked, or it's just an unknown token. 

In the case of an expired or revoked token, you can configure the GetOAuthV2Info policy to set variables despite the expiry or revocation status of the token.  Use the IgnoreAccessTokenStatus element. The policy will then set a variety of context variables - the app name, the expiry, etc.  

<GetOAuthV2Info name='OAuth-Get-Info' continueOnError='true'>
  <AccessToken ref="extracted.access_token"></AccessToken>

  <!-- tellt he policy to set variables even if the token is expired, revoked -->
  <IgnoreAccessTokenStatus>true</IgnoreAccessTokenStatus>

  <!--
This policy populates variables like

oauthv2accesstoken.##.status
oauthv2accesstoken.##.access_token
oauthv2accesstoken.##.expires_in
oauthv2accesstoken.##.accesstoken.CUSTOM_ATTR
...
-->

</GetOAuthV2Info>

The set of variables the policy will set, is documented here.  

The problem is, there are cases in which the token is simply unknown. It's just not a token at all.  In which case, there is no developer app, there is no client id, and so on.  Those data have no meaning. So it will not be possible for the policy to set a variable containing "the app name" in those cases.

[archanamalakala]

Thanks for the reply but my scenario is that the developer has an access token he obtained from application A for product A but he is using that token to call product B of application B, which means in this case the token in not expired or revoked but  it is invalid to call apis in product B . So how would i know which app is making this call and failing?

[dchiesa1]

ok thanks for clarifying.

Did you try the "continueOnError = 'true'" option? 

[archanamalakala]

Yes I did try it worked @dchiesa1  . But I have this requirement that if an app makes more than 5 consecutive 401 auth error calls we need to revoke it's access. We are thinking we need a counter for this for each app. Do you think we can create custom attribute named counter on each app and keep it updated if the condition of oauth failure is met? Do i need to post this as new question if so sorry for doing to this.

[dchiesa1 · Accepted solution]

Five consecutive 401s.... 

I don't think a custom attribute on each app is the right way to go. The app artifacts are cached in the MP, and AFAIK AccessEntity will read from cache. (But I haven't tested this exact scenario - you may wish to test it).  Further, it is not possible for you to  flush or circumvent the cache via a configuration flag that you apply to AccessEntity. 

You could try using  a Quota policy for this purpose, with allow limit = 5, and Synchronous=true. Use the token as the quota identifier.  In the case of 401, increase the quota.  In the case of non-401, reset the quota. Use a continueOnError = true in the Quota policy.  Check the condition afterwards to see if the quota has fired, and if it has fired, revoke the token.  

If you don't necessarily mean five consecutive 401s, but five 401s at any point, then... don't reset the quota in the case of a successful validation. 

Be careful though - the effective quota identifier always includes the proxy name, so .. you must always perform this check within the same proxy. Use a local shared quota proxy to get this behavior. (There is an outstanding feature request to change this behavior).    

If the Synchronous Quota does not work for you, then you may need to resort to an external store of data.  A database that you manage.  You'd need to call out to it , maybe via ServiceCallout, after every 401. 

Good luck.

[archanamalakala]

thanks @dchiesa1  it worked i need to do some testing though it worked 😀 .

[archanamalakala]

@dchiesa1  So it worked in a way .So we have set this up when the Oauth fails (that is the test condition for Quota policy) everything works as expected and the user is blocked for one hour as configured only if he keeps calling with invalid creds ,if he calls with valid creds on 6th call (after 5 failed oauth calls) Oauth would work as usual without going into the quota check flow. So can we lock the user even if he sends right creds after 5 failed auth attempts.