Observing OAuth2, expires_in seems to be a common parameter returned alongside an access token. The value of expires_in is the number of seconds remaining until the access token expires. I'm having trouble seeing how client applications would be able to make use of this in a convenient way. Expecting clients to count down the seconds after receiving an access token seems annoying at best. Wouldn't it be easier to set something like expires_at with a future timestamp when it expires?
Your proposal of expires_at would be almost impossible to manage when client and server are not synchronized in time. But if I'm wrong, please, correct me.
You have two options here:
Calculate if the token has expired by subtracting the expires_in seconds and the seconds spent from where you requested the token until now.
Get the token info (/oauth/tokeninfo, /tokens/{token}, or whatever, depending on the OAuth2 provider, and check if it is still valid and has not expired.
Both approaches have clear pros and cons, but I do, personally, prefer the second one.
Related
I'm using the Dailymotion API which uses Oauth2, their client tokens expire in 36000 seconds (10 hours), so I thought of creating new tokens for every call with the refresh token URL provided. Also, I didn't find any warnings in the documentation preventing me from doing this, is this a bad practice?
creating a new token on every requests is not the best way to proceed.
During your request, you can check (ex: with a "try") if your access token has expired then request new one with your given refresh token only if necessary.
If you are using a language like PHP, Python, Javascript, ... you can save much time using the available SDKs that already implement these mechanisms.
cf. https://developer.dailymotion.com/tools/sdks/
Yes, it is a bad practice, even though it's feasible. Authorization Servers might impose rate limiting on your client so that at some point you won't be able to refresh the token.
The access token must have expiration time for security reasons. If anyone manages to get hold of that token they will be able to use it only for the specified time. Good practice is to have as short expiration times as possible - e.g. 5 or 15 minutes. The 10 hours used by Dailymotion is a bit much, in my opinion, but it's their decision.
Refresh tokens should be kept securely by your client and you usually need a client secret to make a refresh request. This means that generally it's much harder for an attacker to get hold of a refresh token (or use it once they manage to steal it).
I understood why Access Tokens have to be expired (here is the topic), but I am a bit confused about the purpose of the expires_in:
expires_in seems to be less useful than a fixed time, since there are delay in network operations and extra computation as well. Why don't we simply use a standard time (like Unix timestamp or ISO 8601)?
As in that topic, if we are assuming Access Tokens are very short-lived, are we going to "bomb" the OAuth2 server with refresh token for every operation?
When I do the initial authentication to the Asana API with OAuth, it gives me a refresh_token as well as an expires_in of 3600 ms (1 hour).
What is the typical way of determining whether my app will need to use the refresh_token to get a new access_token?
I can think of two options:
Watch for an authentication error and then request a new access_token.
Store the date/time from now until 1 hour from now. Then with each API request, check the date/time to see if that time has already passed, and if so, request a new access_token.
Is there a better way than one of these two options? I don't see a recommendation from Asana in their OAuth documentation.
Thanks!
(I work at Asana.)
Great question! Both of your ideas are quite reasonable and should work - pick whichever is easiest / makes sense for your implementation. #1 is a little more robust in case there is skew with the timing, but if you just add some padding (be sure to request the token 1-2 minutes before expiration) then #2 should work just fine.
Note that it is always possible for the user to revoke the token, in which case when you go to get a new token the request will fail.
This seems like a good thing for us to recommend in the documentation, and possibly even add an automatic mechanism for in our client libraries.
We are:
Using OAuth for both authorization and authentication
Using the implicit-grant flow (i.e. client-side flow)
Issuing relatively short-lived access tokens (measured in hours, not weeks)
I want to offer a comparable experience to the traditional expiring-cookie policy, where you get a certain amount of time that your credentials will work, but if you stay active on the site that window continually resets. I'm realizing that this is not straightforward in OAuth. Yes, tokens are issued with an expiry time, but most implementations keep that time fixed regardless of activity.
This isn't so weird when issuing extremely long-lived tokens as one does when authorizing an integration (like, say, a Twitter app). But it's weird when using OAuth for user-facing authentication. If we issue a short-lived token and the user goes for a big session on our site, their access may run out abruptly even though they are in the middle of something. Even if we issued a token valid for 24 hours, if the user comes back 23.75 hours later, they're going to get 15 good minutes and then suddenly get kicked off.
I'm trying to figure out how to offer my users a better experience while sticking to OAuth mechanics. So far, my best idea is to change the server-side implementation to update the expiry date on the token on each authenticated request (this only works because our tokens have a server-side component - I don't know how it could work if we went the self-contained token route). And then, to keep the client appraised of the updated expiry time, we'll want to send that back with our response, maybe in a header, or a meta attribute in the JSON object.
This approach seems a little complicated, but workable. Is there a better way? Has anyone else dealt with this issue? Am I nuts for even trying?
I am looking at using Savon to consume a SOAP API. One of the requirements of this particular API is that an authentication token be supplied in each request to the API. That is, apart from the request that returns the authentication token itself. That call just needs a username and password. The token expires after 20mins of inactivity.
My question is, what is the best practice for storing this token? It's surely not advisable to make two requests every time, one for the token and one for the actual request?
I was considering storing it in a session variable but this would mean generating a new token for each visitor, which I presume is not necessary. However, it would mean I could set a 20 minute expiry on it very easily though.
If I store it in the database, how would I know whether or not it will have expired before making the call to the API, without a lot of extra logic?
Or, should I store it in the database and simply make a background call to the API every few minutes to ensure the token never expires?
Or am I barking up completely the wrong tree?!
Thanks for any advice.