I am able to generate OAuth tokens from this URL successfully.
However, I can see both refresh token and access token is generated in the call.
Can we remove the refresh token during the OAuth call so that only access token is generated.
I have seen this feature of suppressing and disabling refresh token in other OAuth servers.
Does it apply in RingCentral too?
Yes, refresh tokens can be disabled by setting the TTL (time to live) for the refresh_token_ttl to zero:
refresh_token_ttl=0
example:
username=<username>&password=<password>&extension=<extension>&grant_type=password&refresh_token_ttl=0
Related
As we know that access token gives the client to access resources from resource server, I would like to know the contents and the process that happens with refresh token to get new access token.
I was tryging to experiment how oauth2 works, but got stuck at what refresh token does.
I would like to know the contents and the process that happens with
refresh token to get new access token.
Refresh token are generally opaque token (random unique string).
Refresh token is used to get new access token from the Authorization Server. Refresh tokens typically remain valid for longer time as compared to access token. In a typical client-server flow, when the access token expired, server reject the request then client uses the earlier obtained refresh token to get a new access token from Authorization Server. By doing so authentication between client and server remain uninterrupted and no re-authentication needed. Once the refresh token expired, client has to go through the complete authentication flow which usually require user intervention.
I see most of people saying when we use refresh token to exchange for a new access token, the auth server would issue a new refresh token and invalid the previous one. Refer
OAuth Refresh Token Best Practice
But from the OAuth website
https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/
It says the auth server can "optionally issue a new fresh token in response, or if we don't include a new refresh token, the client assumes the current refresh token will continue to be valid"
So, it looks like both options (keep or renew refresh token) are acceptable to OAuth2 standard.
My questions are:
1) Do both options are equally secure?
2) If the auth server returns a new refresh token but the client fails to receive (e.g. network error), the client has no way to re-gain access token with existing refresh token, which already invalidated. Correct?
3) If the refresh token has been leaked to someone else, both the attacker and the victim client can use it. If the auth server takes the renewal approach, then only the first one to use the refresh token can re-gain access token. So, if the victim found the refresh token is no longer valid, it may think that the refresh token has been compromised. Is this the reason for the "renewal approach"?
2.) Yes, that's correct.
3.) That's correct too. You can take a look at the OAuth 2.0 for Browser-Based Apps RFC which discusses the refresh token regeneration. It's important mainly for public clients - the ones without client_secret, since a refresh token can be exchanged for an access token right away.
1.) Refresh token regeneration is a security feature - it shortens validity of a stolen refresh token and it enables the auth server to detect that refresh token had been compromised. So it's more secure to use it than not. But it may be more convenient for private clients not to get a new refresh token on each use - for example to prevent the refresh token loss due to network error - as you described it in point #2.
I am implementing an oauth server using spring oauth. I notice that spring's implementation re issues the same access token if not expired from the token endpoint. However the behavior is different while refreshing access tokens. A new token is reissued each time, are there any concerns to keep in mind if I were to reissue the same un expired access token on receiving a valid refresh request.
The OAuth Spec section-6 specifies that:
The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
There does not seem to be a requirement that the access token is brand new.
I think the main concern is to ensure that you do not change the expiration date on an existing token. And that you correctly return to the client an accurate expires_in property which reflects when the token will expire.
In addition, it might make the semantics confusing for clients. The refresh is usually done when a token is expired, and the client wants a new one.
I can imagine some odd edge cases. A client could send a request to refresh a token a few seconds before it is expired (perfectly valid logic for a client), but still receive back the same token which is almost expired.
I am using Oauth to access Google Cloud Storage via their JSON API.
All is fine, I authenticate and get an access token which has an expiration of 3600.
What is the correct way to refresh this?
It is my understanding that in other types of oAuth flows (i.e. Web Server), the initial authorization request returns a refresh token as well as an access token, and that the refresh token is used to ask for another access token when the current access token has expired.
But is appears that there is no refresh token when doing server-to-server oAuth with a Google "Service Account"?
Found the answer.
https://developers.google.com/accounts/docs/OAuth2ServiceAccount#expiration
Access tokens issued by the Google OAuth 2.0 Authorization Server
expire one hour after they are issued. When an access token expires,
then the application should generate another JWT, sign it, and request
another access token.
I'm working with an API that uses OAuth2, provides an access token that expires in 3600 seconds, and provides a refresh token with it. Originally, I'd waited for an API call to fail in a way that indicated the access token was expired and then tried to refresh the access token using the refresh token. This has become problematic when the access token is expired and several API calls are made concurrently (each call separately triggers a refresh and most of the calls fail).
Would it be better to automatically refresh the access token using the refresh token after 3600 seconds? (Or 3599 seconds or 3601 seconds?) Is there a different paradigm I should be using for refreshing the access token?
Ideally, the client should have sufficient smarts to not use an expired access token. Fortunately the response from your OAuth AS's token endpoint should include the expires_in attribute to confirm that the expiry will be in 3600 seconds. E.g.:
{"token_type":"Bearer","expires_in":3600,"refresh_token":"p8BPdo01kkjh6fhatclD3wwBEQblm4kL4ctYRVlrHo","access_token":"9XebAAXeu6hQOAiwmOk8vdhRyUFV"}
Since this JSON response is generated by the server, there's a chance that the transmission back to the client has taken time, and thus the "expires_in" value may be smaller than it appears.
Given that, I'd recommend that you have some sort of buffer (say 5-10 seconds) before expiry to automatically use your refresh token to request a new access token.
I may have used the following scenario. There will be access failures due to access token validation error but those errors will be minimal.
App1 invokes the token api with password grant type and get the access token and refresh token pair (accto1/refto1)
App2 also do the same at the starting up of the execution (accto1/refto1)
When the access token is expired for App1, he may do the refresh token by invoking the token api with refresh token grant type and with his existing refresh token (refto1) and he will retrieve a new pair of access token and refresh token. (accto2/refto2)
When App2 also reaches the instance when his access token is expired, he will also try the refresh token grant with the refresh token he already has (refto1) but he will get an authorization error since that refresh token is now expired.
When either of the apps get this error then app needs to realize that someone else has refreshed the token so at this moment the app needs to make a call with the password grant to retrieve the new access token / refresh token pair in action. This time as in the example the App2 will also retrieve the same access token and refresh token pair that the App1 has previously received for his refresh token grant. (accto2/refto2)