AD-FS define refresh token life time to be equal to SSO lifetime. What would be the new refresh token life time, if we replace the refresh token with the newly acquired refresh token which we get in access token call.
For eg : If my ssolifetime is 720 mins(8 hrs) and after 6 hrs i make a call to get new access token which will also return a new refresh token. What would be the ssolifetime for this new refresh token. Is it 2 hrs(as 6 hrs is already elapsed) or it works in sliding manner and new life time for this newly acquired refresh token would be another 8 hrs starting from 6th hr.
If I understand correctly, in ADFS, if you are an unregistered device, and you don't use Keep me signed in option when signing in, then the Refresh token is = to the sso, which by default is 8 hours.
the way I understand it is you do NOT get a new refresh token in this scenario. so if you renew your token before the 8 refresh token expires, I would think your access token is good for another 8 hours, but your refresh token is no good anymore, so next time you try to get a new token it will fail.
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-settings#enable-psso-for-office-365-users-to-access-sharepoint-online
there's also Persistent SSO, for authenticated devices, and keep me signed in for unauthenticated devices, they all behave differently. but there is no indication that a unauthenticated device without "keepmesignedin" would ever get a new refresh token in adfs.
Session SSO cookies are written for the authenticated user which eliminates further prompts when the user switches applications during a particular session. However, if a particular session ends, the user will be prompted for their credentials again.
With KMSI disabled, the default single sign-on period is 8 hours. This
can be configured using the property SsoLifetime. The property is
measured in minutes, so its default value is 480.
I hope this helps a bit.
Related
While accessing Microsoft Graph API, using Azure Active Directory(AAD), we can generate a token with sliding expiration as 90 days as default value.
How can we reduce the sliding expiration for the same to like 1 hr so that it can be tested.
Assuming when you say sliding expiration, you mean refresh token which expires after 90 days by default.
As per the documentation, you can not set the refresh token lifetime as of January 2021.
In your case, if you are using MSAL, you don't have to test this expiry because it is handled by MSAL. So you can only ensure when refresh token expires, you handle the authenticating the user again.
If you just need to test what happens when refresh token expires, you can mock the expiry of the refresh token with a behavior in you test without having to touch the token expiration configurations which also is not possible.
I am using the Gmail api to send e-mails from my Oracle database.
After a while, the Oauth2 token expires and the token needs to be refreshed with, using the refresh token.
All of this works fine (in both Postman and Oracle).
When the mail has not been used for a while ( a few weeks) the refresh token doesn't work anymore.
Then I need to get a new authorization code etc. It seems as if the gmail-api revokes its grant after a certain time.
Is there a way to work around this ?
thanks in advance.
Servé
There are a number of things which can cause a refresh token to expire here are my top three.
Applications that are still in testing, and have not bee though the google verification process will have their refresh tokens expired within in two weeks.
If the user changes their password this will also cause a refresh token to expire when using the gmail scopes.
If you authorize the app, then authorize it again you get two refresh tokens both will work, you can have up to fifty outstanding refresh tokens once you have hit that number the first one will be expired, as you can maximum have fifty outstanding refresh tokens.
Have a look at the possible refresh token expiration reasons here: https://developers.google.com/identity/protocols/oauth2#expiration
My team is working on implementing or rather configuring B2C login for our client's mobile app. We got the configuration setup to a point where the user can login to the app once and the token gets cached in MSAL. And next time onwards, the user is able to directly login without entering his/her credentials. We are following the pattern as described here
Our code first tries to retrieve the token using AcquireTokenSilent and if the token is not present in the MSAL cache, then we retrieve it using AcquireTokenInteractive.
I was trying to understand how the ID and Access tokens are refreshed and found on MS docs here about tokens which says
Refresh tokens are used to acquire new ID tokens and access tokens in
an OAuth 2.0 flow. They provide your application with long-term access to resources on behalf of users without requiring interaction with those users...
This also mentioned that when we redeem the refresh token to get new ID and Access tokens, we also get a new refresh token that replaces the previous refresh token.
Now I tried logging out and log back into my mobile app after 1 hour or more and I was still able to login. When I inspected the claims, the ID and Access token expiry was refreshed to next 1 hour of login.
My question here is:
Since ID token and Access tokens have default expiry to 1 hr, then how is it that even though I was logged out for more than an hour, my token refreshed and I was able to login without entering user credentials.
If this is because refresh token automatically refreshes the ID and Access tokens when they approach their expiry, then does this process go on till the refresh token expires itself.
The MS docs also mentioned that when the ID and Access tokens are regenerated after their expiry, we also get a new refresh token. If this is the case then the refresh token would never expire since the new token will always have new expiry.
Is there a way to control the refresh token so that we can control when to refresh the ID and Access tokens.
I am sorry if I missed anything but I am a little confused on how the refresh token works and is there a way to control when to refresh the tokens and when not.
Thanks in advance.
Yes, the refresh token is used to get the new id token and access token, even the id token and access token were expired, as long as the refresh token does not expire, it could use the refresh token to get new id token and access token, meanwhile, a new refresh token will be generated, if you want to configure the token lifetime, you could do that in the portal.
Reference - https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-tokens?pivots=b2c-user-flow
I have an implementation of IdentityServer4 which connects with Azure AD for authentication (OIDC). In the callback method, using the IdentityServertools, I am generating the access_token and redirecting the user to SPA with the same. The SPA then stores the access_token into localstorage and uses it for authentication.
Normally, when my SPA app hits the token endpoint of the IdentityServer4, it gives access_token and refresh_token and then uses refresh_token to re-authenticate a returning user.
In this case of SSO with Azure AD, do I need to generate refresh_token manually? If yes, I can build on top of default implementation and that's not the problem (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
My real question is, is there a need of refresh_token here? Because refresh_tokens are stored in DB and never get's deleted and after sometime, these refresh_tokens table will swell (right now it already has 80k rows). The user is expected to click on a small tile inside SAP's Successfactor - that will open the signin/consent screen of Azure or will directly take the user to the main page where zhe will just answer a question and done. So it's hardly 2-3 mins business. So I can continue to generate access_tokens from my IdentityServer4 for every click as I don't expect the user to stay authenticated in the browser if zhe has logged out from SAP's Successfactor (or any other app linked with Azure).
Please advise, if I should generate refresh_token? Is it a good architecture?
Access token is used to prove the request is allowed to access the resource(such as api from ms or your custom api) and refresh token is used to refresh access token to make sure the access token isn't expired. Access token will expire in an hour by default and refresh token has 90 days.
At this point, we can easily find the refresh token is designed for some special scenarios because the expired time for refresh token is much longer than access token's expired time, but we can also generate a new access token in other way such as using msal or sign in again.
As you said in the question, you can generate an access token by one click and you don't expect users to stay authenticated for a long time. So I think it's unnecessary for you to use refresh token.
We are using IdentityServer4 and have an issue on using refresh token.
Here is my client configs:
Grant Types:
client_credentials
hybrid
Access token lifetime:
60
Identity token lifetime:
900
Absolute refresh token lifetime:
240
Sliding refresh token lifetime:
60
Refresh token usage:
OneTimeOnly
Refresh token expiration:
Absolute
I am checking access token life time and when it is about to be expired I use refresh token to get new access token. After 240 second the access token life time does not extension and my client goes to Identity Server and it issues new set of tokens for my client.
I want my user enter username/password after expiration the refresh token buy Identity Server issue new tokens instead of asking credential.
Any Idea?
If I'm understanding correctly you want to force the user to interactively authenticate from your client? If so the max_age=n or prompt=login authorize endpoint parameters can be used to trigger that flow and then you can validate the auth_time claim within your client to ensure it's recent enough.
Currently this is happening without prompting because the user still has a valid IDP session via the authentication cookie. I'd recommend using the above method over and above setting the IDP session to be aligned with your client application session lifetime.