I need to know the time remaining in the Access Token and not the ID token or the token for browser flows. Checking the expiry of the token on http://www.jwt.io always returns 24 hours. However, the Access Token for the API should be longer than that. How can I check the expiring date?
If the authorization server provides an endpoint to get information about the token (the ideal would be to have an Introspection endpoint as per the RFC7662), then it is easy to have this information.
Otherwise, if no endpoint is available, you have to keep in you memory the value in the expires_in parameter of your access token response (see RFC6749 section 4.1.4) and add the current timestamp to this value to get the exiration timestamp.
Please note that the access tokens you receive may be revoked by the authorization server thus the token will be invalid before that expiration time.
Another possibility if the access token is a signed Json Web Token (JWS - see RFC7515), you could parse the token and check the exp claim (optional, but usually present in such context).
Related
When I retrieve a token from Azure IDP for to be authenticated and authorised to hit one of our services on Azure, the payload includes an "access_token", which has a value in JWT format. It also includes a "refresh_token", and its value is not in JWT format and does not decode, hence failing token validation that our app runs after getting the payload back from IDP.
What should be changed in the manifest? Token format is 0.x.x instead of eyxxx.x.x. I believe the 0 is where the eyxxx should be for token headers?
The refresh token is not meant to be decoded or validated in your client application. It is just a random string issued and that you can return to get a new set of access and refresh tokens.
The client should not care about what it contains or how it is structured, it is just a piece of data.
According to the specification here, it says:
A refresh token is a string representing the authorization granted to
the client by the resource owner. The string is usually opaque to the
client.
ie, the refresh token is never inspected by the client, its just a blob of data that you pass back to the authorization server to get new tokens.
I am creating node.js/express project. Authentication is done based on JWT. Details:
When user log in, in response there is access token (validation: 15 minutes) and refresh token (validation: 24 hours). In payload of each token there are user's most neccessary data and unique identifier which is used to make these token kind of pairs. These tokens are "bond". On logout this identifier is put on blacklist - for more read below.
In each request I check access token: a) if token is real token (not faked one), b) if it is expired or c) token contains in its payload an unique identifier which was put on the blacklist. In case access token expired check out no 3 below.
When access token expired, there sie /refreshToken endpoint where user can refresh both access token and refresh tokens. In case unique identifier is in the blacklist token will not be refreshed and user should re-authenticate.
And finally, there is /logout endpoint where user pass access token in request. And again, if unique identifier is in blacklist there is error in response. However if access token is valid, unique identifier is put on the blacklist and user is logged out.
What I need to mention here is I do not store refresh tokens in database as in many other solutions. All is based on unique identifier.
Basically, my goal was to be sure that when user logged out (access token in request), no one will use refresh token to regain access token. In this solution both tokens should be useless.
What do you think of this flow. What do you think of unique identifier which pairs both access and refresh token?
Would you improve that in any way?
Can we use the same access token to request another app resource or validate Token. What happens after 3599 seconds to an access_token? can we still use it?
How many times we can use the same refresh token? (Is there any way to restrict to one time if possible)
How to check if the existing access_token and refresh_token were valid ones or not?
Please help.
PAVANSAI C
Can we use the same access token to request another app resource or validate Token. What happens after 3599 seconds to an access_token?
can we still use it?
When you acquire an access token, it is only meant to be used against certain resources (you specify them when you request a token). You can't use that token for any other resources. Generally an access token is valid for an hour (3600 seconds) but that's configurable at Azure AD level. Once this time period expires, you can't use that token anymore as using it will throw an error.
How many times we can use the same refresh token? (Is there any way to restrict to one time if possible)
Similar to access token, there's also an absolute expiration for refresh token (it is usually 14 days). When you use a refresh token to get a new access token, you also get a new refresh token. You should be using the new refresh token instead of an old one.
How to check if the existing access_token and refresh_token were valid ones or not?
A successful response to an access token request will include the number of seconds the returned access token is valid for (expires_in), as well as the time at which the access token will expire (expires_on). Use these to keep track of whether the access token is still valid or not.
Note: You should consider using client libraries such as MSAL, which will do this automatically. Your code only needs to ask for a new token token, and the library will take care of figuring out if the last token received is still valid, or if a new one is needed.
Another possibly way to test it is try to use the access_token/refresh_token in an operation and catch the exception. Try to parse the exception to figure out what's wrong with the token. For example, if an access token has expired and you use it you will get an error telling you exactly that. That would be an indication for you to get a new access token using the refresh token. (This approach relies on the resource provider (i.e. the API) to return a message that clearly indicates that the token is expired, which is not always the case.)
I have list of services registered in Azure AD. Is there a way to generate a single MSI token by passing list of MSI ApplicatonIds and generate a token which has all the ids in the audience field.
No, this is not possible. One token will only include one audience.
Note that if you're using an interactive authentication flow, you can use the refresh token associated with the token for one audience, to get a token for another audience. This means you only have to authenticate once.
From the v1.0 docs:
Access Tokens are short-lived and must be refreshed after they expire to continue accessing resources. You can refresh the access_token by submitting another POST request to the /token endpoint, but this time providing the refresh_token instead of the code. Refresh tokens are valid for all resources that your client has already been given consent to access - thus, a refresh token issued on a request for resource=https://graph.microsoft.com can be used to request a new access token for resource=https://contoso.com/api.
From the v2.0 docs:
Access_tokens are short lived, and you must refresh them after they expire to continue accessing resources. You can do so by submitting another POST request to the /token endpoint, this time providing the refresh_token instead of the code. Refresh tokens are valid for all permissions that your client has already received consent for - thus, a refresh token issued on a request for scope=mail.read can be used to request a new access token for scope=api://contoso.com/api/UseResource.
We have a standalone Java application (see "Installed application") which runs periodically and uses Google API (updates some information from customer databases/ldap/...).
To access Google APIs we store username and password in configuration file, which is a security risk and customer does not like that. So we would like to use OAuth2 long-living access token instead.
What`s default expiration time for Google OAuth2 access tokens ?
As we will have only access token in application, app itself cannot refresh it when access token expires.
Personally I think that OAuth2 implementation in this case will not bring any major benefit but let`s focus on main question - default expiration times.
You shouldn't design your application based on specific lifetimes of access tokens. Just assume they are (very) short lived.
However, after a successful completion of the OAuth2 installed application flow, you will get back a refresh token. This refresh token never expires, and you can use it to exchange it for an access token as needed. Save the refresh tokens, and use them to get access tokens on-demand (which should then immediately be used to get access to user data).
EDIT: My comments above notwithstanding, there are two easy ways to get the access token expiration time:
It is a parameter in the response (expires_in)when you exchange your refresh token (using /o/oauth2/token endpoint). More details.
There is also an API that returns the remaining lifetime of the access_token:
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token={accessToken}
This will return a json array that will contain an expires_in parameter, which is the number of seconds left in the lifetime of the token.
The default expiry_date for google oauth2 access token is 1 hour. The expiry_date is in the Unix epoch time in milliseconds. If you want to read this in human readable format then you can simply check it here..Unix timestamp to human readable time