[oauth.token_renewal]
renew_access_token_per_request= "true"
I set this to the deployment.toml file in wso2 IAM. I generated access token, use it in a API it works fine, When i regenerate access token, the old one should get expires but in my case it does not expired. And if i does not hit api for 4 to 5 minutes it get expired due to renew property
I want that if access token regenerated the old one should expired instantly.
Related
I'm using directus to grant users access to ressources required by an SPA written in Angular. To authenticate users I created an auth service and interceptor to handle sessions and attach the "Authorization" header. Those services work fine and login as intended. But here comes the problem:
Directus session times are configured with default values (15 min validity for access_token, 7d for refresh_token) but as soon as the access_token expires I cannot retrieve a new one using the refresh token. This bugs me, because the goal is to keep users logged in for the next 7d (refresh_token lifespan) or until logout if they check this option.
My attempts at achieving this:
Since i'm using graphQL, i tried the "auth_refresh" mutation from the authentication documentation. While the access token is still valid, refreshing works fine. After the access token expired there is no way to retrieve a new one via a valid refresh token.
Alternatively I tried to achieve a refresh via the POST request specified by the docs (to double check if it was some sort of config error with graphql) but I encounter exactly the same problems as with graphQL. Directus returns either "401 unauthorized : Token expired."
if i extend the lifespan of the access token for longer than the server defined lifetime,
Response: Sending a token with prolonged life
or "401 unauthorized : Invalid user credentials." if I request a new token without an
"Authorization" header.
Response: Sending no access token
The refresh token is correctly loaded and sent to the server as specified in the docs in both
cases.
Now my questions are:
Am I missing something? I haven't found any further specification in the docs and the Auth0 protocol specifies that a new access token should be retrievable with a valid refresh token.
If this feature is not intended: How could I achieve a "keep me signed in" option with directus? I would like to keep user rights management in one place and do not really want to handle user auth redundantly for my current use case.
2b. Why is the lifespan of the refresh token so much longer than the lifespan of the access token if this isn't intended?
One of my thoughts is, that it has to do with access rights of the "public" role on the "directus_sessions" table. But I can't think of a way to grant only read rights for owned/received tokens, since there are no payload variables available inside the filters. Could this be the cause? Would there be a way to achieve this?
Thx&Greetz
I have a very simple ADFS environment with Angular ADAL app getting the JWT successfully.
No matter what setting i change with "set-adfsproperties", token always expires after one hour.
and that is forcing adal to retrieve a new token each hour.
I would like to token to live for 24 hours to avoid the refresh delay in the UI.
Has anyone been able to change the token expiration beyond the 1hr default?
Try:
Set-ADFSRelyingPartyTrust –TargetName "display name of relying party" –TokenLifetime 1440
To check the new value to make sure it is set do:
Get-ADFSRelyingPartyTrust –Name:"display name of relying party"
See:
ADFS 3.0 using OAuth and Persistent Refresh Tokens
https://blog.fullscope.com/increasing-adfs-token-timeout-time-for-microsoft-dynamics-crm-2011
Maybe a simple question.
Lets say that the user receives the bearer token and has an expire time of 1 day.
the user makes calls to the web api and then stops making calls say after 6 hours.
Then if the user makes a call to the web api does that auto refresh the token and then the user has another 24 hours to use the token or will it definatly expire based on the first get of the token.
thanks
Once issued, the token cannot be changed and will be valid until it expires. It doesn't matter how or when the token was used or even if other tokens were requested in the meantime.
Since the token cannot be changed, the expiration of the token cannot be extended. The token can however be revoked before it expires, based on other factors, if the server is configured to do so.
It may not be possible to extend the token itself, but it is possible to request a new token without having to send the credentials.
You can configure the server to add a refresh token to the token. Please note that this is not available for all grant_types. In case of a refresh token the normal token has an extra parameter 'refresh_token' that contains an additional token with its own expiration time. This token can be used once the normal token is expired. In that case a new token can be requested with this refresh token, without having to send the credentials.
When pulling information from the LinkedIn API, the access token will randomly expired, and the application will not be able to pull the information from the API. This issue randomly occurs after an extended period of time. I am trying to determine whether this could possibly be coming from LinkedIn's side. Is there any way to verify?
According to the LinkedIn documentation, you should receive the expiration date of the access token in the same request you receive the token.
Access Token Response
A successful Access Token request will return a JSON object containing
the following fields:
access_token — The access token for the user. This value must be kept secure, as per your agreement to the API Terms of Use.
expires_in — The number of seconds remaining, from the time it was requested, before the token will expire. Currently, all access tokens are issued with a 60 day lifespan.
One thing to keep in mind is that access tokens can be manually revoked by the user:
Invalid Tokens
If you make an API call using an invalid token, you will receive a
"401 Unauthorized" response back from the server. A token could be
invalid and in need of regeneration because:
It has expired.
The user has revoked the permission they initially granted to your application.
You have changed the member permissions (scope) your application is requesting.
Since a predictable expiry time is not the only contributing factor to token invalidation, it is very important that you code your applications to properly handle an encounter with a 401 error by redirecting the user back to the start of the authorization workflow.
One thing that is not mentioned on this page, as #JustinKominar mentioned, is that only your most recent access token is valid. That means requesting a new access token will invalidate all of the previous ones, so make sure that your tokens are up to date!
I am configuring Azure ACS with "Google" configured as IdP in my application. My requirement is that I do not want the IdP login page to be displayed every time I try to log into my application. I have set my ACS token lifetime to the maximum period so that my token is valid for a day.
First time when I log into my application and I select "Stay Signed In" in Google login page, I am able to log into my application. I now close the browser, reopened the application, I am successfully rediercted to the application home page without any credential request. (as ACS internally uses the session token created intenally which will be used in next requests)
But if I do not select "Stay Signed In" in IdP login page, and proceed the same steps, I am asked for credentials. Any idea why is this happening? Is there a way I can manipulate the session token and validate the ACS token which was earlier issued to me ?
When you select "stay signed in" at Google, it writes a persistent cookie, meaning that you'll stay logged in even if you close your browser. By default, your application's cookie is scoped to the session (assuming you're using WIF). When you close and reopen your browser, the original token and cookie are gone. Your browser redirects to ACS, which redirects to Google, which redirects you back again because of the persistent Google cookie. Running your session using Fiddler or HttpWatch should show that, even when you choose "stay signed in", you're still being sent back to ACS and Google and getting a new token.
It sounds like what you want is your RP to "remember" the user so they don't have to log in again within the token lifetime. To do this, your federated cookie (the one with the token in it) needs to be set as persistent, rather than session. If you're using WIF, this can be done using CookieHandler configuration on the FederationAuthenticationModule (see PersistentSessionLifetime).