I'm using docusign developper account to test docusign restapi. Howerver, the token provided expires in 8 hours. I wanna know if i pay for an api plan, will I get a token with longer expiration time?
I'm afraid not. Tokens in production also expire after 8 hours.
You would need to use the refresh_token to obtain a new token. This technique is part of OAuth security best practices.
Here is an article that explains how to do this:
https://medium.com/brandsoft/using-a-refresh-token-to-obtain-an-access-token-from-docusign-3c297eb51886
Related
I am design the app auth api with auth2.0, now I found some companies set the refresh token expire with 10 years! why design like that? it is a good practice? how long should I set the refresh token expire time?
I found the google oauth 2.0 refresh token never expired for native app: https://developers.google.com/identity/protocols/oauth2/native-app
It all depends on how often you want to to force the user login again and reauthenticate.
In some system you want the user to do this more often and in a system with for example 10 years refresh token, you don't want the user to have to login again after the first successful authentication.
It's a bad idea to set the liftime of refresh_token to 10 years like that you have a big security problem, the best implementation of refresh_token is when it is used the first time it should be revocked or a lifetime not much than access_token.
see my other answer here
In my application I am using OAuth 2 authorization and get access token from access code which expires after 8 hours. Is there any way I can increase this expiry time. Default expiry time I get is 28800(8 hours), I want it to be like for 30 days or 60 days. Is it possible. I know this is possible with Implicit grant flow but if I want to continue with Authorization code grant flow then, Is it possible?
Thanks.
You cannot increase the life of Access token beyond certain limit due to security reasons. These tokens are supposed to be short lived. One thing you can do is allowing issuance of refresh tokens for offline access. So, if access token is expired/about to expire, client (Secure) can talk to Authorization Server and get fresh access token issued.
You won't be able to modify the token itself as it's signed by the STS before being issued to you. If you were to modify the field itself, signature validation would fail when you bear the token. As dvsakgec said, this token is meant to be short lived and the correct pattern is to use the refresh token to obtain fresh access tokens when it has expired. For most identity providers, the refresh token never expires so you can always get a new access token.
Now, some identity providers will allow you to configure the token through their developer tools. It depends on the provider. There is no hard line guide for token expiration, it's whatever the identity provider decides.
I have integrated tokbox in my app for live call, signaling.
My problem is session & token expire at every 1 hour. So is this valid?
What is the validity(time limit) of any session & token?
How to solve this problem
please guide us.
thank you.
OpenTok sessions do not expire. However, authentication tokens do expire. Also, note that sessions cannot explicitly be destroyed.
OpenTok tokens expire after a set period of time (max up to 30 days). You can specify the expiration period when you generate the token. Read this https://tokbox.com/developer/guides/create-token/
While working on a test version of your app, you can obtain a test session ID and token using the Dashboard page. But every production OpenTok application should be generating these values dynamically on a server, using one of their many Server SDKs (PHP, node, Ruby, Python, .NET, Java)
I need to understand if a refresh token from OAuth 2.0 for Google data expires or not if unused for more than 6 months?
At many places it is called out that it doesn't expire and at some places it is said that it will expire if unused for 6 months.
For example, in this question, the accepted answer says that it never expires but one of the comments suggest that it can expire if unused for 6 months.
This Google doc calls out that refresh token will never expire while this doc says it can expire if not used for 6 months.
Although I am using a safety check for the cases where refresh token is expired due to any reason, but still want to make sure I understand the behavior correctly.
You are correct the two pages Using OAuth 2.0 for Web Server Applications and Using OAuth 2.0 to Access Google APIs don't have the same information.
Using OAuth 2.0 to Access Google APIs is correct.
You should write your code to anticipate the possibility that a
granted token might no longer work. A token might stop working for one
of these reasons:
The user has revoked access.
The token has not
been used for six months.
The user account has exceeded a certain
number of token requests.
There is currently a 25-token limit per Google user account. If a user
account has 25 valid tokens, the next authentication request succeeds,
but quietly invalidates the oldest outstanding token without any
user-visible warning.
If you need to authorize multiple programs, machines, or devices, one
workaround is to limit the number of clients that you authorize per
user account to 15 or 20. If you are a Google Apps admin, you can
create additional admin users and use them to authorize some of the
clients.
A refresh token that hasn't been used for 6 months will expire.
I have sent in a bug report on the first URL. Google should clear up the discrepancy the next time they go though the documents.
Every time I read https://developers.facebook.com/roadmap/offline-access-removal/, I'm left more confused than the time before. I'm looking for some clarification on some items under scenarios 3 and 4 (server-side apps and client-side apps)
For server-side apps, it states "If the call is made while there is still a valid 60-day access_token for that user, the returned access_token from this second call may be the same or may have changed, but in either case the expiration time will be a fresh 60 days."
What is "the call" that is referred to here?
Is it the same exchange of an authorization code for the access token that takes place during the initial OAuth flow?
Or is it the endpoint call described under the client-side section to freshen the token to 60 days?
If it's the former, then where does the authorization code come from when trying to renew the token?
Is it the same authorization code from the original callback or do I have to go through the authorization flow again?
In short, can a server-side app keep freshening the life of a 60-day token and, if so then how?
Regarding client-side use, the document indicates that the client must make that endpoint call passing in (among other things) the application's client ID and client secret.
My interpretation of "client-side" may be wrong, but I'm thinking in terms of a JavaScript-based client running in a web-browser.
If that's what Facebook has in mind here, then should the JavaScript code really ever know about the client secret? (It won't be much of a secret if it's sent to the client.)
Even then, it indicates that 60-day tokens cannot have their life extended and that a new 2-hour token must first be acquired and used to get a 60-day token. This is under the client-side portion of the document, but does this rule apply to server-side 60-day tokens, too? If not, then I ask again: How do I freshen the life of a 60-day token on the server-side?
Finally, the question that has been burning in my mind for some time: Why has Facebook adopted this strategy and not adopted the refresh token as defined in the OAuth 2 specification (a specification that Facebook is helping define)???
EDIT: Further thoughts/questions after re-reading the document again:
At the beginning it says "a long-lived expiration time that can be renewed each time the user revists your app". My initial assumption is that the way to renew it would be to make a call to the endpoint later in the document. But, aside from the fact that the endpoint is described under the "client-side" heading, it also states "Please note, the endpoint can only be used to extend the short-lived user access_tokens. If you pass an access_token that had a long-lieved expiration time, the endpoint will simply pass that same access_token back to you without altering or extending the expiration time." (The typo on "long-lieved" is from FB's own documentation.)
Okay, so if that endpoint cannot be used to renew the expiration time (and my own attempts to renew a long-lived token with that endpoint prove this out), then how can I renew the expiration time on a long-lived token each time they visit my app?
Is there no one who understands how this is supposed to work?
After reading Facebook's doc (like for the 5th time) and with the help of this question/answer this are my conclusions.
What is "the call" that is referred to here?
It referres to the OAuth call to get an access token.
Is it the same exchange of an authorization code for the access token
that takes place during the initial OAuth flow?
Yes, I believe it's that flow.
Or is it the endpoint call described under the client-side section to
freshen the token to 60 days?
No, that endpoint is only valid for short-lived access tokens.
Is it the same authorization code from the original callback or do I
have to go through the authorization flow again?
You've to go through the authorization flow again.
how can I renew the expiration time on a long-lived token each time
they visit my app?
Long-lived access tokens cannot be renewed using the client side endpoint. The user will have to reauthorize the app to get a new one.
According to Facebook documentation:
If the call (OAuth authorization call) is made while there is still a valid long-lived user
access_token for that user, the returned user access_token from this
second call may be the same or may have changed, but in either case
the expiration time will be set to a long expiration time.
Once the application is reauthorized you'll get a new expiration time. Facebook may return a new long-lived access token, so you should grab it and replace that information for the one you already had.
Conclusion:
Seems there's no way to renew a long-lived access token without user intervention. To get a new expiration time/access token they'll have to reauthorize your app. My humble advice is that should suggest the user to reauthorize it, a few days before the expiration date.
Also, this Facebook how-to can came in handy for checking expired access tokens.