Oauth2 Manual Chapter I.

Source: https://github.com/jeansfish/RFC6749.zh-cn/blob/master/SUMMARY.md

1. Introduction
In the traditional client-server authentication mode, when a client requests access to a restricted resource (a protected resource) on the server, it needs to authenticate with the resource owner's credentials on the server. The resource owner needs to share its credentials with a third party in order to provide access to a restricted resource to a third-party app. This leads to some problems and limitations:

Third-party apps need to store the credentials of the resource owner for future use. This credential is usually a clear-text password.
The server needs to support password authentication, although password authentication has inherent security flaws.
Third-party apps gain too broad access to the resource owner's protected resources, causing the resource owner to limit access time or permissions to a limited subset of resources.
The resource owner cannot revoke access to a third party without affecting other third parties, and must change their password to do so.
Compromise with any third party application results in a compromise of the end user's password and all data protected by that password.
OAuth addresses these issues by introducing the authorization layer and separating the client roles from the resource owner role. In OAuth, a client requests access to a resource that is controlled by the resource owner and is hosted on a resource server, and grants a set of credentials that are different from those owned by the resource owner.

As an alternative to using the resource owner's credentials to access a protected resource, the client obtains an access token ——— A string representing the specific scope, life cycle, and other access properties. An access token is issued to a third-party client by the authorization server, as approved by the resource owner. The client uses an access token to access the protected resources that are hosted on the resource server.

For example, an end user (a resource owner) can license a print service (client) to access a protected picture that she stores on a picture-sharing site (a resource server) without sharing her username and password with the print service, but instead, she authenticates directly with a server trusted by the picture-sharing site (the authorization server), The server issues specific delegate credentials (access tokens) to the print service.

This specification is designed for the HTTP (RFC2616) protocol. Using OAuth on any non-HTTP protocol is not within the scope of this specification.

The OAuth 1.0 Protocol (RFC5849) is published as a guiding document and is a result of the work of a small ad hoc group. This standardized specification builds on the deployment experience of OAuth 1.0 and also includes the collection of other user stories and scalability requirements from the wider IETF community. The OAuth 2.0 protocol is not backwards compatible with OAuth 1.0. These two versions can coexist on the network, and the implementation can choose to support them at the same time. However, the intent of this specification is that the new implementation supports AUTH 2.0,oauth 1.0 as specified in this document to support existing deployments only. The OAuth 2.0 protocol does not have much association with the OAuth 1.0 protocol implementation details. Implementations familiar with OAuth 1.0 should understand this document rather than make assumptions about the structure and details of OAuth 2.0.
1.1. Roles
OAuth defines four types of roles:
Resource owner
An entity that can license access to a protected resource. When the resource owner is an individual, it is called an end user.
Resource server
A server that hosts a protected resource to receive and respond to requests to a protected resource using an access token.
Client
An application that uses the resource owner's authorization to initiate a request for a protected resource on behalf of the resource owner. The term "client" does not specifically refer to any specific implementation characteristics (for example, whether the application is performed on a server, desktop, or other device).
Authorization server
The server that issued the access token to the client after successfully validating 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 detached individual. An authorization server can issue access tokens that are accepted by multiple resource servers.
1.2. Protocol Process
+--------+                               +---------------+
|   |--(A)-Authorization Request->| Resource |
|                               |     | Owner |
|               |<-(B)--Authorization Grant---| |
|                               | +---------------+
| |
|                               | +---------------+
| |--(C)--Authorization Grant-->| Authorization |
|                               Client |     | Server |
|               |<-(D)-----Access Token-------| |
|                               | +---------------+
| |
|                               | +---------------+
|    |--(E)-----Access Token------>| Resource |
|                               |     | Server |
|               |<-(F)---Protected Resource---| |
+--------+                               +---------------+
Figure 1: Abstract protocol Flow

The abstract OAuth 2.0 process shown in Figure 1 describes the interactions between the four roles, including the following steps:

(A) The client requests authorization from the resource owner. Authorization requests can be initiated directly to the resource owner () or, preferably, indirectly through an authorization server as an intermediary.
(B) The client receives an authorization, which is a credential that represents the authorization of the resource owner, using one of the four license types defined in this specification or using the extended license type. The licensing type depends on the method used by the client to request authorization and the types supported by the authorization server.
(C) The client authenticates with the authorization server and presents an authorization permit to request an access token.
(D) Authorize the server to authenticate the client and verify the license, and issue an access token if it is valid.
(E) The client requests the protected resource from the resource server and presents an access token for authentication.
(F) The resource server validates the access token and, if valid, processes the request.
A better way for clients to obtain authorization from the resource owner (shown in steps (A) and (B)) is to use the authorization server as a mediator, as shown in section 4.1, Figure 3.

1.3. Licensing
A license is a credential that is authorized (to access a protected resource) on behalf of the resource owner, which the client uses to obtain an access token. This specification defines four license types-authorization codes, implicit licenses, resource owner password credentials, and client credentials-and the extensibility mechanisms used to define other types.
1.3.1. Authorization Code
Authorization codes are obtained by using an 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 (by the user agent defined in RFC2616), and the authorization server directs the resource owner back to the client with the authorization code.

The authorization server authenticates the resource owner and obtains its authorization before the boot resource owner carries the authorization code back to the client. Because the resource owner authenticates only with the authorization server, the credentials of the resource owner do not need to be shared with the client.

The authorization Code provides some important security benefits, such as the ability to authenticate the client's identity, as well as the transmission of the direct access token to the client rather than passing it through the resource owner's user agent and potentially exposing it to others, including the resource owner.
1.3.2. Implicit licensing
Implicit licensing is a streamlined authorization code process that is optimized for clients that are implemented in a browser using scripting languages such as JavaScript. In the implicit licensing process, the client is no longer issued an authorization code, instead the client is issued an access token directly (as the authorization of the resource owner). This type of license is implicit because no intermediate credentials (such as an authorization code) are issued (and then used to obtain an access token).

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

Implicit licensing improves the responsiveness and efficiency of some clients, such as a client that is implemented as a in-browser application, because it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of adopting implicit licensing, as described in sections 10.3 and 10.16, especially when the Authorization Code license type is available.

1.3.3. Resource owner password Credentials
The resource owner password credentials (that is, the user name and password) can be used directly as an authorization to obtain an access token. This credential should only be used when there is a high level of trust between the resource owner and the client (for example, if the client is part of the device's operating system, or is a highly privileged application), and when other licensing types, such as authorization codes, are not available.

Although this authorization type requires direct client access to the resource owner credential, the resource owner credential is only used for one request and is exchanged as an access token. This type of license eliminates the need for clients to store resource owner credentials for future use through the interchange of credentials and long-term valid access tokens or refresh tokens.
1.3.4. Client Credentials
Client credentials can be used as a license when the scope of authorization is limited to a protected resource under client control or a protected resource that is previously agreed with the authorization server. Typically, client credentials are used as an authorization when the client represents itself as a performer (the client is also the resource owner) or when access to a protected resource is based on an authorization request that was previously agreed with the authorization server.
1.4. Access Tokens
The access token is the credential that is used to access the protected resource. An access token is a string representing the authorization issued to the client. The string is usually opaque to the client. Tokens represent the specific scope and duration of access permissions that are licensed by the resource owner and implemented by the resource server and the authorization server.

Tokens can represent an identifier for retrieving authorization information or can self-contain authorization information in a verifiable manner (the even if card string consists of data and signatures). Additional authentication credentials-beyond the scope of this specification-can be required for the client to use tokens.

An access token provides an abstraction layer that replaces different authorization structures (for example, user names and passwords) with tokens that a single resource server can understand. This abstraction makes issuing an access token more restrictive than issuing a license to obtain a token, while eliminating the need for a resource server to understand the various authentication methods.

Resource server-based security requires access tokens to have different formats, structures, and methods used (for example, cryptographic properties). The properties of the access token and the methods used to access the protected resource are beyond the scope of this specification and are defined in a companion specification such as RFC6750.
1.5. Refresh the 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 fails or expires, or to obtain an additional access token of equal or narrower scope (the access token may have a shorter life cycle and fewer permissions than the resource owner authorized). The issuance of a refresh token is optional and is determined by the authorization server. If the authorization server issues a refresh token, it is included when the access token is issued (that is, step d in Figure 1).

A refresh token is a string that represents the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token represents an identifier that is used to retrieve authorization information. Unlike an access token, the refresh token is designed to be used only with the authorization server and is not sent to the resource server.

+--------+                                           +---------------+
|               |--(A)-------Authorization Grant--------->| |
|                                           |               | |
|               |<-(B)-----------Access Token-------------| |
|               |               & Refresh Token | |
|                                           |               | |
|                            |               +----------+   | |
|          |--(C)----Access Token---->|   |               | |
|                            |          |   |               | |
| |<-(D)-Protected Resource--|   Resource | | Authorization |
|                            Client |  |   Server |     | Server |
|          |--(E)----Access Token---->|   |               | |
|                            |          |   |               | |
|          |<-(F)-Invalid Token Error-|   |               | |
|                            |               +----------+   | |
|                                           |               | |
|               |--(G)-----------Refresh Token----------->| |
|                                           |               | |
|               |<-(H)-----------Access Token-------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an expired access token

The process shown in Figure 2 contains the following steps:

(A) The client authenticates with the authorization server and presents a licensing request for access tokens.
(B) Authorize the server to authenticate the client and verify the license, and issue an access token and a refresh token if it is valid.
(C) The client initiates a request for a protected resource to the resource server by presenting an access token.
(D) The resource server validates the access token and satisfies that requirement if it is valid.
(E) steps (C) and (D) are repeated until the access token expires. If the client knows that the access token has expired, skip to step (G), otherwise it will continue to initiate another request for the protected resource.
(F) The resource server returned an invalid token error because the access token was invalid.
(G) The client requests a new access token by authenticating with the authorization server and presenting a refresh token. Client authentication requires policy based on the type of client and the authorization server.
(H) Authorize the server to authenticate the client and verify the refresh token, and, if valid, issue a new access token (and-optionally-a new refresh token).
Steps (C), (D), (E) and (F) are outside the scope of this specification, as described in section 7th.
1.6. TLS version
This specification uses Transport Layer Security (TLS) at any time, and a corresponding version (or multiple versions) of TLS based on extensive deployment and known security vulnerabilities will change over time. At the time of writing this specification, TLS version 1.2 RFC5246 is the latest release, but it has a very limited deployment base and may not be ready for implementation. TLS version 1.0 RFC2246 is the most widely deployed version and will provide the broadest interoperability.

Implementations can also support other transport layer security mechanisms that meet their security needs.

1.7. HTTP Redirection
HTTP redirection is widely used in this specification, and this client or authorization server directs the user of the resource owner to another destination address. Although the examples in this specification demonstrate the use of HTTP 302 status codes, any other method of redirecting through the user agent is allowed and considered as implementation details.
1.8. Interoperability
OAuth 2.0 provides a rich framework of authorization with a clear security nature. However, although it appears to itself to be a rich and highly extensible framework with many optional components, this specification has the potential to produce many non-interoperable implementations.

In addition, some of the required components in this specification are left partially or completely undefined (for example, client registration, licensing server performance, endpoint discovery, and so on). Without these components, the client must be manually and specifically configured for interoperability with specific licensing servers and resource servers.

The framework is designed with a clear expectation that future work will define the prescriptive configuration and extensions required to achieve complete web-wide interoperability.

1.9. Symbolic conventions
The keywords in this specification are "must", "cannot", "required", "want", "Do not", "should", "should not", "recommended", "Can" and "optional" as explained in RFC2119. This specification uses RFC5234 's extended Backus-Noel Paradigm (ABNF) notation. In addition, rule URI references from the Uniform Resource Identifier (URI): Universal syntax RFC3986 are also included.

Certain security-related terms are understood in accordance with the meanings defined in RFC4949. These terms include, but are not limited to: "Attack", "Authentication", "Authorization", "certificate", "Confidential", "credential", "Encryption", "Identity", "token", "signature", "Trust", "Authentication" and "verification".

Unless otherwise noted, the names and values of all protocol parameters are case-sensitive.

Oauth2 Manual Chapter I.