Oauth2 why refresh token

Their basic structure conforms to the typical JWT structure, and they contain standard JWT claims asserted about the token itself. It's important to highlight that the access token is a bearer token. Those who hold the token can use it. The access token then acts as a credential artifact to access protected resources rather than an identification artifact. Malicious users could theoretically compromise a system and steal access tokens, which in turn they could use to access protected resources by presenting those tokens directly to the server.

As such, it's critical to have security strategies that minimize the risk of compromising access tokens. One mitigation method is to create access tokens that have a short lifespan: they are only valid for a short time defined in terms of hours or days. There are different ways that a client application can get a new access token for a user. For example, once an access token expires, the client application could prompt the user to log in again to get a new access token. Alternatively, the authorization server could issue a refresh token to the client application that lets it replace an expired access token with a new one.

As mentioned, for security purposes, access tokens may be valid for a short amount of time. Once they expire, client applications can use a refresh token to "refresh" the access token. That is, a refresh token is a credential artifact that lets a client application get new access tokens without having to ask the user to log in again.

The client application can get a new access token as long as the refresh token is valid and unexpired. Consequently, a refresh token that has a very long lifespan could theoretically give infinite power to the token bearer to get a new access token to access protected resources anytime.

The bearer of the refresh token could be a legitimate user or a malicious user. As such, security companies, such as Auth0, create mechanisms to ensure that this powerful token is mainly held and used continuously by the intended parties. It's important to keep in mind that the OAuth 2.

So, if we were to discuss authorization strategies in terms of other identity protocols or frameworks, such as SAML, we would not have the concepts of access tokens or refresh tokens. For those involved with web development, access token and refresh tokens are common talk because the web extensively uses token-based authorization and authentication through the OAuth 2. When combined, OAuth 2.

Each flow has its own set of benefits and caveats that define the best scenarios and architecture where we should use access and refresh tokens. Is the client a traditional web application executing on the server? Use the Authorization Code Flow. Use the Implicit Flow with Form Post. Is the client the resource owner? You may use the Client Credentials Flow. Is the client absolutely trusted with user credentials? You may use the Resource Owner Password Flow. Keep in mind that according to the spec, when using the Implicit Flow, the authorization server should not issue refresh tokens.

There's no easy way of keeping a refresh token secure in the frontend layer on its own. For example, when using the implicit grant type, the access token is transmitted in the URI fragment , which can expose it to unauthorized parties.

You can learn more about these vulnerabilities by reading the "Misuse of Access Token to Impersonate Resource Owner in Implicit Flow" section of the spec.

However, implementing PKCE in your applications still has no impact on how secure refresh tokens are. There are scenarios where you can still get an access token without interrupting the user and without relying on the almighty power of the refresh token.

Other examples to keep a session going can be cookies or silent authentication. However, billions of people use SPAs every day. It is important to provide users with a user experience that balances security and convenience well. If valid, the authorization server responds back with an access token and, optionally, a refresh token. Value MUST be set to "code".

The client identifier as described in Section 2. As described in Section 3. The scope of the access request as described by Section 3. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent.

If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision by asking the resource owner or by establishing approval via other means. When a decision is established, the authorization server directs the user-agent to the provided client redirection URI using an HTTP redirection response, or by other means available to it via the user-agent.

The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. 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. The authorization code is bound to the client identifier and redirection URI.

The exact value received from the client. The authorization code string size is left undefined by this specification. The client should avoid making assumptions about code value sizes. A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error.

The authorization code received from the authorization server. 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.

Access Token Response If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.

If the request client authentication failed or is invalid, the authorization server returns an error response as described in Section 5. Implicit Grant The implicit grant type is used to obtain access tokens it does not support the issuance of refresh tokens and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript. Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device. C Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier.

D The user-agent follows the redirection instructions by making a request to the web-hosted client resource which does not include the fragment per [ RFC ]. The user-agent retains the fragment information locally. E The web-hosted client resource returns a web page typically an HTML document with an embedded script capable of accessing the full redirection URI including the fragment retained by the user-agent, and extracting the access token and other parameters contained in the fragment.

F The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token. G The user-agent passes the access token to the client. See Sections 1. See Sections Value MUST be set to "token". The access token issued by the authorization server. The type of the token issued as described in Section 7. Value is case insensitive. The lifetime in seconds of the access token. For example, the value "" denotes that the access token will expire in one hour from the time the response was generated.

If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. The scope of the access token as described by Section 3.

Such clients will require using other methods for redirecting the client than a 3xx redirection response -- for example, returning an HTML page that includes a 'continue' button with an action linked to the redirection URI.

The access token string size is left undefined by this specification. The client should avoid making assumptions about value sizes. Resource Owner Password Credentials Grant The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged Hardt Standards Track [Page 37] RFC OAuth 2.

The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable. This grant type is suitable for clients capable of obtaining the resource owner's credentials username and password, typically using an interactive form. It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

B The client requests an access token from the authorization server's token endpoint by including the credentials received from the resource owner. C The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.

Authorization Request and Response The method through which the client obtains the resource owner credentials is beyond the scope of this specification. The client MUST discard the credentials once an access token has been obtained. Value MUST be set to "password". The resource owner username.

The resource owner password. Since this access token request utilizes the resource owner's password, the authorization server MUST protect the endpoint against brute force attacks e. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5. Client Credentials Grant The client can request an access token using only its client credentials or other supported means of authentication when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server the method of which is beyond the scope of this specification.

B The authorization server authenticates the client, and if valid, issues an access token. Authorization Request and Response Since the client authentication is used as the authorization grant, no additional authorization request is needed. Access Token Response If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.

Issuing an Access Token If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.

The refresh token, which can be used to obtain new access tokens using the same authorization grant as described in Section 6. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers.

The order of parameters does not matter and can vary. The sizes of tokens and other values received from the authorization server are left undefined. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP Unauthorized status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client.

The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. The refresh token issued to the client. The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner. 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 valid and authorized, the authorization server issues an access token as described in Section 5. If the request failed verification or is invalid, the authorization server returns an error response as described in Section 5.

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. Accessing Protected Resources The client accesses protected resources by presenting the access token to the resource server.

The resource server MUST validate the access token and ensure that it has not expired and that its scope covers the requested resource. The methods used by the resource server to validate the access token as well as any error responses are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server.

The method in which the client utilizes the access token to authenticate with the resource server depends on the type of access token issued by the authorization server.

Access Token Types The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request along with type-specific attributes. It also defines the HTTP authentication method used to include the access token when making a protected resource request. While the specifics of such error responses are beyond the scope of this specification, this document establishes a common registry in Section New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification.

Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to the registry in the same manner. Extensibility 8. Defining Access Token Types Access token types can be defined in one of two ways: registered in the Access Token Types registry following the procedures in Section Types utilizing a URI name SHOULD be limited to vendor-specific implementations that are not commonly applicable, and are specific to the implementation details of the resource server where they are used.

All other types MUST be registered. The token type "example" is reserved for use in examples. Defining New Endpoint Parameters New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the OAuth Parameters registry following the procedure in Section If the extension grant type requires additional token endpoint parameters, they MUST be registered in the OAuth Parameters registry as described by Section Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the Authorization Endpoint Response Types registry following the procedure in Section Only one order of values can be registered, which covers all other arrangements of the same set of values.

For example, the response type "token code" is left undefined by this specification. However, an extension can define and register the "token code" response type. Once registered, the same combination cannot be registered as "code token", but both values can be used to denote the same response type. Defining Additional Error Codes In cases where protocol extensions i. Error codes used with unregistered extensions MAY be registered. Native Applications Native applications are clients installed and executed on the device used by the resource owner i.

Native applications require special consideration related to security, platform capabilities, and overall end-user experience.

The authorization endpoint requires interaction between the client and the resource owner's user-agent. Native applications can invoke an external user-agent or embed a user-agent within the application. For example: o External user-agent - the native application can capture the response from the authorization server using a redirection URI with a scheme registered with the operating system to invoke the client as the handler, manual copy-and-paste of the credentials, running a local web server, installing a user-agent extension, or by providing a redirection URI identifying a server-hosted resource under the client's control, which in turn makes the response available to the native application.

When choosing between an external or embedded user-agent, developers should consider the following: o An external user-agent may improve completion rate, as the resource owner may already have an active session with the authorization server, removing the need to re-authenticate. It provides a familiar end-user experience and functionality. An embedded user-agent educates end-users to trust unidentified requests for authentication making phishing attacks easier to execute.

When choosing between the implicit grant type and the authorization code grant type, the following should be considered: o Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential. Security Considerations As a flexible and extensible framework, OAuth's security considerations depend on many factors. The following sections provide implementers with security guidelines focused on the three client profiles described in Section 2.

Client Authentication The authorization server establishes client credentials with web application clients for the purpose of client authentication. The authorization server is encouraged to consider stronger client authentication means than a client password. Web application clients MUST ensure confidentiality of client passwords and other client credentials. The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device.

When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity -- for example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. A valid redirection URI is not sufficient to verify the client's identity when asking for resource owner authorization but can be used to prevent delivering credentials to a counterfeit client after obtaining resource owner authorization.

The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials e.

Client Impersonation A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.

The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients.

For example, the authorization server can engage the resource owner to assist in identifying the client and its origin. The authorization server SHOULD enforce explicit resource owner authentication and provide the resource owner with information about the client and the requested authorization scope and lifetime.

It is up to the resource owner to review the information in the context of the current client and to authorize or deny the request. The authorization server SHOULD NOT process repeated authorization requests automatically without active resource owner interaction without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator.

Access Tokens Access token credentials as well as any confidential access token attributes MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued.

When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties. The authorization server MUST ensure that access tokens cannot be generated, modified, or guessed to produce valid access tokens by unauthorized parties. The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and MAY issue an access token with less rights than requested.

This specification does not provide any methods for the resource server to ensure that an access token presented to it by a given client was issued to that client by the authorization server. Refresh Tokens Authorization servers MAY issue refresh tokens to web application clients and native application clients. Refresh tokens MUST be kept confidential in transit and storage, and shared only among the authorization server and the client to whom the refresh tokens were issued.

The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued. The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.

For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach. The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.

Since authorization codes are transmitted via user-agent redirections, they could potentially be disclosed through user-agent history and HTTP referrer headers. Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process. Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS.

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.

If the client can be authenticated, the authorization servers MUST authenticate the client and ensure that the authorization code was issued to the same client.

If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code.

An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker's user-agent is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client and replaces the Hardt Standards Track [Page 56] RFC OAuth 2.

The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and trusted client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code.

The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account, which can now gain access to the protected resources authorized by the victim via the client. In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token.

Resource Owner Password Credentials The resource owner password credentials grant type is often used for legacy or migration reasons.

It reduces the overall risk of storing usernames and passwords by the client but does not eliminate the need to expose highly privileged credentials to the client. This grant type carries a higher risk than other grant types because it maintains the password anti-pattern this protocol seeks to avoid. The client could abuse the password, or the password could unintentionally be disclosed to an attacker e. Additionally, because the resource owner does not have control over the authorization process the resource owner's involvement ends when it hands over its credentials to the client , the client can obtain access tokens with a broader scope than desired by the resource owner.

The authorization server should consider the scope and lifetime of access tokens issued via this grant type. While refresh tokens are often long-lived, the authorization server can invalidate them.

Some of the reasons a refresh token may no longer be valid include:. Because refresh tokens have the potential for a long lifetime, developers should ensure that strict storage requirements are in place to keep them from being leaked.

For example, on web applications, refresh tokens should only leave the backend when being sent to the authorization server, and the backend should be secure. The client secret should be protected in a similar fashion. Mobile applications do not require a client secret, but they should still be sure to store refresh tokens somewhere only the client application can access. Languages with SDK support include Node.