Is there some mechanism built in Identity for extending access token life, or I have to deal with it ?
When you create a client called [AccessTokenLifetime] this sets how long an access token is valid for. Normally you would set it to 3600 which is an hour you can of course set it longer.
Once an access token has been created though you cant change its lifetime they have to be created with the desired lifetime.
Remember the point of access tokens is that they are short lived giving them long lifetimes is probably not the best idea.
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 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
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.
I am developing an oAuth2 server and I've stumbled upon this question.
Lets suppose a scenario where my tokens are set to expire within one hour. On this timeframe, some client goes through the implicit auth fifty times using the same client_id and same redirect_uri. Basically same everything.
Should I give it the same accessToken generated on the first request on the subsequent ones until it expires or should I issue a new accessToken on every request?
The benefits of sending the same token is that I won't leave stale and unused tokens of a client on the server, minimizing the window for an attacker trying to guess a valid token.
I know that I should rate-limit things and I am doing it, but in the case of a large botnet attack from thousands of different machines, some limits won't take effect immediately.
However, I am not sure about the downsides of this solution and that's why I came here. Is it a valid solution?
I would rather say - no.
Reasons:
You should NEVER store access tokens in plain text on the Authorization Server side. Access tokens are credentials and should be stored hashed. Salting might not be necessary since they are generated strings anyway. See OAuth RFC point 10.3.
Depending how you handle subsequent requests - an attacker who knows that a certain resource owner is using your service and repeat requests for the used client id. That way an attacker will be able to impersonate the resource owner. If you really return the same token then at least ensure that you authenticate the resource owner every time.
What about the "state" parameter? Will you consider requests to be the "same" if the state parameter is different? If no then a botnet attack will simply use a different state every time and force you to issue new tokens.
As an addition - generally defending against a botnet attack via application logic is very hard. The server exposing your AS to the internet should take care for that. On application layer you should take care that it does not go down from small-bandwidth attacks.
You can return the same access_token if it is still valid, there's no issue with that. The only downside may be in the fact that you use the Implicit flow and thus repeatedly send the - same, valid - access token in a URL fragment which is considered less secure than using e.g. the Authorization Code flow.
As a thumb rule never reuse keys, this will bring additional security in the designed system in case of key capture
You can send different access token when requested after proper authentication and also send refresh token along your access token.
Once your access token expires, you should inform user about that and user should re-request for new access token providing one-time-use refresh token previously provided to them skipping need for re-authentication, and you should provide new access token and refresh token.
To resist attack with fake refresh token, you should blacklist them along with their originating IP after few warnings.
PS: Never use predictable tokens. Atleast make it extremely difficult to brute force attacks by using totally random, long alpha-numeric strings. I would suggest bin2hex(openssl_random_pseudo_bytes(512)), if you are using php.
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.