I use Spring-Lemon library for my spring boot project. I use a web front-end to my application. My question is, how to know if my auth token is about to expire? Documentation said a Get context operation should be used in this case to get a new token. But I did't find the way to find out when I should use this method to get a new token. Is there way to add the expiration date or the time remained to the responses, so my front-end would know that it should renew the token?
Knowing when it'll expire shouldn't be a problem, because you actually control it:
By default, the expiration will be 10 days after you call
/context (See LemonProperties)
You can change it by setting a
property
You override the property be calling get-context with a
parameter: /context?expirationMillis=123456
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 have created an authentication server that implements OAuth 2 for authorization and it also provides local password authentication using the resource owner flow.
At the moment I always return a refresh token along with the access token which was an acceptable thing to do when I first implemented the feature. However now I need to implement a remember me feature in the client that uses the server. I could always just save the refresh token in the client when the user ticks the remember me checkbox but the token would still exist on the server and be usable even though the user didn't want it to.
What I want to do is simply pass a parameter along with the request that tells me whether I should create a refresh token or not.
So my question is. Is there some standard or recommended way of doing this using the fields provided in the spec or is it acceptable to simply add a parameter to the request to handle this use case?
AFAIK, there is no standardized way to choose whether to issue a refresh token or not.
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.
I'm trying to set up some simple security rules for my Firebase (essentially, any authorized user can read/write), which I'm using with a Rails application that uses Devise for user-authentication. However, I'm having trouble understanding how the process of generating tokens work.
I found the Ruby gem here:
https://github.com/firebase/firebase-token-generator-ruby
However, I'm not sure where I'm supposed to put this snippet of Ruby code:
require "firebase_token_generator"
arbitraryAuthPayload = {:auth_data => "foo", :other_auth_data => "bar"}
generator = Firebase::FirebaseTokenGenerator.new("<YOUR_FIREBASE_SECRET>")
token = generator.create_token(arbitraryAuthPayload)
Do I just put it in an initializer along with a variable for user_id?
Also, I saw that tokens expire after 24 hours. Does that mean this token generator will automatically generate a new token for each client with an expired token?
Thanks
If the clients need to read/write from Firebase directly they will need to have that token to auth to Firebase before they can, so it would probably be a good idea to generate a token wherever you're handling user authentication / initialization.
As you mentioned, the default session length is 24 hours, so after that they will need a new token. You can specify a different expiry time using a second options parameter with an :expires key to the create_token method as mentioned in the README to any future date. That way you can set it for say 30 days in the future, or whatever your normal session length is, or you could create an endpoint that returns a valid token and handle the expiration gracefully on the frontend.
If the ruby server is the only thing accessing Firebase, things are a little easier - you could just create a server token once and allow it read/write access to the whole Firebase
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.