​Hi Community,

 

We are on ISAM 9.0.5

We have OAuth for a mobile app.

I am trying to understand why some of the refresh_token received in Production are being rejected (approx. 1% of refresh token are rejected).

 

With trace in the pre-mapping rules, it seem that these rejected token are simply not in the database:

I get the token:

stsuu.getContextAttributes().getAttributeValuesByNameAndType("refresh_token", "urn:ibm:names:ITFIM:oauth:body:param");

when I try to obtain the corresponding token objet:

var token = OAuthMappingExtUtils.getToken(refresh_token);

the token var is NULL

 

So in the AAC's Advanced Configuration, I have set:

oauth20.tokenCache.cleanupWait= 604800

(one Week)

 

In the pre-token mapping rules, I set:

var max_oauth_grants_per_user_per_client = 30;

var limit_method = "lru";

 

I was expecting that the resulting behavior would be that the tokens get accumulated in the runtime database for up to a week.

I was expecting the stale token (either expired bearer or already used/expired refresh) would stay in the database with flag TOKEN_ENABLE at "N".

 

Having those "old" disabled token could have given me a clue as to what is happening: I could look at the created date & the last used date to try & rebuild the sequence of events that lead to the refresh token being refused.

 

But it seems that the stale tokens get erased from the database every time I go through a refresh_token process. Is there a way to avoid this?

 

Also, can you suggest which trace could be activated that would help me understand what is happening?

 

We had an issue with the app (in some very specific cases) trying to refresh multiple time using the same refresh token. I activated "Enable multiple refresh tokens for fault tolerance". That fixed this issue and reduced the rejected numbers but we still have a approx. 1% rejection. And the refresh token cannot really be expired as the app has not been in production longer that the life of the refresh_token. We've been in prod for 3 months & the refresh_token have a lifetime of 6 months.

  

Many thanks,

Louis

------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------

Hi Louis,

To make sure that this is not caused by your "max_oauth_grants_per_user_per_client / lru" config, I would start by putting tracing in the pretoken rule.
When this rule deletes grants because of your limit, I'd put in a trace that prints the grants that were deleted. Look for OAuthMappingExtUtils.deleteGrant in your pretoken rule to find that piece of code.
Use IDMappingExtUtils.traceString for the tracing and set the runtime tracing to something like com.tivoli.am.fim.trustserver.sts.utilities=ALL

Kind regards, Peter



------------------------------
Peter Volckaert
Sales Engineer
IBM Security
------------------------------

Hi Louis, 

I've seen this in a past customer issue where the function of the configuration item: Maximum authorization grant lifetime was not correctly interpreted.  The way this manifested is that grants would seemingly fail to refresh at random! Which sounds similar to the problem you're seeing. 

Can you share the value you've set for this configuration? Its important to note that this is the grant lifetime, not the refresh token lifetime. This means that when a refresh token flow occurs the lifetime of the token is maintained, not reset back to the full value. 

Eg if RT1 will expire at 6:00pm, and is refreshed, RT2 will also expire at 6:00pm. 

There is a way to change this via some javascript in the post token mapping rule:

if(grant_type == "refresh_token") {
  var tkn = stsuu.getContextAttributes().getAttributeValueByNameAndType("refresh_token_id", "urn:ibm:names:ITFIM:oauth:response:metadata");
  IDMappingExtUtils.traceString("got token: " + tkn);
  if(tkn != null) {
    var token_lifetime_in_milliseconds = 7200 * 1000;
    var updated = OAuthMappingExtUtils.updateToken(tkn, token_lifetime_in_milliseconds, null, true);
    IDMappingExtUtils.traceString("Token updated? " + updated);
  }
}

So my question for you - what is your grant lifetime and how long has the system been in production? 

------------------------------
Leo Farrell
------------------------------

Hi Leo,

Our grant lifetime is 15,552,000 (180 days) but our app has only been online for around 3 months.

But you point is very valid as we DID make the erroneous assumption that the refresh_token lifetime would be reset to 15552000 at every refresh (i.e. that it represents an "inactivity" time-out)

I will be implementing the modification you suggested very shortly.

At the same time I am also adding traces to the deletegrant routine in the pretoken rule as Peter suggested.

Thanks for your help
Louis

------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------

​Hi Leo,

Even though the javadoc for OAuthMappingExtUtils.updateToken states that the newLifetime should be passed in milliseconds my test show that I need to pass the value in seconds to obtain the correct lifetime.

Louis

------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------

Concerning my last comment, I see an entry that seem to be related this :

https://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1IJ17439
which point to :
http://www.ibm.com/support/docview.wss?uid=swg1IJ17439
But I don't seem to have access

------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------

Original Message:
Sent: Tue November 06, 2018 03:06 PM
From: Louis Beaudry
Subject: OAuth: Rejected Refresh_tokens

​Hi Leo,

Even though the javadoc for OAuthMappingExtUtils.updateToken states that the newLifetime should be passed in milliseconds my test show that I need to pass the value in seconds to obtain the correct lifetime.

Louis

------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------