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.
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 a webapp which lets the user OAuth 2.0 to youtube & after exchanging the authorization code I can capture the access_token & refresh_token into my database .
Can these tokens be maliciously used later by me , say after 2 weeks , to delete the poor user's video using /yoube/v3/delete or some other operation like insert badly formed captions ..
& if this could be done isn't this a security breach cause the poor used who has accidentally consent ouath into my application & got his access_token & refresh_token & other info captureded by my back-end
So basically when someone consents ouath's to an application ...the user is now on the mercy of the application...like information could be stored or deleted or anything
If yes? what can the poor user do to unlink & how would the user even know that video's are getting deleted by someone else ?
Access tokens are short lived tokens which will work for one hour after that time you will need to use the refresh token to request a new access token.
Your refresh token should not expire except.
if it has not been used for six months.
If a user authenticates your application they get a new refresh token, If they authenticate your application again then will get another refresh token. You can have up to 50 outstanding refresh tokens all will continue to work until you go over that number then the first one will expire.
The user can also revoke your access though their account at any time.
Don't bother storing the access token just store the refresh token, and make sure that if your user authenticates your application again that you replace the refresh token in your database with the new one.
If a user grants your application offline access which will give you a refresh token. Yes they are at the mercy of your application which can do what ever you have been granted access when ever.
Note: it can take a while to go through the verification process with the YouTube API start early.
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 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.
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"