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
I have configured my client to use Hybrid flow with a grant type of password and offline. The user is able to generate an access token and the response does include a refresh token.
My question is I do not see documentation on how to use the refresh token for non .Net environments. Specifically I am curious if any body has a sample refresh flow in another language or Postman that shows which endpoints to hit and what the request needs to look like when the user requests a new token via the refresh token.
Thanks in advance,
G
This is documented at http://docs.identityserver.io/en/latest/endpoints/token.html
The token endpoint can be used to programmatically request tokens. It supports the password, authorization_code, client_credentials and refresh_token grant types). Furthermore the token endpoint can be extended to support extension grant types.
Example
POST /connect/token client_id=client1&client_secret=secret& grant_type=refresh_token&refresh_token=hdh922&redirect_uri=https://myapp.com/callback
I am new to OAuth and was wondering why authorization code is required?
Why authorization does not send access token or refresh token in callback response.
why not directly access token?
The Authorization Code grant uses the short-lived one-time code so that it can be exchanged for the real token (which is longer-lived and multiple-use) in a backchannel call that is more secure and can leverage credentials to authenticate the Client towards the Authorization Server.
The Implicit grant type returns the access token directly in the authorization response. It is considered to be more insecure because it is easier to attack (using crafted redirects etc.) and because there's no way to keep a client credentials secret.
I am completely new to oauth2. I need to implement oauth2 for securing my REST services. After reading different blog posts what I under stood is,
There are 3 things, Client,Provider and webapp.
Web app Wants to access information about the user from the provider.
If the client allows , provider will give a authorization code to the client and webapp in query string.
Now the web app will use the authorization code to obtain the access token using which it can access the resources.
Now I am bit confused regarding the authorization code. Is it secure ?
What is the life span of a authorization code? If someone else will steal the authorization code will he be able to access the user resources?
RFC 6749 recommends that the maximum lifetime of an authorization code be 10 minutes (4.1.2. Authorization Response). In other words, an authorization code expires in 10 minutes.
An authorization code is just like a ticket which is exchanged with an access token at the token endpoint. An authorization code is not an access token, so no one can access any data with an authorization code. In addition, an OAuth 2.0 server will discard or invalidate the authorization code after the exchange.
These two request have to be done over HTTPS (mandatory) since they are requests to the OAuth server which has to support only HTTPS. It's only the client/requestor server who do not have to support HTTPS, so only the Auth Code is potentially sent in clear over HTTP. But the Auth Code is useless without the client ID/Secret. Basically the point of the OAuth Code flow is that the burden of having an SSL-enabled server is on the OAuth Provider (Google/Facebook etc...) and not on the users of the APIs
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.