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.
Related
I have a web service that makes use of the Authorization Code grant type to get an Access Token for user data on a Resource Server, together with a Refresh Token. Now my web service launches jobs at certain points in time that should also access this user data. However,
there may be more than one job running at a time,
the user is not necessarily around when the jobs are spawned, and
the jobs may be long-running, in particular they may live longer than the validity of the Access Token.
My question is: How can I provide each job with an Access Token so that
no user interaction is required for every single job launch, and
each job can refresh its own Access Token if necessary, without invalidating other jobs' tokens?
While https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 states that a refresh token can be used to obtain "additional access tokens" (emphasis mine), the spec is not so clear on whether the previous Access Token remains valid until it's expiry date (well, if it does not I wouldn't call it "additional"). Also, according to https://datatracker.ietf.org/doc/html/rfc6749#section-6 if a server issues a new Refresh Token to prevent replay attacks, then the old Refresh Token cannot be used any more, so now maybe I have an additional Access Token, but I can't really pass the Access Token and the new Refresh Token to the job, because if the job made use of that Refresh Token would then my web service couldn't use it any more.
Are there maybe any lesser-known flows that allow for this kind of unattended Access Token creation?
Normally access tokens and refresh tokens are valid till the exipration time.
Having multiple access and refresh tokens are also allowed.
However a refresh token can be revoked under following scenarios
the authorization server has revoked the refresh token
the user has revoked their consent for authorization
the refresh token has expired
the authentication policy for the resource has changed
Since you are having the background jobs running. I suggest not to use JWT Tokens for authentication. Instead you can have your custom security standards.
Like custom API Key, UserAgent for Jobs and you can pass the user information with the requset or as custom-header as well.
Provided, I have a google app, a user authorized my app by using OAuth2 many times, and my app stored all refresh tokens generated from the authorization. how many valid refresh tokens my app can keep ? and how many access token generated by each refresh token are valid ?
I'm currently working with other API's using OAuth2 and whenever a user authorises your application to get information the old tokens become invalid. In my case if a user re-authorises I toss the old tokens and insert the new ones. The access token can, and in most cases have, a limited life-span. If an access token is expired you will receive an error and you need to request a new access token with your refreshtoken. In some cases you will also get a new refresh token additional to your access token to request the next accesstoken. See https://developers.google.com/identity/protocols/OAuth2 for google-specific information.
In the answer to the question Why do access tokens expire?, the first point provided states:
[Bearer-Tokens are] short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token.
But when an Access-Token is used (From a native-app), the Client uses the Refresh-Token to get a new Access Token, and sends that new token back to the requestor. So if an attacker uses somebody else's access token, he'll just be sent a brand new access token every time.
So who cares about how long the token lasts? If an attacker gets it, they have taken over the session For As Long As The Refresh Token Lasts
I already know a dozen answers to my question, but I have questions to each answer. My original question was so long because I explained every scenario and how they are inconsequential or false (as far as I know). So please try to help me understand and I'll comment if I think the answer has caveats.
Addition/Edit - Hoping for more answers with my additional information
Web Page calls a Client with Resource Owner (User) Credentials
Client calls the Auth Server and gets an Access and Refresh Token. The Access Token will expire in 5 minutes, the Refresh Token will expire in hours or days or whatever.
Client sends the Access Token to the Web Page
Resource Owner (User) uses the web page
Web Page sends the Access Token to the Client
Client sends the Access Token to the Resource Server
Resource Server checks the Access Token in any number of ways
Resource Server sends Resources to the Client
Client sends Resources to the Resource Owner
Resource Owner (user) Continues to use the Web Page
The Client, either during Each Request or every 4 minutes and 30 seconds, uses the Refresh Token to get a new Access Token
The Client, either during Each Request or every 4 minutes and 30 seconds, sends a New Access Token to the Active Resource Owner
Yes? No? Since the Resource Owner is Actively using the web site, the web site is in constant communication with the Client, and the Client gets a new Access Token (Using the Refresh Token) and sends it back to the web site, so the Active user can continue using the site without being kicked out every 5 minutes.
Therefore, if ANY Person gets ahold of that Access Token, and are hitting the Client with it, the Client will continue to send new Access Tokens to whoever has that Access Token. Granted: After a single refresh, one of those two people will have a bad Access Token and be booted, but not necessarily the right person.
Your point seems to be that if an attacker can take over your browser session then they will be able to access the third-party resource for the entire length of the refresh token, as you've described. So what's the point of having a short-lived access token?
There's certainly some truth to that, but there are two general responses:
Using a refresh token makes it practicable to invalidate the user if the third-party figures out that the session has been taken over by an attacker.
The access token / refresh token system is used to prevent or limit other kinds of attacks that you haven't mentioned.
Regarding the first point, remember that the access token is sent to the resource server, not the authorization server. Although there's nothing in the specification that prevents the resource server from checking the validity of the user, in practice that could present performance issues. Access tokens are typically designed to be self-validating, without requiring access to some external resource.
Given that, the only way to invalidate a user is to do it on the authorization server when the refresh token is sent in. The authorization server sees that this user has been marked as compromised, and refuses to send a new access token.
Regarding the second point, there are plenty of other security scenarios that OAuth is designed to protect against other than a user's browser session being taken over by an attacker. What if someone is able to get ahold of the access token in some other way? Since the access token itself isn't generally used to get access to the client (see below), they won't be able to get the client to refresh the token for them, and therefore the fact that the access token is short-lived will be a security advantage.
As a reference, both of these points are made succinctly in this email to the Oauth Working Group mailing list.
Looking specifically at the flow you described in your post, I think your confusion is rooted in the idea that the client (web server) sends the user agent (the browser) the access token (your step 3), and that that token (in the form of a cookie) is what the client uses to authenticate the user agent. Although it's possible for a web framework to do those things, neither one is a part of OAuth (nor generally true of web frameworks, in my experience).
Access tokens are short-lived, refresh tokens are long-lived. Access tokens are presented to the Resource Server (and only the Resource Server) that hosts the protected content to get access. Refresh tokens are presented only to the Authorization Server, never to the Resource Server. So when an attacker obtains an access token, he can use it for the lifetime of the access token to get access to the protected content.
When the access token expires there's no way to get a new one unless he has obtained the refresh token as well. Besides that, when using the refresh token the client typically authenticates itself to the Authorization Server, so even when the attacker got the refresh token, he would also need the Client's credentials to use it to get a new access token.
there's two ways to fetch access token.
use authorization code to exchange it
use refresh token to refresh it
think about it!!
though the word of exchange and refresh is different,what they do are the same.
both action need to parse client id & client secret(Or signature) and token
we can just save the authorization code in our system,and again use auth code to
refresh access token just like refresh token do.
Except that authorization code is expired too soon.
so I wonder
why the designers of oauth2 designed these two concepts while not used just one single concept or say just design the authorization code and give it a long expired-time.
I am afraid that you have not understood the concepts of oauth2 too well. There aren't just two ways of getting the access token, there are more. Each is basically called a 'grant type'. I'm describing the use cases of the ones which I have deployed below :
1- Authorization code :
This is similar to the flow of "Login with Facebook" etc buttons which you see on different websites, which allow you to register/login using your facebook etc accounts. Here, on clicking this button, control is directed to Facebook, where the user enters his login credentials. If successful, an authorization code is sent to whatever redirecturl you entered while registering as a developer with Facebook. You then use this authorization code to request the access token service to get the access token which you then use whenever accessing any Facebook webservices to get the user's details.
2- Client credentials :
If you are running your own webservices and you want to allow access only to valid clients, then this is the grant type you would use. For example, you are running your webservices and now you want to consume it in your own native mobile app which you distribute through any app store. This will ensure that only those who installed your app will be able to access your webservice.
3- User credentials :
Same as above, only in this case this would allow you to authenticate a registered user as well and then give access to user restricted services like my account etc.
4- Refresh token :
By design, the access token service gives an access token as well as a refresh token. You would use the refresh token obtained from it here to refresh an expired access token. Essentially, this does not generate a new access token, it only "refreshes" an existing token. It will give you a new access token and refresh token and extend the expiry time. When this access token expires, you again call refresh token using the refresh token obtained last time, and keep repeating the process every time the token expires.
According to RFC 6749 10.5 The authorization codes are short lived and single-use. Therefore, you cannot use them again and again to get new authorization tokens.
Authorization codes MUST be short lived and single-use. If the
authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server
SHOULD attempt to revoke all access tokens already granted based on
the compromised authorization code.
There are some additional misconceptions that seem to be presented here, so I wanted to help clear them up.
The differences between an access token and a refresh token can be summarised as follows:
An access token is used to provide access to restricted resources to an authorized client after authentication has taken place.
A refresh token, on the other hand, is used by a client in order to retrieve new access tokens with identical or narrower scopes.
The different between the Authorization Code Grant and the Implicit Grant (as well as their usages) help to illustrate how both should be used.
In general, the Authorization Code Grant should be preferred over the Implicit Grant unless a resource is being accessed directly via a publicly implemented client (e.g., browser-run code) or there is a specific reason that the Authorization Code Grant cannot be used (e.g., feasibility or performance). This is explained in the RFC definition for the Implicit flow.
During an Implicit Grant, access tokens are exposed to the user-agent which could lead to them being compromised since they are no longer under the control of a server app (confidential client) that could otherwise be requesting the protected resources. This is why refresh tokens are not issued during Implicit Grants. Though access tokens might be exposed, they are short-lived. Resource tokens, on the other hand, are long-lived and can be used to retrieve new access tokens.
The Authorization Code Grant, on the other hand, prevents the potential for refresh tokens to be exposed. During this grant, the authorisation server issues a code instead of tokens. The code is then passed by the user-agent to the client application which exchanges the code with the authorization server to retrieve access and refresh tokens. Since the code exchange is performed directly between the client application and a trusted authorization server, a refresh token can be securely issued.
The RFC spec cautions that the security implications of implementing the Authorization Code Grant in a public client versus a confidential (e.g., server-side) client should be seriously considered. "More OAuth 2.0 Surprises: The Refresh Token" clears up a few misconceptions and furthers the idea that auth codes should not be sent directly by the user-agent to the auth server in order to retrieve refresh tokens, though the OAuth 2.0 spec does not technically dictate this.
Answer from #ComfortableDust has the answer to original question. Just quoting the exact text from his reply
The Authorization Code Grant, on the other hand, prevents the potential for refresh tokens to be exposed. During this grant, the authorisation server issues a code instead of tokens. The code is then passed by the user-agent to the client application which exchanges the code with the authorization server to retrieve access and refresh tokens. Since the code exchange is performed directly between the client application and a trusted authorization server, a refresh token can be securely issued.
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.