OAuth 2.0 protocol study notes

Protocol official website

In the traditional client-server authentication model, the client requests access to restricted resources (protected resources) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications with access to restricted resources, resource owners share their credentials with the third party. This creates several problems and limitations.

1. Third-party applications need to store the credentials of the resource owner for future use, usually a clear text password.
2. The server is required to support password authentication, although the password has inherent security weaknesses.
3. Third-party applications gain overly broad access to the resource owner’s protected resources, preventing the resource owner from restricting the duration or accessing a limited subset of resources.
4. The resource owner cannot revoke the access rights to a single third party without revoking the access rights to all third parties, and must change the password of the third party to do so.
5. Any disclosure of third-party applications will result in the disclosure of the end user's password and all data protected by the password.

OAuth solves these problems by introducing an authorization layer and separating the role of the client from the role of the resource owner. In OAuth, the client requests access to the resource controlled by the resource owner and managed by the resource server, and obtains a set of credentials different from the resource owner.

Instead of using the resource owner's credentials to access the protected resource, the client obtains an access token—a string that represents a specific scope, life cycle, and other access attributes. The access token is issued to a third-party client by the authorization server under the approval of the resource owner. The client uses the access token to access the protected resource hosted by the resource server.

For example, end users (resource owners) can grant print services (clients) access to their protected photos stored in photo sharing services (resource servers) without sharing their user names and passwords with print services. Instead, she authenticates directly to a server trusted by the photo sharing service (authorization server), which issues specific credentials (access tokens) delegated by the print service.

This specification is designed for HTTP ([RFC2616]).

The OAuth 1.0 protocol ([RFC5849]) was released as an information document, the result of the efforts of a small temporary community. This standard tracking specification is based on OAuth 1.0 deployment experience and other use cases and scalability requirements collected from the broader IETF community.

The OAuth 2.0 protocol is not backward compatible with OAuth 1.0. These two versions can coexist on the network, and implementations can choose to support both versions at the same time. However, the intent of this specification is that new implementations support OAuth 2.0 as specified in this document, and OAuth 1.0 is only used to support existing deployments. The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should approach this document without making any assumptions about its structure and details.

Four roles in Oauth

Resource owner

An entity capable of granting access to protected resources.

When the resource owner is an individual, it is called the end user.

Resource server

The server hosting the protected resource can use the access token to accept and respond to protected resource requests.

# Client-client

An application that requests protected resources on behalf of and authorized by the resource owner. The term "client" does not imply any specific implementation characteristics (for example, whether the application is executed on a server, desktop, or other device).

Authorization server

The server issues an access token to the client after successfully verifying the resource owner and obtaining authorization.

The interaction between the authorization server and the resource server is beyond the scope of this specification.

The authorization server can be the same server as the resource server, or it can be a separate entity.

A single authorization server can issue access tokens accepted by multiple resource servers.

The abstract OAuth 2.0 process describes the interaction between the four roles, including the following steps:

(A) The client requests authorization from the resource owner. The authorization request can be sent directly to the resource owner, or preferably indirectly through the authorization server as an intermediary.

(B) The client receives the authorization confirmation, which is a credential authorized on behalf of the resource owner. It is represented by one of the four authorization types defined in this specification or an extended authorization type. The authorization authorization type depends on the method the client requests authorization and the type supported by the authorization server.

(C) The client requests an access token, which is done through authentication with the authorization server.

(D) The authorization server authenticates the client and verifies the authorization, and if it is valid, issues an access token.

(E) The client requests protected resources from the resource server and authenticates by providing an access token.

(F) The resource server verifies the access token, and if it is valid, serves the request.

Authorization Grant

Authorization is a credential that represents the resource owner's authorization (access to its protected resources) used by the client to obtain an access token. The specification defines four types of authorization—authorization code, implicit, resource owner password credentials, and client credentials—as well as extensibility mechanisms for defining other types.

Authorization Code

The authorization code is obtained through the authorization server as an intermediary between the client and the resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to the authorization server (through its user agent defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code end.

Before using the authorization code to guide the resource owner back to the client, the authorization server authenticates the resource owner and obtains authorization. Since the resource owner is only authenticated through the authorization server, the resource owner's credentials are never shared with the client.

The authorization code provides some important security advantages, such as the ability to authenticate the client and transmit the access token directly to the client without going through the user agent of the resource owner and possibly exposing it to others, including the resource owner.

Implicit

Implicit authorization is a simplified authorization code flow optimized for clients implemented in browsers using scripting languages such as JavaScript. In the implicit process, instead of issuing an authorization code to the client, an access token is issued directly to the client (as a result of authorization by the resource owner).
The authorization type is implicit because no intermediate credentials (such as an authorization code) are issued (used later to obtain an access token).

When an access token is issued during the implicit authorization process, the authorization server does not authenticate the client. In some cases, the client's identity can be verified by the redirection URI used to pass the access token to the client. The access token may be exposed to the resource owner or other applications that have access to the user agent of the resource owner.

Implicit authorization improves the responsiveness and efficiency of certain clients (such as those implemented as in-browser applications) because it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security risks of using implicit authorization, especially when the authorization code authorization type is available.

Resource Owner Password Credentials

The resource owner's password credentials (ie, username and password) can be used directly for authorization to obtain an access token. Credentials (such as authorization codes) should only be used when there is a high degree of trust between the resource owner and the client (for example, the client is part of the device operating system or a highly privileged application) and other authorization grant types are not available.

Although this authorization type requires the client to directly access the resource owner credentials, the resource owner credentials are still used for a single request and exchange access tokens. By exchanging credentials with long-term access tokens or refresh tokens, this authorization type can eliminate the need for the client to store the resource owner's credentials for future use.

Client Credentials

When the scope of authorization is limited to the protected resources under the control of the client, or the protected resources previously arranged with the authorization server, the client credentials (or other forms of client authentication) can be used as the authorization license. Client credentials are usually used for authorization authorization, when the client acts on its own behalf (the client is also the resource owner) or accesses protected resources based on authorization requests previously arranged with the authorization server.

Access Token

An access token is a credential used to access protected resources. The access token is a string that represents the authorization issued to the client. This string is usually opaque to the client. The token represents a specific access scope and duration, granted by the resource owner, and enforced by the resource server and authorization
server.

The token may represent an identifier used to retrieve authorization information, or it may self-contain authorization information in a verifiable manner (ie, a token string composed of some data and a signature). In order for the client to use the token, additional authentication credentials may be required, which is beyond the scope of this specification.

Access tokens provide an abstraction layer that replaces different authorization structures (for example, usernames and passwords) with a single token understood by the resource server. This abstraction makes the issuance of access tokens stricter than the authorization grants used to obtain them, and eliminates the need for the resource server to understand various authentication methods.

According to the security requirements of the resource server, the access token can have different formats, structures, and usage methods (for example, encryption attributes). Access token attributes and methods used to access protected resources are beyond the scope of this specification and are defined by supporting specifications such as [RFC6750].

Refresh Token

The refresh token is the credential used to obtain the access token. The refresh token is issued by the authorization server to the client to obtain a new access token when the current access token is invalid or expired, or to obtain additional access tokens with the same or narrower range (access tokens may have shorter The life cycle and less than the authorized permissions of the resource owner).
Issuing refresh tokens is optional and is determined by the authorization server. If the authorization server issues a refresh token, it will be included when issuing an access token.

The refresh token is a string that represents the authorization granted to the client by the resource owner. This string is usually opaque to the client. The token represents an identifier used to retrieve authorization information. Unlike the access token, the refresh token is only used for the authorization server and is never sent to the resource server.

(A) The client requests an access token by authenticating with the authorization server and providing authorization permission.

(B) The authorization server authenticates the client and verifies the authorization license, and if it is valid, issues an access token and a refresh token.

(C) The client sends a protected resource request to the resource server by providing an access token.

(D) The resource server verifies the access token, and if it is valid, serves the request.

(E) Repeat steps (C) and (D) until the access token expires. If the client knows that the access token has expired, then skip to step (G); otherwise, it will issue another protected resource request.

(F) The resource server returned an invalid token error due to an invalid access token.

(G) The client requests a new access token by authenticating with the authorization server and providing a refresh token. Client authentication requirements are based on client type and authorization server policy.

(H) The authorization server authenticates the client and verifies the refresh token, and if valid, issues a new access token (and optionally a new refresh token).

Refreshing an Access Token

If the authorization server issues a refresh token to the client, the client sends a refresh request to the token endpoint by using the "application/x-www-form-urlencoded" format to add the following parameters, where the character encoding is UTF-8 HTTP request entity body :

• Grant type: required. The value must be set to "refresh_token".
• refresh_token: required. The refresh token sent to the client.

Since refresh tokens are usually persistent credentials used to request other access tokens, refresh tokens are bound to the client to which they are issued. If the client type is confidential, or the client has obtained client credentials (or assigned other authentication requirements), the client must authenticate with the authorization server.

For example, the client uses transport layer security to issue the following HTTP request (the extra line break is only for display purposes):

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

The authorization server must:

1. Require client authentication for confidential clients or any clients that have issued client credentials (or have other authentication requirements)
2. If client authentication is included, authenticate the client and ensure that the refresh token is issued to the authenticated client, and
3. Verify the refresh token.

If it is valid and authorized, the authorization server will issue an access token. If the request verification fails or is invalid, the authorization server returns an error response.

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 can revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the scope of the refresh token must be the same as the scope of the refresh token included in the request by the client.

Security Considerations

Client Authentication

The authorization server establishes client credentials with the Web application client for client authentication. Encourage the authorization server to consider a client authentication method that is stronger than the client password. The web application client must ensure the confidentiality of the client password and other client credentials.

The authorization server must not issue client passwords or other client credentials to native applications or user agent-based application clients for client authentication purposes. The authorization server can issue a client password or other credentials for a specific installation of a local application client on a specific device.

When client authentication is not possible, the authorization server should use other methods to verify the client's identity-for example, by requiring the registered client to redirect the URI or soliciting resource owners to confirm the identity. When requesting authorization from the resource owner, a valid redirect URI is not sufficient to verify the identity of the client, but it can be used to prevent the credentials from being passed to a forged client after the resource owner's authorization is obtained.

The authorization server must consider the security risks of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (such as refresh tokens) issued to such clients.

Client Impersonation

If the impersonated client fails or cannot keep its client credentials secret, the malicious client can impersonate another client and gain access to protected resources.

The authorization server must authenticate the client as much as possible. If the authorization server cannot authenticate the client due to the nature of the client, the authorization server must require the registration of any redirection URI for receiving authorization responses, and should use other methods to protect the resource owner from such potentially malicious clients Infringe. For example, the authorization server can allow the resource owner to assist in identifying the client and its source.

The authorization server should enforce clear resource owner authentication and provide the resource owner with information about the authorization scope and life cycle of the client and request. The resource owner can view the information in the context of the current client and authorize or deny the request.

The authorization server should not automatically process repeated authorization requests (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated requests come from the original client and not the imitator.

Access Tokens

Access token credentials (and any confidential access token attributes) must be kept secret during transmission and storage, and can only be between the authorization server, the resource server for which the access token is valid, and the client to which the access token is issued Shared. Access token credentials must only be transmitted using TLS, and use the server authentication defined in [RFC2818].

When using the implicit authorization type, the access token is transmitted in the URI fragment, which may expose it to unauthorized parties.

The authorization server must ensure that unauthorized parties cannot generate, modify, or guess an access token to generate a valid access token.

The client should request an access token with the minimum necessary scope. The authorization server should consider the identity of the client when choosing how to accept the scope of the request, and can issue an access token with less authority than the request.

This specification does not provide any method for the resource server to ensure that the authorization server issues to the client the access token provided to it by a given client.

Refresh Tokens

The authorization server can issue refresh tokens to web application clients and native application clients.

The refresh token must be kept secret during transmission and storage, and can only be shared between the authorization server and the client to which the refresh token is issued.

The authorization server must maintain the binding between the refresh token and the client to which it is issued. The refresh token must only be transmitted using TLS and have server authentication as defined in [RFC2818].

Whenever the client's identity can be verified, the authorization server must verify the binding between the refresh token and the client's identity. When client authentication is not possible, the authorization server should deploy other methods to detect refresh token abuse.

For example, the authorization server can use refresh token rotation, where each access token refresh response will issue a new refresh token. The previous refresh token has expired but is retained by the authorization server. If the refresh token is compromised and subsequently used by attackers and legitimate clients, one of them will provide an invalid refresh token, which will notify the authorization server of the vulnerability.

The authorization server must ensure that unauthorized parties cannot generate, modify, or guess a refresh token to generate a valid refresh token.