the documentation from this link, said that Refresh tokens have a longer lifetime than access tokens, and you can use them to get new access and refresh tokens.. How long exactly before the refresh token expires in terms of seconds.
Thanks in advance.
[I work for DocuSign. I consulted with the DocuSign Authorization engineering team to prepare this answer.]
The lifetime for refresh tokens vary depending on a variety of authentication policies.
After it expires, the client uses the Authorization Code Grant flow to request new tokens.
Since the human needs to be present whenever the Authorization Code Grant flow is used, this authentication technique should only be used for integrations where the authenticated user is present ("User Applications").
Other authentication techniques should be used for "Service Integrations."
Added
Not all Refresh Tokens in the DocuSign system have the same lifetime. Some will last for x amount of time, others will last for y amount of time. Why some will last for x and others for y depends on various authentication policies:
DocuSign platform policies
Account (customer) policy
The type of authentication that was performed when the user logged in
Etc
Re: other companies just use "14 days." DocuSign authentication enables the authenticated person to sign legal documents. So the question of the DocuSign token lifetime is not simple.
Bottom line: test your app to ensure that it gracefully handles expiration of both access and refresh tokens.
Added Aug 2018
Access Tokens received via the OAuth Authorization Code Grant flow usually have an 8 hour life. The accompanying Refresh Token usually has a 30 day life.
If extended scope is not requested in the authentication flow, then the Refresh Token, when used will return a new Refresh Token that will have the same expiration date as the original.
But if extended scope is requested, then, when the Refresh Token is used, the returned (new) Refresh Token will normally be good for an additional 30 days from that time.
So if extended scope is requested, and the user logs in at least once every 30 days, then the original and newly provided Refresh Tokens will enable the user to never have to re-authenticate himself or herself.
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
In order to access resources in Azure AD web applications we retrieve an authorization code using the following workflow:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code
Now my questions is, does this retrieved code also have a specific lifetime (like tokens have) or will it never expire? I guess it won't expire but I need to be sure about that.
Yes, the authorization code has a lifetime of 10 minutes I think.
You use it to get the tokens you need and then throw it away.
You'll get refresh tokens so you can use them to get more tokens later.
ADAL.NET for example handles the token refresh for you, assuming you properly implement a token cache.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-id-and-access-tokens (scroll all the way down) (it's for the v2.0 endpoint, but codes are similarly short-lived in v1)
Authorization codes (work or school accounts)
10 minutes
Authorization codes are purposely short-lived, and should be immediately redeemed for access tokens and refresh tokens when the tokens are received.
Most of our clients are having no issues whatever with our system. We have an integrator key and our users do an initial link up for integration using OAuth on REST. We store the access/refresh tokens. Works fine. At some point down the road some clients seem to randomly hit this.
We are using OAuth with the REST API and always get a new access token using the client's refresh token if their access token is within 30 minutes of expiring.
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
Q: Can the refresh token expire such that they would get this?
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
If you get this error then you need to restart the oauth flow again.
A refresh token does expire at some point. When it expires is a policy issue. To achieve the longest possible refresh token lifetime, request scope extended in addition to signature.
Re:
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
A: I'm surprised that you're getting this specific error, but I haven't tried this for awhile. I'd think the error would have a different name.
Q: Can the refresh token expire such that they would get this?
A: Same answer as above re the specific error name. In any case, a refresh token can definitely expire. Requesting the extended scope should minimize this, but at some point an account may set a policy that will also expire extended scope refresh tokens. Bottom line: your app needs to be prepared to ask the user to go through the entire OAuth Auth Code Grant flow again.
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
A: Using the wrong base url for the user. Also, at some point there will be organizational controls that can force policies upon the org's accounts. (Organizations own and control accounts.)
I was going through Oauth2 docs and thought it was kind of permissive security wise, so i tried to implement JWT tokens with a special scheme like in the picture for a mobile app communicating with a web API.
Notes : i didnt like Oauth2 refresh tokens idea as they might get stolen and allow parallel usage (by legit and malicious users) unless you implement theft detection by rotating them (refreshing refresh token upon each request) in this case why use them at all ?
How the auth flow works :
A user logs in with credentials gets a jwt of 20 minutes lifetime.
Upon expiry the jwt gets refreshed by hitting the db checking if it's blacklisted (relogin) and if not check if it was used to generate a new token.
If it was never used to refresh it is accepted and used to issue a low grade access token.
If the token was used before, or had different client+device+user than its parent offer a credential check (password or lockscreen code)
If passed, this check issues a new first grade token that blacklists all its parents and children on the db, its like a new first user login.
If lockscreen fails the user is presented with login screen.
The questions are :
What are possible security holes ? (I found two use cases : stolen valid access token lasts 20 minutes same issue as Oauth tokens. No gain no loss here. And stolen sleeping token : user not logged in for say 7 days, token gets stolen and used until user logs in again or token chain revoqued after 3months of persistance - our policy - and this theft has small chances since token has to be intercepted at the last request the user makes on the app , slimmer than stealing an Oauth2 refresh token )
What are user experience problems an attaker can cause on the app while on this scheme ?
OAuth2 refresh tokens are not meant to be used by mobile clients. Using refresh tokens requires client credentials, which cannot be stored securely in a mobile application.
Refresh tokens are used from confidentials clients (server side web applications for example). They are often renewed when used (server sends back new access and new refresh token). In contrast to access tokens, the refresh token is only sent to the authorization server, not the resource (API) server.
Regarding your auth flow. Step 2 is the weak link IMO. You allow the client to use an expired token to generate a new access token. So if I find your phone and access the device, it will allow me to get a fresh access token and impersonate you.
You could force the client to refresh the token every say 15 min., but then you have to define what happens if the app gets closed or the device is turned off? Is it okay to re-authenticate the user again?
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