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.
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 am new to firebase.
I don't understand how I can keep the users of my firebase app logged in when the max expiration time of an auth token in 1 hour.
I could use a function that uses the refresh token every hour but what do I do if the users phone isn't charged?
Thank you very much for any help.
A Firebase user's access token (or ID token) has a lifetime of an hour. After signing in the user, Firebase issues a refresh token that is used to get new access tokens if that refresh token is still valid and hasn't been revoked. If you are using the Firebase Client SDKs, they will handle getting new ID tokens as needed for you. Refer to the ID tokens documentation for more information.
An ID token essentially states "within the last hour, I have confirmed that I am this user".
If you are making use of Custom Authentication tokens from an Admin SDK, the token you give out to the caller also expires in an hour, but should be exchanged for a refresh token before it expires. Like described above, this new refresh token is used to request new ID tokens as they expire.
Firebase uses multiple token types to manage the authentication state of the user. The shortest lived of these (known as the ID token) expires an hour after it was created, but all Firebase SDKs actually automatically refresh that ID token before it expires.
This is handled for you behind the scenes, so in practice you shouldn't have to worry about token expiration - and your code can just get the currently signed in user everywhere it needs.
I am integration Salesforce OAuth in my application. After mapping users' Salesforce account with our application account I saved access token in DB. When user make request to fetch data from his Salesforce account I just use that token to get data. Sadly, token has expiration time (max 24 hrs). After token is expired user has to again connect salesforce account with our app.
Is there anyway to keep salesforce session alive for unlimited time or any other way to avoid repeated login?
I think what you are looking for is a Refresh Token process. Although you can control the expiration time, as you said there is certain limits you can't pass. Instead you can send a request to your org that can obtain new Session ID for you.
Example:
POST /services/oauth2/token HTTP/1.1
Host: https://login.salesforce.com/
grant_type=refresh_token&client_id=3MVG9lKcPoNINVBIPJjdw1J9LLM82HnFVVX19KY1uA5mu0
QqEWhqKpoW3svG3XHrXDiCQjK1mdgAvhCscA9GE&client_secret=1955279925675241571
&refresh_token=***your token here***
Note that this does not work if you are using username-password OAuth authentication flow. Check this dev documentation for the parameters you can use for Refresh Tokens and what responses can it return. - https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_refresh_token_oauth.htm
It is not possible to make sure that user session never expires. However, you can setup the session timeout value to a maximum of 24 hours.
I agree with Iojo. I implemented the similar requirement to save the Token in DB and reused it for multiple API callouts.
Note: In my case - for all the API callouts - Authentication layer are taken care by same middleware. Additionally, I am using username-password for access token where, clearly, I cannot use refresh token.
What I did for Access Token with token
saved in DB?
//Please create a re-usable method in the Rest handler to Retrieve Token
private string getToken(){
If(Token created within Session Timeout Limit){
//Use encrypted token given in the DB
}
else{
//reuse code to generate new token
//save the encrypted token in the DB for future use
}
}
Benefits:
You need to generate Token just one time within given Session Timeout Limit
Re-use the same if there are multiple API calls in salesforce
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'm using OAuth 2.0 to log in users in my website. Just like any kind of website, e.g. Google, Asana, etc. .
What I would like to know is if there is a way to revoke ONLY the access token and not the refresh token when the user logs out.
This is what I do:
when a user logs in, I create a session and obtain the access token (and the refresh token if the user logs in for the first time). When the user logs out, I just invalidate the session but the access token is still valid.
Sure, the access token will invalidate after a while or when the user logs in the web app again but what I want to know is if the access token can be invalidated during the log out process.
There's no generic answer to this question as the implementation of token revocation behavior wrt. related tokens is Authorization Server specific. Google will invalidate the refresh token together with the access token that is being revoked, other implementations may choose not to do so. Yet other implementations may not even offer a way to revoke access tokens at all.
For Google you can revoke the access token upon logout as described in https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke but it will also revoke the associated refresh token. You must then go through the authorization code flow again to get a new refresh token, which you could try with prompt=none to avoid the user being prompted.