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"
Related
I would like to ask the user to authorize my application only once and then be able to use his credentials to make DocuSign API call even when he is not connected to perform automatic operations.
I am currently using Authorization Code Grant but how can i do to never ask the user to authorize my application again ?
An excellent question. Here's an answer:
When using authorization code grant with the user, include scope extended in addition to scope signature
After the user authenticates and grants consent, your app will receive an access token (good for 8 hours) and a refresh token (good for 30 days).
Then when your app needs to use the DocuSign API, use the access token (whether the user is present or not). If it doesn't work then use the Refresh Operation to obtain a new access token (good for 8 hours) and a new refresh token (good for 30 days from the time of the refresh operation)
Result: Your app will always be able to use either its current access token for the user to do operations on behalf of the user, or will be able to get a new access token for use.
Caveat: Your app will need to use the refresh operation at least once every 30 days otherwise the refresh token will expire. In that case, the user will need to re-authenticate via your app and the Authorization Code Grant flow.
Corner cases: Since the user can withdraw consent at any time, your app should gracefully handled that case.
Note Since the refresh token lasts 30 days, you'll want to store it in durable storage (eg a DBMS), not just in memory.
I'm creating an app that integrates with several 3rd-party Oauth2 providers (think Zapier). The user adds a connection through Oauth2 which gives me a refresh token and access token and which I'm storing in a database.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection? If the user doesn't use my app for several days I'd like to still be able to access his 3rd-party data without having him to go through the Oauth2 consent.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection?
Not necessarily. Wait till your API call fails. Check for a proper response such as "401 Unauthorized" which hints your access token is invalidated/expired. Once this happens use refresh token to renew the access token. If refresh token fails, then you have to fall back again and ask user to login again.
A refresh token can have a varying life time. It can be from few days to few months. For example check Google's explanation mentioning long lived refresh tokens and possible expiry of them. Also check how Azure AD mention about configurations related to token lifetimes.
So user not using app for few days (ex:- leave it and return after weekend) can be handled through proper validity configurations of tokens lifetimes. But be mindful about threats that could occur from long-lived, unmanaged tokens (ex:- due to token stealing).
The Oauth website has a pretty informative answer
The “expires_in” value is the number of seconds that the access token
will be valid. It’s up to the service you’re using to decide how long
access tokens will be valid, and may depend on the application or the
organization’s own policies. You could use this timestamp to
preemptively refresh your access tokens instead of waiting for a
request with an expired token to fail. Some people like to get a new
access token shortly before the current one will expire in order to
save an HTTP request of an API call failing. While that is a perfectly
fine optimization, it doesn’t stop you from still needing to handle
the case where an API call fails if an access token expires before the
expected time. Access tokens can expire for many reasons, such as the
user revoking an app, or if the authorization server expires all
tokens when a user changes their password.
If you make an API request and the token has expired already, you’ll
get back a response indicating as such. You can check for this
specific error message, and then refresh the token and try the request
again.
TLDR: I would only refresh the token when a request fails
I have implemented openid connect authentication using azure active directory in my website. The session expires every 1 hour. So the user is logged out, and redirected back to the login page. While analyzing based on it, i have found a solution in the below link, to use UseTokenLifetime = false
https://github.com/aspnet/Security/issues/147
Will this fix my issue? or is there any chance of increasing the session time?
Thanks in advance
Dinesh
Read here to learn more about Configurable Token Lifetime
In general, access tokens have a very short lifetime. This is intentional. Your web application should be using the refresh token which comes with your access token to acquire new access tokens once the original one expires.
When you get an access token and refresh token (assuming all default settings), the access token will last up to one hour. The refresh token will allow you to get a new access token + refresh token pair for up to 14 days. The new refresh token you get will last another 14 days, allowing you to chain new access tokens up to a total of 90 days, where you will need to eventually ask the user to sign in again.
You have the ability to configure token lifetimes such that your "refresh token chain" will never expire, however any individual access token or refresh token will eventually expire.
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 would like to request Uber cabs on behalf of an Uber user, but first the user needs to permit the app to have access to his profile and permit the app to send requests on his behalf. However, the returned authorization code that I can use to get the access token in order to send user requests on their behalf is only valid for 10 minutes and my requirement needs me to send requests even 24 hours later.
Is there a way to get a permanent authorization code or access token that never expires or at least one that lasts for a long period, e.g. a month?
RFC 6749 says as follows in 4.1.2. Authorization Response:
code
REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code
Therefore, it is hopeless to expect an authorization code with longer lifetime than 10 minutes. So, you should exchange an authorization code for an access token at the token endpoint immediately using the way described in 4.1.3. Access Token Request.
If Uber's authorization server issues a refresh token when it issues an access token, you can expect it has longer lifetime than an access token. You can use a refresh token at the token endpoint in order to get a new access token. See 6. Refreshing an Access Token for details.
If lifetime of access tokens and refresh tokens issued by Uber is less than 24 hours, you have to change the flow of your application.