I have an api runs a long time. What if an access token expires during the api run? will the api stop in the middle or keep running until it ends?
Thanks,
It depends on the API. Usually the API will validate the token when it receives the request and then process it. During processing usually expiration is not checked - the API only cares that the token was valid when it received the request.
Of course I can imagine that someone implemented an API, that during processing of long requests it validates the token in set intervals. I would imagine that you would have information on such behaviour in the API's documentation, though.
Related
I'm using an API with OAuth2.0 protocol in my backend environment with password flow (grant_type = "password").I chose this flow because I don't have user interaction, it is just machine to machine (M2M).I know there is another flow, "client_credentials" I think that is more appropriate but the API provider doesn't offer this option.
So, sometimes my system makes 5 request in an hour, sometimes none an hour, this makes me ask as the title says, is it bad to call the password flow for every request?Should I use the refresh token, another possibility or does it just not matter?
The standard behaviour is for your API to work like this:
Authenticate with the Authorization Server to provide a credential and get an access token (which may live for 60 minutes)
Cache the token in the client process (your API) - perhaps in a thread safe memory cache
Call the downstream API with the access token as frequently as you like (eg every 30 seconds)
This ensures that:
The credential is not sent often and on most calls only an access token is sent
When the credential is sent, only the Authorization Server can see it - not the downstream API
The risk of stolen credentials is lower - and if an access token is somehow stolen it will expire soon anyway
Sometimes you may have to work with non standards based APIs. In this case I would still aim to follow the above pattern as best you can.
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'm developing a API to be used with my IOS App and I am curious on the best practice for using the refresh token in oAuth2. I am using the user password grant to generate a access token and refresh token.
If the token expires every 60 minutes then that means every 60 minutes the client will have to make 3 consecutive API calls: 1. use the access token to get the resource from the API, 2. api responds with a invalid token so we need to use the refresh token, 3. now that the token is refreshed we need to try the initial call again.
So, what I am wanting to know is if it's best to refresh the token just before it expires? Or is it better to generate a new access token once the API has responded with a expired token error?
Not sure there's a best practice as such, but it's certainly more efficient to refresh in advance as you then won't make requests that you can know will fail. The cost of the timer to refresh is much less than the cost of the network communication.
You still need handling for the token being invalid on any request as the server could invalidate the token for any number of other reasons, so this is really a 'how can I make this efficient and user friendly' than a 'can I remove some of my code' kind of thing. Handling the error response is the standard, refreshing in advance is the user friendly.
Be cautious about refreshing while you have in-flight requests and you could inadvertently cause a request to fail by invalidating its token...
I read the documentation in the Youtube developers website it does not talk about any validity.
Does the OAuth 2.0 standards define any validity period or is the authorization token valid till the user revokes it manually ?
The OAuth spec defines that the token should expire shortly after its granted, so will it expire after I get the
access and refresh tokens ?
And can I use this access token for all future API requests or do I need to get a new token periodically ?
I'm assuming you are talking about the authorization code, you're mixing the terms a bit here.
From the OAuth 2.0 draft:
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 more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.
After using it once for getting the access token, you can not use it again. You also don't need to retrieve an authorization code periodically. You do this only when you have no access token for a user, but want to request his data.
Your access token some time expires. You know when by either looking at the expires_in value that got send with it, or by doing a request to the API and getting an access token expired error back. Then you can use the refresh token to get a new access token without the user being involved.
Very useful step-by-step guide about how to get access and fresh tokens and save them for future use using YouTube OAuth API v3.
PHP server-side YouTube V3 OAuth API video upload guide.
The good thing is, you do not need to worry about the expiry of the tokens, as the script in this guide checks, saves, and updates the token in a txt file for future access.
{"access_token":"XXXXXXXXX","token_type":"Bearer", "expires_in":3600, "refresh_token":"XXXXXXX", "created":000000}
We use at http://presentationtube.com and it works fine with thousands of users.
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.