The server should invalidate the refresh token that has already been used for generating
new access token and refresh tokens, however the refresh token can be used multiple times for
generating new tokens, without being invalidated, even though the server provides a new
refresh token each time the request is triggered. I'm using AzureAD for my application.
I know there is a way to expire refresh tokens that have already been used using Refresh Token Rotation Implementation but is it implementable in AzureAD.
I'm pretty sure that it is working as they have designed it.
The purpose is that you can take the new refresh token and replace the one you have in your cache.
If you are running a distributed application, it is a good thing that the current refresh token doesn't immediately stop working since it allows the other instances to keep working while the token is refreshed in another.
As far as I am aware, there is no place to change this behaviour.
Related
I build an application that must use delegated AAD permissions to interact with the Graph API. App permissions are no option due to secruity restrictions.
This application is a background service which has some minimal UI for configuration of the application. The idea is to have users log into the UI once (via AAD), granting the required permissions. After that users will mostly never need to use this UI as there is nothing vital to configure.
This creates a situation where the user will only once present a usable access token. After that initial onboarding, the application will have to use a refresh token once in a while to keep being able to use the Graph API.
Is my assumption correct that in order for this to work, I must persist refresh tokens of each user? Intuitively this seems like both a security risk (if not implemented properly) and also a kind of complex system which would not only store tokens but also have additional background refreshing tokens and potentially informing users about eventual expired tokens (in case of failing token refreshs).
Yes, the refresh token you receive back is unique for each user, so you really need to keep the refresh and access token separate between each user and store them in a secure way.
Please also note that in some systems you get a new refresh token each time you use it.
Either you use the refresh token with a timer and refresh them each XX minutes. Or you do the refresh when the user receives a 401 Not Authenticated response from the API.
I have a web application written that uses the OAuth "authorization code" grant type to retrieve the initial access token, and then the "refresh token" grant type to refresh the access token on occasion.
However, a problem occurs when the OAuth server is bogged down and the request for a refresh token takes long (10+ seconds). The client will timeout the request and cancel it, but the server fulfills the request eventually. When the server fulfills the request, it generates the new access token and refresh token and simultaneously invalidates the old refresh token. The client never receives the new tokens.
Now the next time the client tries to renew it's token again (when the server is not bogged down), it's attempting to do so with an invalid (old) refresh token. Now the only way to fix the problem is to use the "authorization code" grant again, which requires manual intervention by the end user.
How do others work around this issue?
I've seen the exact same issue at a company I worked at.
The advice I gave them is not to expire/rotate refresh tokens. The Oauth protocol allows for refresh token rotation, but does not require it. In the Oauth threat model, the value and the implications are discussed, including the following note:
Note: This measure may cause problems in clustered environments,
since usage of the currently valid refresh token must be ensured. In
such an environment, other measures might be more appropriate.
The case you are dealing with is another reason (in addition to the note above) on why refresh token expiry is not a great idea.
If you have no control over that, then you have to develop some duct-tape kludge solution where you retain refresh tokens and substitute on the server side an expired refresh token for a current one. It's ugly, very ugly, but unfortunately I'm not sure there is much more you can do with this painful security control that causes more problems than what it is worth.
We have an application that makes use of OAuth in SharePoint 2013.
The application stores the access token for a user and makes use of the refresh token to request a new access token whenever it expires.
This flow works perfectly.
However, refresh tokens expires at some point too - It's valid for 6 months in SP2013 from what I understand. I would like to test the application to see how it handles the situation where the refresh token expires.
What is the best way to force an expiration of the refresh token in SharePoint?
Forwarding the system date has a lot of negative effects on the entire system, so it doesn't seem to be a viable solution.
All I can find is how to use a refresh token to request a new access token...
There is one thread though that has a way to force such a scenario in Salesforce by revoking the refresh token from the user's profile, but I can't find anything similar in SP2013.
Any ideas would be really appreciated
I've found that you can revoke an App's permissions completely by deleting the permissions for the app under Site Settings -> Site Collection Administration -> Site Collection App Permissions... however I don't think it simulates the case where the refresh token is expired.
I have developed a rails application that allows a user to login using their google account and then the application fetches the emails and parses them for information.
All this works fine, but I am facing issues with access token become invalid, hence I have been looking into refreshing the token. I found some code at:
https://stackoverflow.com/a/14491560/718087
With this code I have been able to get a new access token that works. But I have a few questions:
How many times can I use the same refresh token I got the first time? or do I need update my refresh token as well, each time I get a new access token? note: application is setup with offline access.
Do I need to refresh the token before it expires or it will still return to me a valid token after the old access token has expired? This will allow me to decide an approach as to when I should refresh the tokens - a: right before fetching the emails, b: automatically before the token expires via delayed jobs or something (this would add quite a overhead though)
I have gone through the api docs but could not find answer to my these specific questions. Please excuse my overly detailed queries.
Thanks,
Aditya
Refresh tokens never expire, unless revoked by the user. You should store it safely and permanently. You should definitely not go back and get new refresh tokens over and over, because only a certain number can be understanding per user/app combination, and eventually the older ones will stop working.
In answer to your question: "Do I need to refresh the token before it expires or it will still return to me a valid token after the old access token has expired?"
I have a rails app, and I check for expiration & refresh token existence:
if client.authorization.expired? && client.authorization.refresh_token
#then I refresh here...
So the answer is, Yes you can (and probably should) wait until your access token expires, and then refresh it.
I'm trying to add authentication feature to my application.
The authentication server implements oauth 2.0
I'm not sure how to save the refresh_token. I want to save it to a file, so next time when the application starts and there is a refresh_token available, it can ask for a new access_token. The user won't need to re-login again.
But this doesn't sound secure to me, because if someone copies my file that has the refresh_token to another computer, he can hack into my account.
You are correct with the attack that you describe. Refresh tokens have to be stored securely in order to be used as intended. As I understand, you are building a standalone application. Therefore, you can rely on file system security to prevent a refresh token being copied by an unauthorized user. You may want to use encryption for the refresh token, too, but the key would need to be bound to a user's session at your local machine (otherwise, the user would need to provide it during "sign in" process in order for the application to decrypt the refresh token).
Consider reading the thread from the OAuth WG, that discusses similar problems to the one described and provides some guidance:
https://www.ietf.org/mail-archive/web/oauth/current/msg02292.html
Refresh tokens are used to obtain access (this process requires HTTP Basic Auth). So, unless user has your (id,secret) combination he can't do much about it. However, storage of refresh token must be considered very seriously.
Here's my two cents:
Store your tokens in a DB
Whenever you use refresh token to obtain access token reset the refresh token as well. (Oauth2.0 has this feature, you can let the refresh token unchanged too, but it's wise in terms of security perspective to keep it changing and updating the DB)
Hope this gives some insights!!
You are right about your concern - you should not save the refresh token. By doing so, you jeopardize your client's data (and you know the reason; you wrote it in the question).
oAuth is not supposed to work this way.
You should keep the refresh token in-memory.