Since using the refresh token gives you a new pair of tokens, what is the advantage of doing a refresh versus just obtaining a new Auth token? For example:
65 minutes after obtaining a token, I have to refresh it (and obtain a new token), or
just obtain a new one
Why not just get a new access token each time?
If I am doing everything within my own server / within my own code, is there any benefit to refreshing. Or is it as good to obtain a new token every hour?
I get the gist of the refresh in some circumstances, but when it's all in my control, is refresh token necessary?
Advantage relies with easiness of obtain access token.
Think about Authorization code flow. If you do not get a refresh token, client application have to trigger a new authorization code flow to retrieve a new access token. This include end user interactions for user grants (end user login in simple terms). For some applications, such re-login is not a desired feature. For them having a refresh token is a very desirable feature.
So when you design your application, if you don't want your end users to provide their credentials every time client application want an access token, then you should use refresh token. But if this is not the case and you have other ways to complete access token obtaining process then it's rather a design decision.
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.
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 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 working on a SPA app based on Node, with token-based authentication using JWT. Right now, the jwt token never expires, which is not good.
I want it to expire for more security, but I don't want my users to be forced to re-log. That's why I need a refresh token.
So i'm reading about OAuth2.
I have a hard-time to understand why refresh-tokens must be stored in a database, whereas access-token are generated on the fly using a secret key.
Why refresh tokens can't be generated the same way as access tokens ?
Thank you guys !
Refresh tokens usually are generated the same way as access tokens.
An authorization server will often return a refresh and access token if requested (and you're not using the implicit grant type).
The difference is how they are used.
An access-token is usually a bearer token: whoever has it can use it against the resource server, but it is only valid for a short period of time. In which case, storing them in a database is often pointless as they are worthless once expired.
A refresh token however is like having access to a "forge" which allows you to mint a new token.
If you present the refresh token to the authorisation server (not the resource server) you will get back a new access token and possibly a new refresh token.
Providing of course that the user has not revoked/changed access permissions to your application and that the user is still a valid user.
So you would keep them in a database perhaps because your user logs in infrequently. So you may need the refresh token weeks after you got it.
Alternative to the refresh token.
If you are using the implicit grant (which is common with SPAs but not recommended). You can try and keep your end user logged in to the identity provider used by the authorisation server. This way you can keep requesting new access tokens from the auth server without the user being prompted by the auth server for credentials as a session will be persisted between the identity provider and the user's browser.
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.