I read the comment "// Sometimes we won't get a refresh token after upgrading a code." in the sample DrEdit code https://code.google.com/p/google-drive-sdk-samples/source/browse/java/src/com/google/drive/samples/dredit/CredentialMediator.java line 292.
What does "sometimes" mean? Is there a document that describes the circumstances under which I will and won't be blessed with a refresh token?
Refresh tokens are supplied under two conditions:
A refresh token was requested with offline=true
The request was not auto-approved
In other words, the first time the user authorizes your app and you have offline=true set, you'll get a refresh token. Subsequent authorizations will for that user will be automatically approved unless the user revokes access. Refresh tokens will not be issued in this case.
If you need to force a refresh token to be issued, add approval_prompt=force to the request.
Related
In my web application I am using access and refresh tokens to authorize user access to protected resources, the flow is as following:
The user, through a mobile app, sends a request to the "auth/token" endpoint providing his credentials. The server authenticates the user and issue an access and refresh token. The refresh token is saved in a whitelist to be able to revoke it later on, if necessary.
Upon access token expiration, the mobile app sends the refresh token to the "/token/refresh" endpoint presenting the refresh token. A new access/refresh token pair is created and the old refresh token is invalidated ,implementing in this way the token rotation.
Now the problem:
Let's say that the client refresh the token but never receive a response back from the server because the network is lost. After 30 mins the client tries to refresh again but its token is now invalid and the user is logged out. In the Oauth implementations we can set a time for the old token after which this will be invalidated, giving the possibility to the mobile app to resend the same refresh token if any problem occurs. But I do not think this is a solution because we can't be sure of when the mobile client will retry to refresh the token. It can be in some minutes, hours or worse also days.
How do you approach this problem?
The first solution I could think of is increasing expiration time.
I have two accounts for docusign, live and demo. The demo one hasn't been used in a while, in fact the last time a refresh token was created was the 14th November. I'm therefore assuming it has expired and is potentially stopping me from getting a new one.
When I make a request I get the invalid_grant error. The same code (with testing credentials) works fine with my live account which requests a live token every couple of days or so. It also did work fine on with the testing credentials until it wasn't used for a prolonged period.
I assumed I need to get hold of a new refresh token but without a valid previous token I'm not sure how to go about this.
The following applies to DocuSign's OAuth2 authentication service:
When you use the refresh token to get a new access token, you also get a new refresh token. But see the following:
If your original OAuth request only included the signature scope then the expiration date of the new refresh token will be the same as the original refresh token (30 days).
However, if you request both the signature and extended scopes, then your new refresh token will expire 30 days from the time that you refreshed it.
So the way you can continue to get a new access token without requiring the user to authenticate again is:
User authenticates with the signature and extended scopes. Your app exchanges the auth code for an access token (good for 8 hours) and a refresh token (good for 30 days).
Within the 30 day period, refresh the access token. This also gives you a new refresh token, good for a new 30 day period.
Rinse and repeat. As long as you get a new refresh token at least every 30 days, you can keep going forever.
Caveat: For InfoSec reasons, the end user, their admin, and/or DocuSign might invalidate all existing refresh tokens. This is an unusual corner case but can happen. Easiest way to test the corner case: remove the user's consent for the app.
You cannot refresh a Refresh Token if the Refresh Token has expired or otherwise been revoked. You must repeat the authentication flow to obtain a new Refresh Token.
Once I've completed the OAuth flow by obtaining authorization from the user and then creating an access token, how do I obtain another token without asking the user for authorization again? I thought the user's account on Smartsheet would remember that they trusted the application, but that doesn't seem to be the case. I'm new to OAuth so I'm sorry if I'm missing something obvious.
Thanks!
Access tokens retrieved via the OAuth flow are valid only for a certain period of time -- you (i.e., your application) can refresh a token before it expires in order to prevent the end-user from having to provide authorization again.
When you issue a GET Token request to obtain an access token, the response contains not only the token itself, but also information to indicate how long the token is valid (the expires_in property indicates the number of seconds until the token expires) and a refresh_token property value that you'll need in order to refresh the token.
To prevent the user from having to provide authorization again, simply refresh the token before it expires, and then use the new (refreshed) token value in subsequent API requests. Note that each token you obtain (whether it's the original token or a refresh token) will always expire in a finite amount of time, thereby requiring that you refresh the token in order for your application to maintain user authorization.
I am implementing an oauth server using spring oauth. I notice that spring's implementation re issues the same access token if not expired from the token endpoint. However the behavior is different while refreshing access tokens. A new token is reissued each time, are there any concerns to keep in mind if I were to reissue the same un expired access token on receiving a valid refresh request.
The OAuth Spec section-6 specifies that:
The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
There does not seem to be a requirement that the access token is brand new.
I think the main concern is to ensure that you do not change the expiration date on an existing token. And that you correctly return to the client an accurate expires_in property which reflects when the token will expire.
In addition, it might make the semantics confusing for clients. The refresh is usually done when a token is expired, and the client wants a new one.
I can imagine some odd edge cases. A client could send a request to refresh a token a few seconds before it is expired (perfectly valid logic for a client), but still receive back the same token which is almost expired.
I'm developing an Android app that uses Outlook Calendar REST API. I'm trying to keep in synch and updated the calendars of multiple users (meeting rooms).
My questions are:
1) After how long does the initial authorization code expires?
2) And for the refresh token instead?
The access token expires after 60 mins. I can't get if for the refresh token expires after 6 hours, 14 days or 90 days.
3) Is the latter configurable? Can I make it not expire?
`
UPDATE: (from https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx)
"The lifetime of the refresh token is not provided and varies based on policy settings and the time when the authorization code grant is revoked by Azure AD. The application should expect and handle cases when the request for a new access token fails. In that case, it should return to the code that requests a new access token."
And also: (from http://blogs.msdn.com/b/exchangedev/archive/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-exchange-online-in-office-365.aspx)
"Refresh tokens do not have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action. The client application needs to expect and handle errors returned by the token issuance endpoint correctly. When you receive a response with a refresh token error, discard the current refresh token and request a new authorization code or access token. In particular, when using a refresh token in the Authorization Code Grant flow, if you receive a response with the interaction_required or invalid_grant error codes, discard the refresh token and request a new authorization code."
So how can I guarantee that my App will always have all the users logged in?
It will be in airplane mode during the night and it should automatically recover from crashes as well.
Can I solve without authenticating the users programmatically storing the credentials?
Thanks
Answers:
few minutes. The exact value is an implementation detail and can change at any moment. You should do whatever you can to redeem the code as soon as you get it.
see http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
as of today the lifetime limits cannot be changed. We are working on features that will grant you more control, but we have no ETA to share at the moment
The only way of guaranteeing that a user is signed in is to successfully redeem a refresh token, or to go through an authentication flow. Use of cached credentials is restricted to very few cases, and will likely be disallowed in upcoming versions of the service.
If a refresh token expires, you should plan to perform an interactive authentication. Note that the refresh token might also be invalidated by a consent revocation, which will mandate interactivity in all cases.
What you can do is to obtain the refresh_token and the access_token. Access what you need via the access_token, if that fails then assume it has expired and use the refresh_token to update the access_token. If a user changes their password (or maybe there are other cases) then you start the user over from square one.
To get the refresh_token I think you need to add offline_access to your scope. Something like this:
USER_OAUTH2_AUTHORIZE_URL
+ "?client_id=" + config.getClientId()
+ "&redirect_uri=" + getOutlookLoginRedirect(request)
+ "&response_type=code"
+ "&scope=https%3A%2F%2Foutlook.office.com%2Fmail.send%20" +
"https%3A%2F%2Foutlook.office.com%2Fmail.readwrite%20" +
"offline_access%20openid%20email%20profile"