Have been reading on refresh token and could not find on the following. information
When does an refresh token expire?
Can a password change by the main user cause a refresh token to expire?
Can I explicitly set some dates for expiration of refresh token
Thanks
Chris
Have a look of this post.
http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
Refresh tokens last for 14 days, but If you use a refresh token
within those 14 days, you will receive a new one with a new validity
window shifted forward of another 14 days. You can repeat this trick
for up to 90 days of total validity, then you’ll have to
reauthenticate.
Refresh tokens can be invalidated at ANY time, for reasons
independent from your app (e.g. user changes password). Hence you
should NOT take a dependency on the above in your code – your
logic should always assume that the refresh token can fail at any
time.
Refresh tokens issues for guest MSA accounts last only 12 hours
Related
I have a multitenant web api project with microsoft azure integration. I connect to microsoft, get access token and refresh token and each time before access token expiration, I call api
POST https://login.microsoftonline.com/tenant/oauth2/v2.0/token
data in request is:
grant_type=refresh_token
refresh_token=xxxxxxxxxxx
client_id=xxxxxxxxxx
I get new access token and refresh token, and after an hour get new access token with the same api and last recieved refresh token. But after 24 hours somehow my refresh token expires, and I need to reconnect and enter my credentials again.
How to make my refresh token don't expire until i revoke it manually. I need somehow update refresh token timeout in background and save my integration always connected until i revoke it manually.
I need somehow organize this to stay connected always until manual revocation. Any solution?
There is a 24 hour limit to refresh tokens under certain conditions:
Refresh tokens sent to a redirect URI registered as spa expire after
24 hours. Additional refresh tokens acquired using the initial refresh
token carry over that expiration time, so apps must be prepared to
rerun the authorization code flow using an interactive authentication
to get a new refresh token every 24 hours. Users don't have to enter
their credentials and usually don't even see any related user
experience, just a reload of your application. The browser must visit
the log-in page in a top-level frame to show the login session. This
is due to privacy features in browsers that block third party cookies.
See: https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens
const router = express.Router();
router.post('/refresh', ...{})
The access token expiration period is 7 days and the refresh token expiration period is 30 days. If 7 days have elapsed, it notifies the mobile app client that it has passed, and the client sends a refresh token to the server to check if the refresh token is valid, and immediately receives a new access token for 7 days and a refresh token for 30 days. It's all right here, right?
But what about after 30 days?? What if the user doesn't log in for 30 days? The refresh token will also expire. And I want to keep sign in forever. (This is the for mobile app, so re sign in is not good for user experience) I don't know what to do at this time.
You have a few options depending on the intended functionality and security requirements of your application.
Change expiry period of one or both tokens, possibly make refresh token infinite to maintain some security
Is background refresh an option you can consider? If this can be completed without the user having opened the app it will work well for you.
Store user credentials and re-login (either automatically or manually) if re-accessing after the refresh token has expired.
If I understood the refresh token rotation right, it means that every time we request a new access token, we also get a new refresh token. If a refresh token is used more than once - we invalidate all the refresh tokens that a certain user previously used, and a user has to go through the authentication process again.
Does it mean that we need to store all the refresh tokens (all the old ones) in a database?
Can't we simply store the last refresh token, only one (that wasn't used yet), and with each request to get a new access token we would check if the refresh token sent in the request is in the database, and if so, we would create a new access and refresh token and overwrite the old refresh token in the database, so that old refresh tokens can't be used to get new tokens?
How long should such refresh tokens live?
Yes, but all will usually mean "all in a given time frame". The time frame will depend on your needs - for how long do you want to be able to identify any potential refresh token leaks.
You can, but then you don't get any better security than without using token rotation. This is because you never know who used the current token first - the legitimate user, or the malicious one, who stole your token. If it was the latter, then she will now have access to working access/refresh token pairs. The legitimate user will be left with an invalid token.
This depends on your requirements, features, security etc. You will usually find information that a refresh token should be valid for a couple of hours (usually up to 8), but I've setups with refresh tokens valid for days or even months.
I have a long running application (many days/weeks). Is there anyway to get OAuth access that is not tied to the 14 day refresh token expiry? No matter what I try I lose access in 14 days. It would put a huge burden on our users to have to re-authenticate every N days.
Azure AD Refresh tokens have a sliding expiry of 14 days, up to a maximum of 90 days. That is, as long as you use the refresh token in those 14 days, you will get a new refresh token valid for another 14 days. So your users would only need to re-enter credentials every 90 days.
That being said, for long running applications, the Client Credentials Flow may be more suitable. This uses Application Permissions rather than Delegated Permissions (so you may need to change the permissions in the Azure portal). If you really need to make your calls as a particular user it may not work in your case.
We are using Azure AD authentication with a bootstrap MVC site.
Everything is fine and dandy - except we have an issue with the token timeout.
I have read multiple articles about the token lasting 1 hour before re-authenticating against Microsoft.
Our problem comes up when posting data.
Efter we enter a page with a post form on it - and this hours expires when on the page - the post data gets lost when posting the data. Everything points in the direction of the problem occurring when the site goes to get a fresh 1-hour token.
Has anyone here had experience with this or have any idea of how to get around this problem?
Not sure if this is the right way of doing things, but this is how we're handling this situation.
Basically when a user authenticates against Azure AD, you get 3 things back - Access Token (which expires after 60 minutes), Refresh Token and Token Expiry. What we do in our application is cache these three items.
Whenever we perform something that requires Access Token, we first check if the token has expired or not (by comparing the server date/time with the token expiry). If the token is not expired, we simply use that access token. However if the token is expired, we fetch new tokens using refresh token (fetching new tokens using refresh token will again return Access Token, Refresh Token and Token Expiry which we cache again in our application).