[Iplant-api-dev] OAuth expire time inconsistent

[Joe Stubbs]

Hi Jon,


Thanks for your messages, and we apologize for the trouble. I think I can explain a lot of what you are seeing, but if not please feel free to pass on more information.


There are a couple of things going on. First of all, there is a bug with our OAuth server that does occasionally cause it to return 400 responses on valid requests for an OAuth token. The issue is rooted in a caching bug within the token service itself which causes cache entries to not be invalidated appropriately. From our understanding of the issue, it should correct itself once the cache expires which should be within the life of the token.


Certain (valid) actions within the API (such as a long running file upload) can trigger the invalid cache state. It is possible that you are encountering this issue. We are are actively working with WSO2 to get a fix in place as soon as possible. At the same time, we are monitoring our server for this behavior and clearing the cache when it is detected.


For token expiration times, keep in mind that the OAuth tokens not only represent an end user but also an OAuth client. If an OAuth client issues a request for an OAuth token on behalf of an end user (using the password grant, say) then an access and refresh token will be returned with an expiration time. Now, if the same OAuth client issues a subsequent password grant request for a token on behalf of the same user within the time expiration, the *same* token will be returned but with an appropriately reduced expiration time. This is by design to support the same client running in multiple processes, etc. On the other hand, a different client making a token request for the same end user will of course get a different token with its own expiration time.


I hope this helps. Let me know if this does not explain everything you are seeing.


Best,

Joe

________________________________
From: iplant-api-dev-bounces at iplantcollaborative.org <iplant-api-dev-bounces at iplantcollaborative.org> on behalf of Rion Dooley <dooley at tacc.utexas.edu>
Sent: Friday, March 27, 2015 9:36 AM
To: Joe Stubbs
Cc: iPlant API Developers Mailing List
Subject: Re: [Iplant-api-dev] OAuth expire time inconsistent

Joe will be able to comment in much greater depth about our OAuth2 implementation, but this specific question is easily explained. When you login, you have established who you are and are granted a bearer token valid for 4 hours. If you authenticate again, you have proved who you are again and get another 4 hour token. Password flow requests are idempotent. The fact that you have the username and password speaks to the trust required to initiate that flow.

On the other hand, when you bounce around between multiple flows, alternating between authentications in high trust and low trust scenarios, your token can get rejected in the lower trust scenario. I don’t think this is necessarily the best approach, and it’s something that is already addressed in the next version of our server, but it is what it is right now.

—
Rion

On Mar 27, 2015, at 9:14 AM, Duvick, Jonathan P [GDCBS] <jduvick at iastate.edu<mailto:jduvick at iastate.edu>> wrote:

Another curious observation: multiple logins (grant-type=password) with the same credentials returns different 'expires_in' times, with the first one off by 5 minutes relative to subsequent logins.
Example:
1st login:  expires_in = 1427474948
2nd login: expires_in = 1427474648
3rd login: expires_in = 1427474648


Jon Duvick
PlantGDB Manager
http://www.plantgdb.org/
Department of Genetics, Development and Cell Biology
2258 Molecular Biology Building
Iowa State University
Ames IA 50011

(515) 294-2360
(515) 294-6755 FAX
_______________________________________________
Iplant-api-dev Mailing List: Iplant-api-dev at iplantcollaborative.org<mailto:Iplant-api-dev at iplantcollaborative.org>
List Info and Archives: http://mail.iplantcollaborative.org/mailman/listinfo/iplant-api-dev
One-click Unsubscribe: http://mail.iplantcollaborative.org/mailman/options/iplant-api-dev/dooley%40tacc.utexas.edu?unsub=1&unsubconfirm=1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iplantcollaborative.org/pipermail/iplant-api-dev/attachments/20150327/f9bb6367/attachment-0001.html