OAuth2标准文档（RFC6749）

Internet Engineering Task Force (IETF) D. Hardt, Ed.

Request for Comments: 6749 Microsoft

Obsoletes:

5849 October 2012

Category: Standards Track

ISSN: 2070-1721

The OAuth 2.0 Authorization Framework

Abstract

The OAuth 2.0 authorization framework enables a third-party

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force

(IETF). It represents the consensus of the IETF community. It has

received public review and has been approved for publication by the

Internet Engineering Steering Group (IESG). Further information on

Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,

and how to provide feedback on it may be obtained at

Provisions Relating to IETF Documents

(

http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Hardt Standards Track [Page 1]

RFC 6749

1.1. Roles ......................................................6

1.3.2. Implicit ............................................8

1.3.3. Resource Owner Password Credentials .................9

1.3.4. Client Credentials ..................................9

1.4. Access Token ..............................................10

1.5. Refresh Token .............................................10

1.6. TLS Version ...............................................12

1.8. Interoperability ..........................................12

1.9. Notational Conventions ....................................13

2. Client Registration ............................................13

2.1. Client Types ..............................................14

3. Protocol Endpoints .............................................18

3.1.1. Response Type ......................................19

3.1.2. Redirection Endpoint ...............................19

3.2.1. Client Authentication ..............................22

3.3. Access Token Scope ........................................23

4. Obtaining Authorization ........................................23

4.1. Authorization Code Grant ..................................24

4.1.1. Authorization Request ..............................25

4.1.2. Authorization Response .............................26

4.1.4. Access Token Response ..............................30

4.2. Implicit Grant ............................................31

4.2.1. Authorization Request ..............................33

4.4.1. Authorization Request and Response .................41

4.4.2. Access Token Request ...............................41

4.4.3. Access Token Response ..............................42

4.5. Extension Grants ..........................................42

Hardt Standards Track [Page 2]

RFC 6749

5. Issuing an Access Token ........................................43

5.1. Successful Response .......................................43

6. Refreshing an Access Token .....................................47

8. Extensibility ..................................................50

8.1. Defining Access Token Types ...............................50

8.2. Defining New Endpoint Parameters ..........................50

8.3. Defining New Authorization Grant Types ....................51

8.4. Defining New Authorization Endpoint Response Types ........51

8.5. Defining Additional Error Codes ...........................51

10. Security Considerations .......................................53

10.1. Client Authentication ....................................53

10.2. Client Impersonation .....................................54

10.3. Access Tokens ............................................55

10.9. Ensuring Endpoint Authenticity ...........................58

10.11. Phishing Attacks ........................................58

10.12. Cross-Site Request Forgery ..............................59

10.14. Code Injection and Input Validation .....................60

10.15. Open Redirectors ........................................60

10.16. Misuse of Access Token to Impersonate Resource

Owner in Implicit Flow ..................................

61

11. IANA Considerations ...........................................62

11.1. OAuth Access Token Types Registry ........................62

11.2. OAuth Parameters Registry ................................63

11.2.1. Registration Template .............................63

11.2.2. Initial Registry Contents .........................64

12.1. Normative References .....................................68

12.2. Informative References ...................................70

Hardt Standards Track [Page 3]

RFC 6749

Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71

A.1. "client_id" Syntax ........................................71

A.3. "response_type" Syntax ....................................71

A.7. "error" Syntax ............................................72

A.8. "error_description" Syntax ................................72

A.9. "error_uri" Syntax ........................................72

A.10. "grant_type" Syntax .......................................73

A.11. "code" Syntax .............................................73

A.12. "access_token" Syntax .....................................73

A.14. "expires_in" Syntax .......................................73

A.15. "username" Syntax .........................................73

A.16. "password" Syntax .........................................73

A.17. "refresh_token" Syntax ....................................74

1

In the traditional client-server authentication model, the client

owner’s credentials for future use, typically a password in

clear-text.

o Servers are required to support password authentication, despite

the security weaknesses inherent in passwords.

o Third-party applications gain overly broad access to the resource

owner’s protected resources, leaving resource owners without any

ability to restrict duration or access to a limited subset of

resources.

o Resource owners cannot revoke access to an individual third party

without revoking access to all third parties, and must do so by

RFC 6749

by the resource owner and hosted by the resource server, and is

issued a different set of credentials than those of the resource

owner.

Instead of using the resource owner’s credentials to access protected

resources, the client obtains an access token -- a string denoting a

specific scope, lifetime, and other access attributes. Access tokens

are issued to third-party clients by an authorization server with the

approval of the resource owner. The client uses the access token to

access the protected resources hosted by the resource server.

For example, an end-user (resource owner) can grant a printing

service (client) access to her protected photos stored at a photo-

specific credentials (access token).

RFC2616]). The

Standards Track specification builds on the OAuth 1.0 deployment

experience, as well as additional use cases and extensibility

requirements gathered from the wider IETF community. The OAuth 2.0

protocol is not backward compatible with OAuth 1.0. The two versions

may co-exist on the network, and implementations may choose to

support both. However, it is the intention of this specification

that new implementations support OAuth 2.0 as specified in this

document and that OAuth 1.0 is used only to support existing

details with the OAuth 1.0 protocol. Implementers familiar with

OAuth 1.0 should approach this document without any assumptions as to