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.
Related
Is the authorization code grant type only for interactive accounts? I'm working with an API that does not appear to support client credentials grant and unless I fallback to basic auth (user:token) I do not know how we would make this work for a user that (to us) is a service account.
The piece I am struggling with is the return of the authorization code. If I hit the generated URL to request the auth code I receive a dialog asking me to allow/validate access and by accepting I am returned to the redirect_uri with the code param. This required human interaction which in our scenario we would not have. Auth codes are not supposed to be long lived so I cannot just save this for future use.
The first piece, getting an authorization code, needs to be done manually by a human.
The authorization code is short-lived so you wouldn't want to store the auth code for use later.
Thankfully, you can trade in that authorization code for an access token and refresh token. Though the access token expires, usually around an hour, the refresh token often remains active for an extended amount of time (this is can vary by API). The API I am working with at the moment does not document when it expires, it may not expire ever.
We'll just note that if the refresh code ever fails/expires then we should manually go to the authorization URL to get a new auth code which we can trade in for a new access token and refresh token. We'll keep the refresh token stored securely and will plug in the refresh token in our automation. The automation will not make authorization_code grant type calls (that part we'll still keep manual) and will only make refresh_token grant type calls (those can be automated) as well as the calls to do the actual work with the API once we have a fresh, valid access token.
I am using Google APIs in my application and the oauth2 refresh token expires after 1 hour. I am using this refresh token to execute a task which runs daily. I create the refresh token using the OAuth2 playground. Is there a way to extend the expiration time of a refresh token? (1 month)
I think that you have your terms confused here.
As per Oauth2 access tokens expire after one hour. Access tokens are used to request access of an api and return the data that you need. There is no way to extend the lifetime of an access token beyond one hour. You need to use a refresh token to request a new access token.
Refresh tokens are extremely long lived and do not normally expire. Refresh tokens are used to request a new access token. Refresh tokens for the most part do not expire if one is not used in six months though google will automatically expire it. Also if the user removes your access then the refresh token will also automatically expire.
If you are creating your refresh token using the Outh2 playground which is intended only for testing purposes it will also expire.
If you are using the oauth2 playground to create your refresh token then you should not be doing this you should be creating your own application to request the tokens.
As already explained the refresh tokens created using the OAuth 2.0 Playground are automatically revoked after a few hours because the playground is mainly for testing purposes. However you can configure the OAuth playground to use your own app credentials (use the 'wheely' icon top right). If you use your own app credentials the refresh token will not be revoked.
That said it looks like you want to run a background service that accesses Google APIs. For this you may want to use a Service Account if you are not accessing a specific user's data.
I tried to add YouTube Video from the third party and After one day, I got the success in doing so. But While uploading a video the access token is required and in order to get that access token the user must be logged in. And the expiration time for that access token is 3600 seconds( 1 hr).
Now, There are some of my questions regarding this.
Is there anyway, by which I can refresh access token.
If some one has G Suite account, then Is there any special values for expiration time, or it remains the same?
As per the documentation, I can have maximum 50 tokens, So is there any alternative for it, So that I can get valid token after 50 requests.
To answer your question for number 1, you can check the documentation here.
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that
object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the
user to Google's OAuth 2.0 server. In that case, Google's
authorization server returns a refresh token when you exchange an
authorization code for an access token. Then, if the access token
expires (or at any other time), you can use a refresh token to obtain
a new access token.
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
About the G Suite account, it was stated 24 Hours in the documentation. Note:
In this SO post answer, the function of Access Token and Refresh Token was discussed.
I am not sure if there are ways to alter the limits because of security reasons.
To clearly differentiate these two tokens and avoid getting mixed up,
here are their functions given in The OAuth 2.0 Authorization
Framework:
Access Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted
by the resource server.
Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server
and are used to obtain a new access token when the current access
token becomes invalid or expires, or to obtain additional access
tokens with identical or narrower scope.
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.
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.