I'm looking into Oauth2 to allow developers to authorize users of their app to use my service. I've found a few sources that say that my Authorization Server should return an access token when a user sends an assertion (JWT in my case) but that it should not return a refresh token. I'm wondering what the harm is in returning a refresh token. Developers could invalidate refresh/access tokens by calling an Api that invalidates any access granted from a particular JWT's id.
That recommendation is not correct. Refresh tokens are optional and can be issued at the discretion of the Authorization Server after client presents the authorization grant. See Oauth2 specification
1.5 Refresh tokens
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 (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (D) in
Figure 1).
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.
If you request a token from the server (with the same credentials and within the lifespan of an old token) should it either:
return a fresh token every time
return the same token with a shorter lifespan
something else / depends on
Is it depending on whether you use a refresh token?
Can you please reference the OAuth 2 RFC in your answer ?
The OAuth 2.0 Authorization Framework is a framework that allow a Resource Owner to CONSENT to allow DELEGATION of their permissions to access a Resource Server to another party (OAuth Client).
The Authorization Request is performed by the OAuth Client and is fulfilled by the Authorization Server only after obtaining CONSENT from the Resource Owner by the Authorization Response (which includes a Access Token).
The Access Token is a Bearer Token with a limited lifetime.
The refresh Token, if used, by the client to requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
The "same" Access Token is never returned or reused by the Authorization Server.
Reading and following the Security Considerations with any Authentication or Authorization Protocols is a must. Most breaches are caused by implementation errors rather than protocol errors.
You should Tell us what you have tried and show logs or results and Read:
https://stackoverflow.com/help/how-to-ask
We have just started out with ASP.NET Web API 2 and implemented OAuth2 client credential token grant, resource owner token grant (for internal apps) as well as code flow token Grant for third party Vendors.
For code flow, when the refresh token is exchanged for a new access token and refresh token the original token is removed from the token store and as such invalidated. The resource owner can also at any time revoke an access token and its associated refresh token.
One of our vendors will follow the code flow grant as there is a requirement that the resource owner or representative authorizes the access to the resource server.
The vendor subsequently requested that instead of the normal flow to redeem the refresh token for a new access token and refresh token, that the host server automatically provide a new access token and refresh token for each request.
The idea that over and above servicing the request, the host API calls back to a pre-determined endpoint on the client domain that will provide a new access token and refresh token.
It goes without saying that such an arrangement introduces complexity within the host API and it would defeat the whole point of short lived tokens and longer lived refresh tokens and we would probably implement other measures to prevent token hi-jacking and other types of attacks.
Currently our authorization server and resource server is one and the same. We would however want to keep the option open to separate the authorization server from the resource in future.
The questions from this then:
Should we consider this arrangement at all?
Would it make sense to adjust to a never expiring access token and not issue a refresh token with the token request?
After reading the Google OAuth2 documents, I have downloaded the application_default_credentials.json and used this to get access token(bearer token).
I'm not sure if this's the standard of OAuth2. Some documents show that we need refresh token and client credential to get access token, but why not just refresh token? If I have client credential, does that mean I can get access token directly?
Yes, it is part of the OAuth2 specification that you must send the client credentials along with the refresh token. From RFC 6749, section 6:
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client to which it was issued. If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server.
Why can't the client simply send both the access and refresh tokens together for every authorized request? If the access token is expired, it wouldn't require two additional trips to retrieve a new access token and finally making the relevant request.
I realize this operation is amortized, but it would lessen the number of requests for very short access tokens. And under SSL, I don't see how adding the refresh token makes this any more vulnerable. Or does it?
I think the main reason is that the refresh token and the access token are sent to different places. The access token is sent to the resource server and the refresh token is sent to the authorization server. In the general case, there's nothing that the resource server can do with the refresh token.
Some reasons:
The access token provides an abstraction layer, replacing different
authorization constructs (e.g., username and password) with a single
token understood by the resource server. This abstraction enables
issuing access tokens more restrictive than the authorization grant
used to obtain them, as well as removing the resource server's need
to understand a wide range of authentication methods.
https://www.rfc-editor.org/rfc/rfc6749#section-1.4
Having the resource servers understand refresh tokens means more work for them when it can / should be abstracted away (by the authorization server).
...
Because refresh tokens are typically long-lasting credentials used to
request additional access tokens, the refresh token is bound to the
client to which it was issued. If the client type is confidential or
the client was issued client credentials (or assigned other
authentication requirements), the client MUST authenticate with the
authorization server as described in Section 3.2.1.
https://www.rfc-editor.org/rfc/rfc6749#section-6
A refresh request requires client credentials. The resource server shouldn't have to ever see the client's credentials.
Refresh tokens are meant to be long-lasting, while access tokens aren't (or shouldn't be).