1. Internet Engineering Task Force (IETF)                     D. Hardt, Ed.
  2. Request for Comments: 6749                                     Microsoft
  3. Obsoletes: 5849                                             October 2012
  4. Category: Standards Track
  5. ISSN: 2070-1721

The OAuth 2.0 Authorization Framework

  1.  
  2. Abstract
  3.  
  4.    The OAuth 2.0 authorization framework enables a third-party
  5.    application to obtain limited access to an HTTP service, either on
  6.    behalf of a resource owner by orchestrating an approval interaction
  7.    between the resource owner and the HTTP service, or by allowing the
  8.    third-party application to obtain access on its own behalf.  This
  9.    specification replaces and obsoletes the OAuth 1.0 protocol described
  10.    in RFC 5849.
  11.  
  12. Status of This Memo
  13.  
  14.    This is an Internet Standards Track document.
  15.  
  16.    This document is a product of the Internet Engineering Task Force
  17.    (IETF).  It represents the consensus of the IETF community.  It has
  18.    received public review and has been approved for publication by the
  19.    Internet Engineering Steering Group (IESG).  Further information on
  20.    Internet Standards is available in Section 2 of RFC 5741.
  21.  
  22.    Information about the current status of this document, any errata,
  23.    and how to provide feedback on it may be obtained at
  24.    http://www.rfc-editor.org/info/rfc6749.
  25.  
  26. Copyright Notice
  27.  
  28.    Copyright (c) 2012 IETF Trust and the persons identified as the
  29.    document authors.  All rights reserved.
  30.  
  31.    This document is subject to BCP 78 and the IETF Trust's Legal
  32.    Provisions Relating to IETF Documents
  33.    (http://trustee.ietf.org/license-info) in effect on the date of
  34.    publication of this document.  Please review these documents
  35.    carefully, as they describe your rights and restrictions with respect
  36.    to this document.  Code Components extracted from this document must
  37.    include Simplified BSD License text as described in Section 4.e of
  38.    the Trust Legal Provisions and are provided without warranty as
  39.    described in the Simplified BSD License.
  40.  
  41. Hardt                        Standards Track                    [Page 1]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3. Table of Contents
  4.  
  5.    1. Introduction ....................................................4
  6.       1.1. Roles ......................................................6
  7.       1.2. Protocol Flow ..............................................7
  8.       1.3. Authorization Grant ........................................8
  9.            1.3.1. Authorization Code ..................................8
  10.            1.3.2. Implicit ............................................8
  11.            1.3.3. Resource Owner Password Credentials .................9
  12.            1.3.4. Client Credentials ..................................9
  13.       1.4. Access Token ..............................................10
  14.       1.5. Refresh Token .............................................10
  15.       1.6. TLS Version ...............................................12
  16.       1.7. HTTP Redirections .........................................12
  17.       1.8. Interoperability ..........................................12
  18.       1.9. Notational Conventions ....................................13
  19.    2. Client Registration ............................................13
  20.       2.1. Client Types ..............................................14
  21.       2.2. Client Identifier .........................................15
  22.       2.3. Client Authentication .....................................16
  23.            2.3.1. Client Password ....................................16
  24.            2.3.2. Other Authentication Methods .......................17
  25.       2.4. Unregistered Clients ......................................17
  26.    3. Protocol Endpoints .............................................18
  27.       3.1. Authorization Endpoint ....................................18
  28.            3.1.1. Response Type ......................................19
  29.            3.1.2. Redirection Endpoint ...............................19
  30.       3.2. Token Endpoint ............................................21
  31.            3.2.1. Client Authentication ..............................22
  32.       3.3. Access Token Scope ........................................23
  33.    4. Obtaining Authorization ........................................23
  34.       4.1. Authorization Code Grant ..................................24
  35.            4.1.1. Authorization Request ..............................25
  36.            4.1.2. Authorization Response .............................26
  37.            4.1.3. Access Token Request ...............................29
  38.            4.1.4. Access Token Response ..............................30
  39.       4.2. Implicit Grant ............................................31
  40.            4.2.1. Authorization Request ..............................33
  41.            4.2.2. Access Token Response ..............................35
  42.       4.3. Resource Owner Password Credentials Grant .................37
  43.            4.3.1. Authorization Request and Response .................39
  44.            4.3.2. Access Token Request ...............................39
  45.            4.3.3. Access Token Response ..............................40
  46.       4.4. Client Credentials Grant ..................................40
  47.            4.4.1. Authorization Request and Response .................41
  48.            4.4.2. Access Token Request ...............................41
  49.            4.4.3. Access Token Response ..............................42
  50.       4.5. Extension Grants ..........................................42
  51.  
  52. Hardt                        Standards Track                    [Page 2]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    5. Issuing an Access Token ........................................43
  4.       5.1. Successful Response .......................................43
  5.       5.2. Error Response ............................................45
  6.    6. Refreshing an Access Token .....................................47
  7.    7. Accessing Protected Resources ..................................48
  8.       7.1. Access Token Types ........................................49
  9.       7.2. Error Response ............................................49
  10.    8. Extensibility ..................................................50
  11.       8.1. Defining Access Token Types ...............................50
  12.       8.2. Defining New Endpoint Parameters ..........................50
  13.       8.3. Defining New Authorization Grant Types ....................51
  14.       8.4. Defining New Authorization Endpoint Response Types ........51
  15.       8.5. Defining Additional Error Codes ...........................51
  16.    9. Native Applications ............................................52
  17.    10. Security Considerations .......................................53
  18.       10.1. Client Authentication ....................................53
  19.       10.2. Client Impersonation .....................................54
  20.       10.3. Access Tokens ............................................55
  21.       10.4. Refresh Tokens ...........................................55
  22.       10.5. Authorization Codes ......................................56
  23.       10.6. Authorization Code Redirection URI Manipulation ..........56
  24.       10.7. Resource Owner Password Credentials ......................57
  25.       10.8. Request Confidentiality ..................................58
  26.       10.9. Ensuring Endpoint Authenticity ...........................58
  27.       10.10. Credentials-Guessing Attacks ............................58
  28.       10.11. Phishing Attacks ........................................58
  29.       10.12. Cross-Site Request Forgery ..............................59
  30.       10.13. Clickjacking ............................................60
  31.       10.14. Code Injection and Input Validation .....................60
  32.       10.15. Open Redirectors ........................................60
  33.       10.16. Misuse of Access Token to Impersonate Resource
  34.              Owner in Implicit Flow ..................................61
  35.    11. IANA Considerations ...........................................62
  36.       11.1. OAuth Access Token Types Registry ........................62
  37.            11.1.1. Registration Template .............................62
  38.       11.2. OAuth Parameters Registry ................................63
  39.            11.2.1. Registration Template .............................63
  40.            11.2.2. Initial Registry Contents .........................64
  41.       11.3. OAuth Authorization Endpoint Response Types Registry .....66
  42.            11.3.1. Registration Template .............................66
  43.            11.3.2. Initial Registry Contents .........................67
  44.       11.4. OAuth Extensions Error Registry ..........................67
  45.            11.4.1. Registration Template .............................68
  46.    12. References ....................................................68
  47.       12.1. Normative References .....................................68
  48.       12.2. Informative References ...................................70
  49.  
  50. Hardt                        Standards Track                    [Page 3]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71
  4.      A.1.  "client_id" Syntax ........................................71
  5.      A.2.  "client_secret" Syntax ....................................71
  6.      A.3.  "response_type" Syntax ....................................71
  7.      A.4.  "scope" Syntax ............................................72
  8.      A.5.  "state" Syntax ............................................72
  9.      A.6.  "redirect_uri" Syntax .....................................72
  10.      A.7.  "error" Syntax ............................................72
  11.      A.8.  "error_description" Syntax ................................72
  12.      A.9.  "error_uri" Syntax ........................................72
  13.      A.10. "grant_type" Syntax .......................................73
  14.      A.11. "code" Syntax .............................................73
  15.      A.12. "access_token" Syntax .....................................73
  16.      A.13. "token_type" Syntax .......................................73
  17.      A.14. "expires_in" Syntax .......................................73
  18.      A.15. "username" Syntax .........................................73
  19.      A.16. "password" Syntax .........................................73
  20.      A.17. "refresh_token" Syntax ....................................74
  21.      A.18. Endpoint Parameter Syntax .................................74
  22.    Appendix B. Use of application/x-www-form-urlencoded Media Type ...74
  23.    Appendix C. Acknowledgements ......................................75

1. Introduction

  1.  
  2.    In the traditional client-server authentication model, the client
  3.    requests an access-restricted resource (protected resource) on the
  4.    server by authenticating with the server using the resource owner's
  5.    credentials.  In order to provide third-party applications access to
  6.    restricted resources, the resource owner shares its credentials with
  7.    the third party.  This creates several problems and limitations:
  8.  
  9.    o  Third-party applications are required to store the resource
  10.       owner's credentials for future use, typically a password in
  11.       clear-text.
  12.  
  13.    o  Servers are required to support password authentication, despite
  14.       the security weaknesses inherent in passwords.
  15.  
  16.    o  Third-party applications gain overly broad access to the resource
  17.       owner's protected resources, leaving resource owners without any
  18.       ability to restrict duration or access to a limited subset of
  19.       resources.
  20.  
  21.    o  Resource owners cannot revoke access to an individual third party
  22.       without revoking access to all third parties, and must do so by
  23.       changing the third party's password.
  24.  
  25. Hardt                        Standards Track                    [Page 4]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    o  Compromise of any third-party application results in compromise of
  4.       the end-user's password and all of the data protected by that
  5.       password.
  6.  
  7.    OAuth addresses these issues by introducing an authorization layer
  8.    and separating the role of the client from that of the resource
  9.    owner.  In OAuth, the client requests access to resources controlled
  10.    by the resource owner and hosted by the resource server, and is
  11.    issued a different set of credentials than those of the resource
  12.    owner.
  13.  
  14.    Instead of using the resource owner's credentials to access protected
  15.    resources, the client obtains an access token -- a string denoting a
  16.    specific scope, lifetime, and other access attributes.  Access tokens
  17.    are issued to third-party clients by an authorization server with the
  18.    approval of the resource owner.  The client uses the access token to
  19.    access the protected resources hosted by the resource server.
  20.  
  21.    For example, an end-user (resource owner) can grant a printing
  22.    service (client) access to her protected photos stored at a photo-
  23.    sharing service (resource server), without sharing her username and
  24.    password with the printing service.  Instead, she authenticates
  25.    directly with a server trusted by the photo-sharing service
  26.    (authorization server), which issues the printing service delegation-
  27.    specific credentials (access token).
  28.  
  29.    This specification is designed for use with HTTP ([RFC2616]).  The
  30.    use of OAuth over any protocol other than HTTP is out of scope.
  31.  
  32.    The OAuth 1.0 protocol ([RFC5849]), published as an informational
  33.    document, was the result of a small ad hoc community effort.  This
  34.    Standards Track specification builds on the OAuth 1.0 deployment
  35.    experience, as well as additional use cases and extensibility
  36.    requirements gathered from the wider IETF community.  The OAuth 2.0
  37.    protocol is not backward compatible with OAuth 1.0.  The two versions
  38.    may co-exist on the network, and implementations may choose to
  39.    support both.  However, it is the intention of this specification
  40.    that new implementations support OAuth 2.0 as specified in this
  41.    document and that OAuth 1.0 is used only to support existing
  42.    deployments.  The OAuth 2.0 protocol shares very few implementation
  43.    details with the OAuth 1.0 protocol.  Implementers familiar with
  44.    OAuth 1.0 should approach this document without any assumptions as to
  45.    its structure and details.
  46.  
  47. Hardt                        Standards Track                    [Page 5]

  1. RFC 6749                        OAuth 2.0                   October 2012

1.1. Roles

  1.  
  2.    OAuth defines four roles:
  3.  
  4.    resource owner
  5.       An entity capable of granting access to a protected resource.
  6.       When the resource owner is a person, it is referred to as an
  7.       end-user.
  8.  
  9.    resource server
  10.       The server hosting the protected resources, capable of accepting
  11.       and responding to protected resource requests using access tokens.
  12.  
  13.    client
  14.       An application making protected resource requests on behalf of the
  15.       resource owner and with its authorization.  The term "client" does
  16.       not imply any particular implementation characteristics (e.g.,
  17.       whether the application executes on a server, a desktop, or other
  18.       devices).
  19.  
  20.    authorization server
  21.       The server issuing access tokens to the client after successfully
  22.       authenticating the resource owner and obtaining authorization.
  23.  
  24.    The interaction between the authorization server and resource server
  25.    is beyond the scope of this specification.  The authorization server
  26.    may be the same server as the resource server or a separate entity.
  27.    A single authorization server may issue access tokens accepted by
  28.    multiple resource servers.
  29.  
  30. Hardt                        Standards Track                    [Page 6]

  1. RFC 6749                        OAuth 2.0                   October 2012

1.2. Protocol Flow

  1.  
  2.      +--------+                               +---------------+
  3.      |        |--(A)- Authorization Request ->|   Resource    |
  4.      |        |                               |     Owner     |
  5.      |        |<-(B)-- Authorization Grant ---|               |
  6.      |        |                               +---------------+
  7.      |        |
  8.      |        |                               +---------------+
  9.      |        |--(C)-- Authorization Grant -->| Authorization |
  10.      | Client |                               |     Server    |
  11.      |        |<-(D)----- Access Token -------|               |
  12.      |        |                               +---------------+
  13.      |        |
  14.      |        |                               +---------------+
  15.      |        |--(E)----- Access Token ------>|    Resource   |
  16.      |        |                               |     Server    |
  17.      |        |<-(F)--- Protected Resource ---|               |
  18.      +--------+                               +---------------+
  19.  
  20.                      Figure 1: Abstract Protocol Flow
  21.  
  22.    The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
  23.    interaction between the four roles and includes the following steps:
  24.  
  25.    (A)  The client requests authorization from the resource owner.  The
  26.         authorization request can be made directly to the resource owner
  27.         (as shown), or preferably indirectly via the authorization
  28.         server as an intermediary.
  29.  
  30.    (B)  The client receives an authorization grant, which is a
  31.         credential representing the resource owner's authorization,
  32.         expressed using one of four grant types defined in this
  33.         specification or using an extension grant type.  The
  34.         authorization grant type depends on the method used by the
  35.         client to request authorization and the types supported by the
  36.         authorization server.
  37.  
  38.    (C)  The client requests an access token by authenticating with the
  39.         authorization server and presenting the authorization grant.
  40.  
  41.    (D)  The authorization server authenticates the client and validates
  42.         the authorization grant, and if valid, issues an access token.
  43.  
  44. Hardt                        Standards Track                    [Page 7]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    (E)  The client requests the protected resource from the resource
  4.         server and authenticates by presenting the access token.
  5.  
  6.    (F)  The resource server validates the access token, and if valid,
  7.         serves the request.
  8.  
  9.    The preferred method for the client to obtain an authorization grant
  10.    from the resource owner (depicted in steps (A) and (B)) is to use the
  11.    authorization server as an intermediary, which is illustrated in
  12.    Figure 3 in Section 4.1.

1.3. Authorization Grant

  1.  
  2.    An authorization grant is a credential representing the resource
  3.    owner's authorization (to access its protected resources) used by the
  4.    client to obtain an access token.  This specification defines four
  5.    grant types -- authorization code, implicit, resource owner password
  6.    credentials, and client credentials -- as well as an extensibility
  7.    mechanism for defining additional types.

1.3.1. Authorization Code

  1.  
  2.    The authorization code is obtained by using an authorization server
  3.    as an intermediary between the client and resource owner.  Instead of
  4.    requesting authorization directly from the resource owner, the client
  5.    directs the resource owner to an authorization server (via its
  6.    user-agent as defined in [RFC2616]), which in turn directs the
  7.    resource owner back to the client with the authorization code.
  8.  
  9.    Before directing the resource owner back to the client with the
  10.    authorization code, the authorization server authenticates the
  11.    resource owner and obtains authorization.  Because the resource owner
  12.    only authenticates with the authorization server, the resource
  13.    owner's credentials are never shared with the client.
  14.  
  15.    The authorization code provides a few important security benefits,
  16.    such as the ability to authenticate the client, as well as the
  17.    transmission of the access token directly to the client without
  18.    passing it through the resource owner's user-agent and potentially
  19.    exposing it to others, including the resource owner.

1.3.2. Implicit

  1.  
  2.    The implicit grant is a simplified authorization code flow optimized
  3.    for clients implemented in a browser using a scripting language such
  4.    as JavaScript.  In the implicit flow, instead of issuing the client
  5.    an authorization code, the client is issued an access token directly
  6.  
  7. Hardt                        Standards Track                    [Page 8]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    (as the result of the resource owner authorization).  The grant type
  4.    is implicit, as no intermediate credentials (such as an authorization
  5.    code) are issued (and later used to obtain an access token).
  6.  
  7.    When issuing an access token during the implicit grant flow, the
  8.    authorization server does not authenticate the client.  In some
  9.    cases, the client identity can be verified via the redirection URI
  10.    used to deliver the access token to the client.  The access token may
  11.    be exposed to the resource owner or other applications with access to
  12.    the resource owner's user-agent.
  13.  
  14.    Implicit grants improve the responsiveness and efficiency of some
  15.    clients (such as a client implemented as an in-browser application),
  16.    since it reduces the number of round trips required to obtain an
  17.    access token.  However, this convenience should be weighed against
  18.    the security implications of using implicit grants, such as those
  19.    described in Sections 10.3 and 10.16, especially when the
  20.    authorization code grant type is available.

1.3.3. Resource Owner Password Credentials

  1.  
  2.    The resource owner password credentials (i.e., username and password)
  3.    can be used directly as an authorization grant to obtain an access
  4.    token.  The credentials should only be used when there is a high
  5.    degree of trust between the resource owner and the client (e.g., the
  6.    client is part of the device operating system or a highly privileged
  7.    application), and when other authorization grant types are not
  8.    available (such as an authorization code).
  9.  
  10.    Even though this grant type requires direct client access to the
  11.    resource owner credentials, the resource owner credentials are used
  12.    for a single request and are exchanged for an access token.  This
  13.    grant type can eliminate the need for the client to store the
  14.    resource owner credentials for future use, by exchanging the
  15.    credentials with a long-lived access token or refresh token.

1.3.4. Client Credentials

  1.  
  2.    The client credentials (or other forms of client authentication) can
  3.    be used as an authorization grant when the authorization scope is
  4.    limited to the protected resources under the control of the client,
  5.    or to protected resources previously arranged with the authorization
  6.    server.  Client credentials are used as an authorization grant
  7.    typically when the client is acting on its own behalf (the client is
  8.    also the resource owner) or is requesting access to protected
  9.    resources based on an authorization previously arranged with the
  10.    authorization server.
  11.  
  12. Hardt                        Standards Track                    [Page 9]

  1. RFC 6749                        OAuth 2.0                   October 2012

1.4. Access Token

  1.  
  2.    Access tokens are credentials used to access protected resources.  An
  3.    access token is a string representing an authorization issued to the
  4.    client.  The string is usually opaque to the client.  Tokens
  5.    represent specific scopes and durations of access, granted by the
  6.    resource owner, and enforced by the resource server and authorization
  7.    server.
  8.  
  9.    The token may denote an identifier used to retrieve the authorization
  10.    information or may self-contain the authorization information in a
  11.    verifiable manner (i.e., a token string consisting of some data and a
  12.    signature).  Additional authentication credentials, which are beyond
  13.    the scope of this specification, may be required in order for the
  14.    client to use a token.
  15.  
  16.    The access token provides an abstraction layer, replacing different
  17.    authorization constructs (e.g., username and password) with a single
  18.    token understood by the resource server.  This abstraction enables
  19.    issuing access tokens more restrictive than the authorization grant
  20.    used to obtain them, as well as removing the resource server's need
  21.    to understand a wide range of authentication methods.
  22.  
  23.    Access tokens can have different formats, structures, and methods of
  24.    utilization (e.g., cryptographic properties) based on the resource
  25.    server security requirements.  Access token attributes and the
  26.    methods used to access protected resources are beyond the scope of
  27.    this specification and are defined by companion specifications such
  28.    as [RFC6750].

1.5. Refresh Token

  1.  
  2.    Refresh tokens are credentials used to obtain access tokens.  Refresh
  3.    tokens are issued to the client by the authorization server and are
  4.    used to obtain a new access token when the current access token
  5.    becomes invalid or expires, or to obtain additional access tokens
  6.    with identical or narrower scope (access tokens may have a shorter
  7.    lifetime and fewer permissions than authorized by the resource
  8.    owner).  Issuing a refresh token is optional at the discretion of the
  9.    authorization server.  If the authorization server issues a refresh
  10.    token, it is included when issuing an access token (i.e., step (D) in
  11.    Figure 1).
  12.  
  13.    A refresh token is a string representing the authorization granted to
  14.    the client by the resource owner.  The string is usually opaque to
  15.    the client.  The token denotes an identifier used to retrieve the
  16.  
  17. Hardt                        Standards Track                   [Page 10]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    authorization information.  Unlike access tokens, refresh tokens are
  4.    intended for use only with authorization servers and are never sent
  5.    to resource servers.
  6.  
  7.   +--------+                                           +---------------+
  8.   |        |--(A)------- Authorization Grant --------->|               |
  9.   |        |                                           |               |
  10.   |        |<-(B)----------- Access Token -------------|               |
  11.   |        |               & Refresh Token             |               |
  12.   |        |                                           |               |
  13.   |        |                            +----------+   |               |
  14.   |        |--(C)---- Access Token ---->|          |   |               |
  15.   |        |                            |          |   |               |
  16.   |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  17.   | Client |                            |  Server  |   |     Server    |
  18.   |        |--(E)---- Access Token ---->|          |   |               |
  19.   |        |                            |          |   |               |
  20.   |        |<-(F)- Invalid Token Error -|          |   |               |
  21.   |        |                            +----------+   |               |
  22.   |        |                                           |               |
  23.   |        |--(G)----------- Refresh Token ----------->|               |
  24.   |        |                                           |               |
  25.   |        |<-(H)----------- Access Token -------------|               |
  26.   +--------+           & Optional Refresh Token        +---------------+
  27.  
  28.                Figure 2: Refreshing an Expired Access Token
  29.  
  30.    The flow illustrated in Figure 2 includes the following steps:
  31.  
  32.    (A)  The client requests an access token by authenticating with the
  33.         authorization server and presenting an authorization grant.
  34.  
  35.    (B)  The authorization server authenticates the client and validates
  36.         the authorization grant, and if valid, issues an access token
  37.         and a refresh token.
  38.  
  39.    (C)  The client makes a protected resource request to the resource
  40.         server by presenting the access token.
  41.  
  42.    (D)  The resource server validates the access token, and if valid,
  43.         serves the request.
  44.  
  45.    (E)  Steps (C) and (D) repeat until the access token expires.  If the
  46.         client knows the access token expired, it skips to step (G);
  47.         otherwise, it makes another protected resource request.
  48.  
  49.    (F)  Since the access token is invalid, the resource server returns
  50.         an invalid token error.
  51.  
  52. Hardt                        Standards Track                   [Page 11]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    (G)  The client requests a new access token by authenticating with
  4.         the authorization server and presenting the refresh token.  The
  5.         client authentication requirements are based on the client type
  6.         and on the authorization server policies.
  7.  
  8.    (H)  The authorization server authenticates the client and validates
  9.         the refresh token, and if valid, issues a new access token (and,
  10.         optionally, a new refresh token).
  11.  
  12.    Steps (C), (D), (E), and (F) are outside the scope of this
  13.    specification, as described in Section 7.

1.6. TLS Version

  1.  
  2.    Whenever Transport Layer Security (TLS) is used by this
  3.    specification, the appropriate version (or versions) of TLS will vary
  4.    over time, based on the widespread deployment and known security
  5.    vulnerabilities.  At the time of this writing, TLS version 1.2
  6.    [RFC5246] is the most recent version, but has a very limited
  7.    deployment base and might not be readily available for
  8.    implementation.  TLS version 1.0 [RFC2246] is the most widely
  9.    deployed version and will provide the broadest interoperability.
  10.  
  11.    Implementations MAY also support additional transport-layer security
  12.    mechanisms that meet their security requirements.

1.7. HTTP Redirections

  1.  
  2.    This specification makes extensive use of HTTP redirections, in which
  3.    the client or the authorization server directs the resource owner's
  4.    user-agent to another destination.  While the examples in this
  5.    specification show the use of the HTTP 302 status code, any other
  6.    method available via the user-agent to accomplish this redirection is
  7.    allowed and is considered to be an implementation detail.

1.8. Interoperability

  1.  
  2.    OAuth 2.0 provides a rich authorization framework with well-defined
  3.    security properties.  However, as a rich and highly extensible
  4.    framework with many optional components, on its own, this
  5.    specification is likely to produce a wide range of non-interoperable
  6.    implementations.
  7.  
  8.    In addition, this specification leaves a few required components
  9.    partially or fully undefined (e.g., client registration,
  10.    authorization server capabilities, endpoint discovery).  Without
  11.  
  12. Hardt                        Standards Track                   [Page 12]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    these components, clients must be manually and specifically
  4.    configured against a specific authorization server and resource
  5.    server in order to interoperate.
  6.  
  7.    This framework was designed with the clear expectation that future
  8.    work will define prescriptive profiles and extensions necessary to
  9.    achieve full web-scale interoperability.

1.9. Notational Conventions

  1.  
  2.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  3.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  4.    specification are to be interpreted as described in [RFC2119].
  5.  
  6.    This specification uses the Augmented Backus-Naur Form (ABNF)
  7.    notation of [RFC5234].  Additionally, the rule URI-reference is
  8.    included from "Uniform Resource Identifier (URI): Generic Syntax"
  9.    [RFC3986].
  10.  
  11.    Certain security-related terms are to be understood in the sense
  12.    defined in [RFC4949].  These terms include, but are not limited to,
  13.    "attack", "authentication", "authorization", "certificate",
  14.    "confidentiality", "credential", "encryption", "identity", "sign",
  15.    "signature", "trust", "validate", and "verify".
  16.  
  17.    Unless otherwise noted, all the protocol parameter names and values
  18.    are case sensitive.

2. Client Registration

  1.  
  2.    Before initiating the protocol, the client registers with the
  3.    authorization server.  The means through which the client registers
  4.    with the authorization server are beyond the scope of this
  5.    specification but typically involve end-user interaction with an HTML
  6.    registration form.
  7.  
  8.    Client registration does not require a direct interaction between the
  9.    client and the authorization server.  When supported by the
  10.    authorization server, registration can rely on other means for
  11.    establishing trust and obtaining the required client properties
  12.    (e.g., redirection URI, client type).  For example, registration can
  13.    be accomplished using a self-issued or third-party-issued assertion,
  14.    or by the authorization server performing client discovery using a
  15.    trusted channel.
  16.  
  17. Hardt                        Standards Track                   [Page 13]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    When registering a client, the client developer SHALL:
  4.  
  5.    o  specify the client type as described in Section 2.1,
  6.  
  7.    o  provide its client redirection URIs as described in Section 3.1.2,
  8.       and
  9.  
  10.    o  include any other information required by the authorization server
  11.       (e.g., application name, website, description, logo image, the
  12.       acceptance of legal terms).

2.1. Client Types

  1.  
  2.    OAuth defines two client types, based on their ability to
  3.    authenticate securely with the authorization server (i.e., ability to
  4.    maintain the confidentiality of their client credentials):
  5.  
  6.    confidential
  7.       Clients capable of maintaining the confidentiality of their
  8.       credentials (e.g., client implemented on a secure server with
  9.       restricted access to the client credentials), or capable of secure
  10.       client authentication using other means.
  11.  
  12.    public
  13.       Clients incapable of maintaining the confidentiality of their
  14.       credentials (e.g., clients executing on the device used by the
  15.       resource owner, such as an installed native application or a web
  16.       browser-based application), and incapable of secure client
  17.       authentication via any other means.
  18.  
  19.    The client type designation is based on the authorization server's
  20.    definition of secure authentication and its acceptable exposure
  21.    levels of client credentials.  The authorization server SHOULD NOT
  22.    make assumptions about the client type.
  23.  
  24.    A client may be implemented as a distributed set of components, each
  25.    with a different client type and security context (e.g., a
  26.    distributed client with both a confidential server-based component
  27.    and a public browser-based component).  If the authorization server
  28.    does not provide support for such clients or does not provide
  29.    guidance with regard to their registration, the client SHOULD
  30.    register each component as a separate client.
  31.  
  32. Hardt                        Standards Track                   [Page 14]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    This specification has been designed around the following client
  4.    profiles:
  5.  
  6.    web application
  7.       A web application is a confidential client running on a web
  8.       server.  Resource owners access the client via an HTML user
  9.       interface rendered in a user-agent on the device used by the
  10.       resource owner.  The client credentials as well as any access
  11.       token issued to the client are stored on the web server and are
  12.       not exposed to or accessible by the resource owner.
  13.  
  14.    user-agent-based application
  15.       A user-agent-based application is a public client in which the
  16.       client code is downloaded from a web server and executes within a
  17.       user-agent (e.g., web browser) on the device used by the resource
  18.       owner.  Protocol data and credentials are easily accessible (and
  19.       often visible) to the resource owner.  Since such applications
  20.       reside within the user-agent, they can make seamless use of the
  21.       user-agent capabilities when requesting authorization.
  22.  
  23.    native application
  24.       A native application is a public client installed and executed on
  25.       the device used by the resource owner.  Protocol data and
  26.       credentials are accessible to the resource owner.  It is assumed
  27.       that any client authentication credentials included in the
  28.       application can be extracted.  On the other hand, dynamically
  29.       issued credentials such as access tokens or refresh tokens can
  30.       receive an acceptable level of protection.  At a minimum, these
  31.       credentials are protected from hostile servers with which the
  32.       application may interact.  On some platforms, these credentials
  33.       might be protected from other applications residing on the same
  34.       device.

2.2. Client Identifier

  1.  
  2.    The authorization server issues the registered client a client
  3.    identifier -- a unique string representing the registration
  4.    information provided by the client.  The client identifier is not a
  5.    secret; it is exposed to the resource owner and MUST NOT be used
  6.    alone for client authentication.  The client identifier is unique to
  7.    the authorization server.
  8.  
  9.    The client identifier string size is left undefined by this
  10.    specification.  The client should avoid making assumptions about the
  11.    identifier size.  The authorization server SHOULD document the size
  12.    of any identifier it issues.
  13.  
  14. Hardt                        Standards Track                   [Page 15]

  1. RFC 6749                        OAuth 2.0                   October 2012

2.3. Client Authentication

  1.  
  2.    If the client type is confidential, the client and authorization
  3.    server establish a client authentication method suitable for the
  4.    security requirements of the authorization server.  The authorization
  5.    server MAY accept any form of client authentication meeting its
  6.    security requirements.
  7.  
  8.    Confidential clients are typically issued (or establish) a set of
  9.    client credentials used for authenticating with the authorization
  10.    server (e.g., password, public/private key pair).
  11.  
  12.    The authorization server MAY establish a client authentication method
  13.    with public clients.  However, the authorization server MUST NOT rely
  14.    on public client authentication for the purpose of identifying the
  15.    client.
  16.  
  17.    The client MUST NOT use more than one authentication method in each
  18.    request.

2.3.1. Client Password

  1.  
  2.    Clients in possession of a client password MAY use the HTTP Basic
  3.    authentication scheme as defined in [RFC2617] to authenticate with
  4.    the authorization server.  The client identifier is encoded using the
  5.    "application/x-www-form-urlencoded" encoding algorithm per
  6.    Appendix B, and the encoded value is used as the username; the client
  7.    password is encoded using the same algorithm and used as the
  8.    password.  The authorization server MUST support the HTTP Basic
  9.    authentication scheme for authenticating clients that were issued a
  10.    client password.
  11.  
  12.    For example (with extra line breaks for display purposes only):
  13.  
  14.      Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
  15.  
  16.    Alternatively, the authorization server MAY support including the
  17.    client credentials in the request-body using the following
  18.    parameters:
  19.  
  20.    client_id
  21.          REQUIRED.  The client identifier issued to the client during
  22.          the registration process described by Section 2.2.
  23.  
  24.    client_secret
  25.          REQUIRED.  The client secret.  The client MAY omit the
  26.          parameter if the client secret is an empty string.
  27.  
  28. Hardt                        Standards Track                   [Page 16]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Including the client credentials in the request-body using the two
  4.    parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
  5.    to directly utilize the HTTP Basic authentication scheme (or other
  6.    password-based HTTP authentication schemes).  The parameters can only
  7.    be transmitted in the request-body and MUST NOT be included in the
  8.    request URI.
  9.  
  10.    For example, a request to refresh an access token (Section 6) using
  11.    the body parameters (with extra line breaks for display purposes
  12.    only):
  13.  
  14.      POST /token HTTP/1.1
  15.      Host: server.example.com
  16.      Content-Type: application/x-www-form-urlencoded
  17.  
  18.      grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  19.      &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
  20.  
  21.    The authorization server MUST require the use of TLS as described in
  22.    Section 1.6 when sending requests using password authentication.
  23.  
  24.    Since this client authentication method involves a password, the
  25.    authorization server MUST protect any endpoint utilizing it against
  26.    brute force attacks.

2.3.2. Other Authentication Methods

  1.  
  2.    The authorization server MAY support any suitable HTTP authentication
  3.    scheme matching its security requirements.  When using other
  4.    authentication methods, the authorization server MUST define a
  5.    mapping between the client identifier (registration record) and
  6.    authentication scheme.

2.4. Unregistered Clients

  1.  
  2.    This specification does not exclude the use of unregistered clients.
  3.    However, the use of such clients is beyond the scope of this
  4.    specification and requires additional security analysis and review of
  5.    its interoperability impact.
  6.  
  7. Hardt                        Standards Track                   [Page 17]

  1. RFC 6749                        OAuth 2.0                   October 2012

3. Protocol Endpoints

  1.  
  2.    The authorization process utilizes two authorization server endpoints
  3.    (HTTP resources):
  4.  
  5.    o  Authorization endpoint - used by the client to obtain
  6.       authorization from the resource owner via user-agent redirection.
  7.  
  8.    o  Token endpoint - used by the client to exchange an authorization
  9.       grant for an access token, typically with client authentication.
  10.  
  11.    As well as one client endpoint:
  12.  
  13.    o  Redirection endpoint - used by the authorization server to return
  14.       responses containing authorization credentials to the client via
  15.       the resource owner user-agent.
  16.  
  17.    Not every authorization grant type utilizes both endpoints.
  18.    Extension grant types MAY define additional endpoints as needed.

3.1. Authorization Endpoint

  1.  
  2.    The authorization endpoint is used to interact with the resource
  3.    owner and obtain an authorization grant.  The authorization server
  4.    MUST first verify the identity of the resource owner.  The way in
  5.    which the authorization server authenticates the resource owner
  6.    (e.g., username and password login, session cookies) is beyond the
  7.    scope of this specification.
  8.  
  9.    The means through which the client obtains the location of the
  10.    authorization endpoint are beyond the scope of this specification,
  11.    but the location is typically provided in the service documentation.
  12.  
  13.    The endpoint URI MAY include an "application/x-www-form-urlencoded"
  14.    formatted (per Appendix B) query component ([RFC3986] Section 3.4),
  15.    which MUST be retained when adding additional query parameters.  The
  16.    endpoint URI MUST NOT include a fragment component.
  17.  
  18.    Since requests to the authorization endpoint result in user
  19.    authentication and the transmission of clear-text credentials (in the
  20.    HTTP response), the authorization server MUST require the use of TLS
  21.    as described in Section 1.6 when sending requests to the
  22.    authorization endpoint.
  23.  
  24.    The authorization server MUST support the use of the HTTP "GET"
  25.    method [RFC2616] for the authorization endpoint and MAY support the
  26.    use of the "POST" method as well.
  27.  
  28. Hardt                        Standards Track                   [Page 18]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Parameters sent without a value MUST be treated as if they were
  4.    omitted from the request.  The authorization server MUST ignore
  5.    unrecognized request parameters.  Request and response parameters
  6.    MUST NOT be included more than once.

3.1.1. Response Type

  1.  
  2.    The authorization endpoint is used by the authorization code grant
  3.    type and implicit grant type flows.  The client informs the
  4.    authorization server of the desired grant type using the following
  5.    parameter:
  6.  
  7.    response_type
  8.          REQUIRED.  The value MUST be one of "code" for requesting an
  9.          authorization code as described by Section 4.1.1, "token" for
  10.          requesting an access token (implicit grant) as described by
  11.          Section 4.2.1, or a registered extension value as described by
  12.          Section 8.4.
  13.  
  14.    Extension response types MAY contain a space-delimited (%x20) list of
  15.    values, where the order of values does not matter (e.g., response
  16.    type "a b" is the same as "b a").  The meaning of such composite
  17.    response types is defined by their respective specifications.
  18.  
  19.    If an authorization request is missing the "response_type" parameter,
  20.    or if the response type is not understood, the authorization server
  21.    MUST return an error response as described in Section 4.1.2.1.

3.1.2. Redirection Endpoint

  1.  
  2.    After completing its interaction with the resource owner, the
  3.    authorization server directs the resource owner's user-agent back to
  4.    the client.  The authorization server redirects the user-agent to the
  5.    client's redirection endpoint previously established with the
  6.    authorization server during the client registration process or when
  7.    making the authorization request.
  8.  
  9.    The redirection endpoint URI MUST be an absolute URI as defined by
  10.    [RFC3986] Section 4.3.  The endpoint URI MAY include an
  11.    "application/x-www-form-urlencoded" formatted (per Appendix B) query
  12.    component ([RFC3986] Section 3.4), which MUST be retained when adding
  13.    additional query parameters.  The endpoint URI MUST NOT include a
  14.    fragment component.
  15.  
  16. Hardt                        Standards Track                   [Page 19]

  1. RFC 6749                        OAuth 2.0                   October 2012
3.1.2.1. Endpoint Request Confidentiality
  1.  
  2.    The redirection endpoint SHOULD require the use of TLS as described
  3.    in Section 1.6 when the requested response type is "code" or "token",
  4.    or when the redirection request will result in the transmission of
  5.    sensitive credentials over an open network.  This specification does
  6.    not mandate the use of TLS because at the time of this writing,
  7.    requiring clients to deploy TLS is a significant hurdle for many
  8.    client developers.  If TLS is not available, the authorization server
  9.    SHOULD warn the resource owner about the insecure endpoint prior to
  10.    redirection (e.g., display a message during the authorization
  11.    request).
  12.  
  13.    Lack of transport-layer security can have a severe impact on the
  14.    security of the client and the protected resources it is authorized
  15.    to access.  The use of transport-layer security is particularly
  16.    critical when the authorization process is used as a form of
  17.    delegated end-user authentication by the client (e.g., third-party
  18.    sign-in service).
3.1.2.2. Registration Requirements
  1.  
  2.    The authorization server MUST require the following clients to
  3.    register their redirection endpoint:
  4.  
  5.    o  Public clients.
  6.  
  7.    o  Confidential clients utilizing the implicit grant type.
  8.  
  9.    The authorization server SHOULD require all clients to register their
  10.    redirection endpoint prior to utilizing the authorization endpoint.
  11.  
  12.    The authorization server SHOULD require the client to provide the
  13.    complete redirection URI (the client MAY use the "state" request
  14.    parameter to achieve per-request customization).  If requiring the
  15.    registration of the complete redirection URI is not possible, the
  16.    authorization server SHOULD require the registration of the URI
  17.    scheme, authority, and path (allowing the client to dynamically vary
  18.    only the query component of the redirection URI when requesting
  19.    authorization).
  20.  
  21.    The authorization server MAY allow the client to register multiple
  22.    redirection endpoints.
  23.  
  24.    Lack of a redirection URI registration requirement can enable an
  25.    attacker to use the authorization endpoint as an open redirector as
  26.    described in Section 10.15.
  27.  
  28. Hardt                        Standards Track                   [Page 20]

  1. RFC 6749                        OAuth 2.0                   October 2012
3.1.2.3. Dynamic Configuration
  1.  
  2.    If multiple redirection URIs have been registered, if only part of
  3.    the redirection URI has been registered, or if no redirection URI has
  4.    been registered, the client MUST include a redirection URI with the
  5.    authorization request using the "redirect_uri" request parameter.
  6.  
  7.    When a redirection URI is included in an authorization request, the
  8.    authorization server MUST compare and match the value received
  9.    against at least one of the registered redirection URIs (or URI
  10.    components) as defined in [RFC3986] Section 6, if any redirection
  11.    URIs were registered.  If the client registration included the full
  12.    redirection URI, the authorization server MUST compare the two URIs
  13.    using simple string comparison as defined in [RFC3986] Section 6.2.1.
3.1.2.4. Invalid Endpoint
  1.  
  2.    If an authorization request fails validation due to a missing,
  3.    invalid, or mismatching redirection URI, the authorization server
  4.    SHOULD inform the resource owner of the error and MUST NOT
  5.    automatically redirect the user-agent to the invalid redirection URI.
3.1.2.5. Endpoint Content
  1.  
  2.    The redirection request to the client's endpoint typically results in
  3.    an HTML document response, processed by the user-agent.  If the HTML
  4.    response is served directly as the result of the redirection request,
  5.    any script included in the HTML document will execute with full
  6.    access to the redirection URI and the credentials it contains.
  7.  
  8.    The client SHOULD NOT include any third-party scripts (e.g., third-
  9.    party analytics, social plug-ins, ad networks) in the redirection
  10.    endpoint response.  Instead, it SHOULD extract the credentials from
  11.    the URI and redirect the user-agent again to another endpoint without
  12.    exposing the credentials (in the URI or elsewhere).  If third-party
  13.    scripts are included, the client MUST ensure that its own scripts
  14.    (used to extract and remove the credentials from the URI) will
  15.    execute first.

3.2. Token Endpoint

  1.  
  2.    The token endpoint is used by the client to obtain an access token by
  3.    presenting its authorization grant or refresh token.  The token
  4.    endpoint is used with every authorization grant except for the
  5.    implicit grant type (since an access token is issued directly).
  6.  
  7. Hardt                        Standards Track                   [Page 21]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The means through which the client obtains the location of the token
  4.    endpoint are beyond the scope of this specification, but the location
  5.    is typically provided in the service documentation.
  6.  
  7.    The endpoint URI MAY include an "application/x-www-form-urlencoded"
  8.    formatted (per Appendix B) query component ([RFC3986] Section 3.4),
  9.    which MUST be retained when adding additional query parameters.  The
  10.    endpoint URI MUST NOT include a fragment component.
  11.  
  12.    Since requests to the token endpoint result in the transmission of
  13.    clear-text credentials (in the HTTP request and response), the
  14.    authorization server MUST require the use of TLS as described in
  15.    Section 1.6 when sending requests to the token endpoint.
  16.  
  17.    The client MUST use the HTTP "POST" method when making access token
  18.    requests.
  19.  
  20.    Parameters sent without a value MUST be treated as if they were
  21.    omitted from the request.  The authorization server MUST ignore
  22.    unrecognized request parameters.  Request and response parameters
  23.    MUST NOT be included more than once.

3.2.1. Client Authentication

  1.  
  2.    Confidential clients or other clients issued client credentials MUST
  3.    authenticate with the authorization server as described in
  4.    Section 2.3 when making requests to the token endpoint.  Client
  5.    authentication is used for:
  6.  
  7.    o  Enforcing the binding of refresh tokens and authorization codes to
  8.       the client they were issued to.  Client authentication is critical
  9.       when an authorization code is transmitted to the redirection
  10.       endpoint over an insecure channel or when the redirection URI has
  11.       not been registered in full.
  12.  
  13.    o  Recovering from a compromised client by disabling the client or
  14.       changing its credentials, thus preventing an attacker from abusing
  15.       stolen refresh tokens.  Changing a single set of client
  16.       credentials is significantly faster than revoking an entire set of
  17.       refresh tokens.
  18.  
  19.    o  Implementing authentication management best practices, which
  20.       require periodic credential rotation.  Rotation of an entire set
  21.       of refresh tokens can be challenging, while rotation of a single
  22.       set of client credentials is significantly easier.
  23.  
  24. Hardt                        Standards Track                   [Page 22]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    A client MAY use the "client_id" request parameter to identify itself
  4.    when sending requests to the token endpoint.  In the
  5.    "authorization_code" "grant_type" request to the token endpoint, an
  6.    unauthenticated client MUST send its "client_id" to prevent itself
  7.    from inadvertently accepting a code intended for a client with a
  8.    different "client_id".  This protects the client from substitution of
  9.    the authentication code.  (It provides no additional security for the
  10.    protected resource.)

3.3. Access Token Scope

  1.  
  2.    The authorization and token endpoints allow the client to specify the
  3.    scope of the access request using the "scope" request parameter.  In
  4.    turn, the authorization server uses the "scope" response parameter to
  5.    inform the client of the scope of the access token issued.
  6.  
  7.    The value of the scope parameter is expressed as a list of space-
  8.    delimited, case-sensitive strings.  The strings are defined by the
  9.    authorization server.  If the value contains multiple space-delimited
  10.    strings, their order does not matter, and each string adds an
  11.    additional access range to the requested scope.
  12.  
  13.      scope       = scope-token *( SP scope-token )
  14.      scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
  15.  
  16.    The authorization server MAY fully or partially ignore the scope
  17.    requested by the client, based on the authorization server policy or
  18.    the resource owner's instructions.  If the issued access token scope
  19.    is different from the one requested by the client, the authorization
  20.    server MUST include the "scope" response parameter to inform the
  21.    client of the actual scope granted.
  22.  
  23.    If the client omits the scope parameter when requesting
  24.    authorization, the authorization server MUST either process the
  25.    request using a pre-defined default value or fail the request
  26.    indicating an invalid scope.  The authorization server SHOULD
  27.    document its scope requirements and default value (if defined).

4. Obtaining Authorization

  1.  
  2.    To request an access token, the client obtains authorization from the
  3.    resource owner.  The authorization is expressed in the form of an
  4.    authorization grant, which the client uses to request the access
  5.    token.  OAuth defines four grant types: authorization code, implicit,
  6.    resource owner password credentials, and client credentials.  It also
  7.    provides an extension mechanism for defining additional grant types.
  8.  
  9. Hardt                        Standards Track                   [Page 23]

  1. RFC 6749                        OAuth 2.0                   October 2012

4.1. Authorization Code Grant

  1.  
  2.    The authorization code grant type is used to obtain both access
  3.    tokens and refresh tokens and is optimized for confidential clients.
  4.    Since this is a redirection-based flow, the client must be capable of
  5.    interacting with the resource owner's user-agent (typically a web
  6.    browser) and capable of receiving incoming requests (via redirection)
  7.    from the authorization server.
  8.  
  9.      +----------+
  10.      | Resource |
  11.      |   Owner  |
  12.      |          |
  13.      +----------+
  14.           ^
  15.           |
  16.          (B)
  17.      +----|-----+          Client Identifier      +---------------+
  18.      |         -+----(A)-- & Redirection URI ---->|               |
  19.      |  User-   |                                 | Authorization |
  20.      |  Agent  -+----(B)-- User authenticates --->|     Server    |
  21.      |          |                                 |               |
  22.      |         -+----(C)-- Authorization Code ---<|               |
  23.      +-|----|---+                                 +---------------+
  24.        |    |                                         ^      v
  25.       (A)  (C)                                        |      |
  26.        |    |                                         |      |
  27.        ^    v                                         |      |
  28.      +---------+                                      |      |
  29.      |         |>---(D)-- Authorization Code ---------'      |
  30.      |  Client |          & Redirection URI                  |
  31.      |         |                                             |
  32.      |         |<---(E)----- Access Token -------------------'
  33.      +---------+       (w/ Optional Refresh Token)
  34.  
  35.    Note: The lines illustrating steps (A), (B), and (C) are broken into
  36.    two parts as they pass through the user-agent.
  37.  
  38.                      Figure 3: Authorization Code Flow
  39.  
  40. Hardt                        Standards Track                   [Page 24]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The flow illustrated in Figure 3 includes the following steps:
  4.  
  5.    (A)  The client initiates the flow by directing the resource owner's
  6.         user-agent to the authorization endpoint.  The client includes
  7.         its client identifier, requested scope, local state, and a
  8.         redirection URI to which the authorization server will send the
  9.         user-agent back once access is granted (or denied).
  10.  
  11.    (B)  The authorization server authenticates the resource owner (via
  12.         the user-agent) and establishes whether the resource owner
  13.         grants or denies the client's access request.
  14.  
  15.    (C)  Assuming the resource owner grants access, the authorization
  16.         server redirects the user-agent back to the client using the
  17.         redirection URI provided earlier (in the request or during
  18.         client registration).  The redirection URI includes an
  19.         authorization code and any local state provided by the client
  20.         earlier.
  21.  
  22.    (D)  The client requests an access token from the authorization
  23.         server's token endpoint by including the authorization code
  24.         received in the previous step.  When making the request, the
  25.         client authenticates with the authorization server.  The client
  26.         includes the redirection URI used to obtain the authorization
  27.         code for verification.
  28.  
  29.    (E)  The authorization server authenticates the client, validates the
  30.         authorization code, and ensures that the redirection URI
  31.         received matches the URI used to redirect the client in
  32.         step (C).  If valid, the authorization server responds back with
  33.         an access token and, optionally, a refresh token.

4.1.1. Authorization Request

  1.  
  2.    The client constructs the request URI by adding the following
  3.    parameters to the query component of the authorization endpoint URI
  4.    using the "application/x-www-form-urlencoded" format, per Appendix B:
  5.  
  6.    response_type
  7.          REQUIRED.  Value MUST be set to "code".
  8.  
  9.    client_id
  10.          REQUIRED.  The client identifier as described in Section 2.2.
  11.  
  12.    redirect_uri
  13.          OPTIONAL.  As described in Section 3.1.2.
  14.  
  15. Hardt                        Standards Track                   [Page 25]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    scope
  4.          OPTIONAL.  The scope of the access request as described by
  5.          Section 3.3.
  6.  
  7.    state
  8.          RECOMMENDED.  An opaque value used by the client to maintain
  9.          state between the request and callback.  The authorization
  10.          server includes this value when redirecting the user-agent back
  11.          to the client.  The parameter SHOULD be used for preventing
  12.          cross-site request forgery as described in Section 10.12.
  13.  
  14.    The client directs the resource owner to the constructed URI using an
  15.    HTTP redirection response, or by other means available to it via the
  16.    user-agent.
  17.  
  18.    For example, the client directs the user-agent to make the following
  19.    HTTP request using TLS (with extra line breaks for display purposes
  20.    only):
  21.  
  22.     GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
  23.         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  24.     Host: server.example.com
  25.  
  26.    The authorization server validates the request to ensure that all
  27.    required parameters are present and valid.  If the request is valid,
  28.    the authorization server authenticates the resource owner and obtains
  29.    an authorization decision (by asking the resource owner or by
  30.    establishing approval via other means).
  31.  
  32.    When a decision is established, the authorization server directs the
  33.    user-agent to the provided client redirection URI using an HTTP
  34.    redirection response, or by other means available to it via the
  35.    user-agent.

4.1.2. Authorization Response

  1.  
  2.    If the resource owner grants the access request, the authorization
  3.    server issues an authorization code and delivers it to the client by
  4.    adding the following parameters to the query component of the
  5.    redirection URI using the "application/x-www-form-urlencoded" format,
  6.    per Appendix B:
  7.  
  8.    code
  9.          REQUIRED.  The authorization code generated by the
  10.          authorization server.  The authorization code MUST expire
  11.          shortly after it is issued to mitigate the risk of leaks.  A
  12.          maximum authorization code lifetime of 10 minutes is
  13.          RECOMMENDED.  The client MUST NOT use the authorization code
  14.  
  15. Hardt                        Standards Track                   [Page 26]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.          more than once.  If an authorization code is used more than
  4.          once, the authorization server MUST deny the request and SHOULD
  5.          revoke (when possible) all tokens previously issued based on
  6.          that authorization code.  The authorization code is bound to
  7.          the client identifier and redirection URI.
  8.  
  9.    state
  10.          REQUIRED if the "state" parameter was present in the client
  11.          authorization request.  The exact value received from the
  12.          client.
  13.  
  14.    For example, the authorization server redirects the user-agent by
  15.    sending the following HTTP response:
  16.  
  17.      HTTP/1.1 302 Found
  18.      Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
  19.                &state=xyz
  20.  
  21.    The client MUST ignore unrecognized response parameters.  The
  22.    authorization code string size is left undefined by this
  23.    specification.  The client should avoid making assumptions about code
  24.    value sizes.  The authorization server SHOULD document the size of
  25.    any value it issues.
4.1.2.1. Error Response
  1.  
  2.    If the request fails due to a missing, invalid, or mismatching
  3.    redirection URI, or if the client identifier is missing or invalid,
  4.    the authorization server SHOULD inform the resource owner of the
  5.    error and MUST NOT automatically redirect the user-agent to the
  6.    invalid redirection URI.
  7.  
  8.    If the resource owner denies the access request or if the request
  9.    fails for reasons other than a missing or invalid redirection URI,
  10.    the authorization server informs the client by adding the following
  11.    parameters to the query component of the redirection URI using the
  12.    "application/x-www-form-urlencoded" format, per Appendix B:
  13.  
  14.    error
  15.          REQUIRED.  A single ASCII [USASCII] error code from the
  16.          following:
  17.  
  18.          invalid_request
  19.                The request is missing a required parameter, includes an
  20.                invalid parameter value, includes a parameter more than
  21.                once, or is otherwise malformed.
  22.  
  23. Hardt                        Standards Track                   [Page 27]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.          unauthorized_client
  4.                The client is not authorized to request an authorization
  5.                code using this method.
  6.  
  7.          access_denied
  8.                The resource owner or authorization server denied the
  9.                request.
  10.  
  11.          unsupported_response_type
  12.                The authorization server does not support obtaining an
  13.                authorization code using this method.
  14.  
  15.          invalid_scope
  16.                The requested scope is invalid, unknown, or malformed.
  17.  
  18.          server_error
  19.                The authorization server encountered an unexpected
  20.                condition that prevented it from fulfilling the request.
  21.                (This error code is needed because a 500 Internal Server
  22.                Error HTTP status code cannot be returned to the client
  23.                via an HTTP redirect.)
  24.  
  25.          temporarily_unavailable
  26.                The authorization server is currently unable to handle
  27.                the request due to a temporary overloading or maintenance
  28.                of the server.  (This error code is needed because a 503
  29.                Service Unavailable HTTP status code cannot be returned
  30.                to the client via an HTTP redirect.)
  31.  
  32.          Values for the "error" parameter MUST NOT include characters
  33.          outside the set %x20-21 / %x23-5B / %x5D-7E.
  34.  
  35.    error_description
  36.          OPTIONAL.  Human-readable ASCII [USASCII] text providing
  37.          additional information, used to assist the client developer in
  38.          understanding the error that occurred.
  39.          Values for the "error_description" parameter MUST NOT include
  40.          characters outside the set %x20-21 / %x23-5B / %x5D-7E.
  41.  
  42.    error_uri
  43.          OPTIONAL.  A URI identifying a human-readable web page with
  44.          information about the error, used to provide the client
  45.          developer with additional information about the error.
  46.          Values for the "error_uri" parameter MUST conform to the
  47.          URI-reference syntax and thus MUST NOT include characters
  48.          outside the set %x21 / %x23-5B / %x5D-7E.
  49.  
  50. Hardt                        Standards Track                   [Page 28]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    state
  4.          REQUIRED if a "state" parameter was present in the client
  5.          authorization request.  The exact value received from the
  6.          client.
  7.  
  8.    For example, the authorization server redirects the user-agent by
  9.    sending the following HTTP response:
  10.  
  11.    HTTP/1.1 302 Found
  12.    Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3. Access Token Request

  1.  
  2.    The client makes a request to the token endpoint by sending the
  3.    following parameters using the "application/x-www-form-urlencoded"
  4.    format per Appendix B with a character encoding of UTF-8 in the HTTP
  5.    request entity-body:
  6.  
  7.    grant_type
  8.          REQUIRED.  Value MUST be set to "authorization_code".
  9.  
  10.    code
  11.          REQUIRED.  The authorization code received from the
  12.          authorization server.
  13.  
  14.    redirect_uri
  15.          REQUIRED, if the "redirect_uri" parameter was included in the
  16.          authorization request as described in Section 4.1.1, and their
  17.          values MUST be identical.
  18.  
  19.    client_id
  20.          REQUIRED, if the client is not authenticating with the
  21.          authorization server as described in Section 3.2.1.
  22.  
  23.    If the client type is confidential or the client was issued client
  24.    credentials (or assigned other authentication requirements), the
  25.    client MUST authenticate with the authorization server as described
  26.    in Section 3.2.1.
  27.  
  28. Hardt                        Standards Track                   [Page 29]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    For example, the client makes the following HTTP request using TLS
  4.    (with extra line breaks for display purposes only):
  5.  
  6.      POST /token HTTP/1.1
  7.      Host: server.example.com
  8.      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  9.      Content-Type: application/x-www-form-urlencoded
  10.  
  11.      grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
  12.      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
  13.  
  14.    The authorization server MUST:
  15.  
  16.    o  require client authentication for confidential clients or for any
  17.       client that was issued client credentials (or with other
  18.       authentication requirements),
  19.  
  20.    o  authenticate the client if client authentication is included,
  21.  
  22.    o  ensure that the authorization code was issued to the authenticated
  23.       confidential client, or if the client is public, ensure that the
  24.       code was issued to "client_id" in the request,
  25.  
  26.    o  verify that the authorization code is valid, and
  27.  
  28.    o  ensure that the "redirect_uri" parameter is present if the
  29.       "redirect_uri" parameter was included in the initial authorization
  30.       request as described in Section 4.1.1, and if included ensure that
  31.       their values are identical.

4.1.4. Access Token Response

  1.  
  2.    If the access token request is valid and authorized, the
  3.    authorization server issues an access token and optional refresh
  4.    token as described in Section 5.1.  If the request client
  5.    authentication failed or is invalid, the authorization server returns
  6.    an error response as described in Section 5.2.
  7.  
  8. Hardt                        Standards Track                   [Page 30]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    An example successful response:
  4.  
  5.      HTTP/1.1 200 OK
  6.      Content-Type: application/json;charset=UTF-8
  7.      Cache-Control: no-store
  8.      Pragma: no-cache
  9.  
  10.      {
  11.        "access_token":"2YotnFZFEjr1zCsicMWpAA",
  12.        "token_type":"example",
  13.        "expires_in":3600,
  14.        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  15.        "example_parameter":"example_value"
  16.      }

4.2. Implicit Grant

  1.  
  2.    The implicit grant type is used to obtain access tokens (it does not
  3.    support the issuance of refresh tokens) and is optimized for public
  4.    clients known to operate a particular redirection URI.  These clients
  5.    are typically implemented in a browser using a scripting language
  6.    such as JavaScript.
  7.  
  8.    Since this is a redirection-based flow, the client must be capable of
  9.    interacting with the resource owner's user-agent (typically a web
  10.    browser) and capable of receiving incoming requests (via redirection)
  11.    from the authorization server.
  12.  
  13.    Unlike the authorization code grant type, in which the client makes
  14.    separate requests for authorization and for an access token, the
  15.    client receives the access token as the result of the authorization
  16.    request.
  17.  
  18.    The implicit grant type does not include client authentication, and
  19.    relies on the presence of the resource owner and the registration of
  20.    the redirection URI.  Because the access token is encoded into the
  21.    redirection URI, it may be exposed to the resource owner and other
  22.    applications residing on the same device.
  23.  
  24. Hardt                        Standards Track                   [Page 31]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.      +----------+
  4.      | Resource |
  5.      |  Owner   |
  6.      |          |
  7.      +----------+
  8.           ^
  9.           |
  10.          (B)
  11.      +----|-----+          Client Identifier     +---------------+
  12.      |         -+----(A)-- & Redirection URI --->|               |
  13.      |  User-   |                                | Authorization |
  14.      |  Agent  -|----(B)-- User authenticates -->|     Server    |
  15.      |          |                                |               |
  16.      |          |<---(C)--- Redirection URI ----<|               |
  17.      |          |          with Access Token     +---------------+
  18.      |          |            in Fragment
  19.      |          |                                +---------------+
  20.      |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
  21.      |          |          without Fragment      |     Client    |
  22.      |          |                                |    Resource   |
  23.      |     (F)  |<---(E)------- Script ---------<|               |
  24.      |          |                                +---------------+
  25.      +-|--------+
  26.        |    |
  27.       (A)  (G) Access Token
  28.        |    |
  29.        ^    v
  30.      +---------+
  31.      |         |
  32.      |  Client |
  33.      |         |
  34.      +---------+
  35.  
  36.    Note: The lines illustrating steps (A) and (B) are broken into two
  37.    parts as they pass through the user-agent.
  38.  
  39.                        Figure 4: Implicit Grant Flow
  40.  
  41. Hardt                        Standards Track                   [Page 32]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The flow illustrated in Figure 4 includes the following steps:
  4.  
  5.    (A)  The client initiates the flow by directing the resource owner's
  6.         user-agent to the authorization endpoint.  The client includes
  7.         its client identifier, requested scope, local state, and a
  8.         redirection URI to which the authorization server will send the
  9.         user-agent back once access is granted (or denied).
  10.  
  11.    (B)  The authorization server authenticates the resource owner (via
  12.         the user-agent) and establishes whether the resource owner
  13.         grants or denies the client's access request.
  14.  
  15.    (C)  Assuming the resource owner grants access, the authorization
  16.         server redirects the user-agent back to the client using the
  17.         redirection URI provided earlier.  The redirection URI includes
  18.         the access token in the URI fragment.
  19.  
  20.    (D)  The user-agent follows the redirection instructions by making a
  21.         request to the web-hosted client resource (which does not
  22.         include the fragment per [RFC2616]).  The user-agent retains the
  23.         fragment information locally.
  24.  
  25.    (E)  The web-hosted client resource returns a web page (typically an
  26.         HTML document with an embedded script) capable of accessing the
  27.         full redirection URI including the fragment retained by the
  28.         user-agent, and extracting the access token (and other
  29.         parameters) contained in the fragment.
  30.  
  31.    (F)  The user-agent executes the script provided by the web-hosted
  32.         client resource locally, which extracts the access token.
  33.  
  34.    (G)  The user-agent passes the access token to the client.
  35.  
  36.    See Sections 1.3.2 and 9 for background on using the implicit grant.
  37.    See Sections 10.3 and 10.16 for important security considerations
  38.    when using the implicit grant.

4.2.1. Authorization Request

  1.  
  2.    The client constructs the request URI by adding the following
  3.    parameters to the query component of the authorization endpoint URI
  4.    using the "application/x-www-form-urlencoded" format, per Appendix B:
  5.  
  6.    response_type
  7.          REQUIRED.  Value MUST be set to "token".
  8.  
  9.    client_id
  10.          REQUIRED.  The client identifier as described in Section 2.2.
  11.  
  12. Hardt                        Standards Track                   [Page 33]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    redirect_uri
  4.          OPTIONAL.  As described in Section 3.1.2.
  5.  
  6.    scope
  7.          OPTIONAL.  The scope of the access request as described by
  8.          Section 3.3.
  9.  
  10.    state
  11.          RECOMMENDED.  An opaque value used by the client to maintain
  12.          state between the request and callback.  The authorization
  13.          server includes this value when redirecting the user-agent back
  14.          to the client.  The parameter SHOULD be used for preventing
  15.          cross-site request forgery as described in Section 10.12.
  16.  
  17.    The client directs the resource owner to the constructed URI using an
  18.    HTTP redirection response, or by other means available to it via the
  19.    user-agent.
  20.  
  21.    For example, the client directs the user-agent to make the following
  22.    HTTP request using TLS (with extra line breaks for display purposes
  23.    only):
  24.  
  25.     GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
  26.         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  27.     Host: server.example.com
  28.  
  29.    The authorization server validates the request to ensure that all
  30.    required parameters are present and valid.  The authorization server
  31.    MUST verify that the redirection URI to which it will redirect the
  32.    access token matches a redirection URI registered by the client as
  33.    described in Section 3.1.2.
  34.  
  35.    If the request is valid, the authorization server authenticates the
  36.    resource owner and obtains an authorization decision (by asking the
  37.    resource owner or by establishing approval via other means).
  38.  
  39.    When a decision is established, the authorization server directs the
  40.    user-agent to the provided client redirection URI using an HTTP
  41.    redirection response, or by other means available to it via the
  42.    user-agent.
  43.  
  44. Hardt                        Standards Track                   [Page 34]

  1. RFC 6749                        OAuth 2.0                   October 2012

4.2.2. Access Token Response

  1.  
  2.    If the resource owner grants the access request, the authorization
  3.    server issues an access token and delivers it to the client by adding
  4.    the following parameters to the fragment component of the redirection
  5.    URI using the "application/x-www-form-urlencoded" format, per
  6.    Appendix B:
  7.  
  8.    access_token
  9.          REQUIRED.  The access token issued by the authorization server.
  10.  
  11.    token_type
  12.          REQUIRED.  The type of the token issued as described in
  13.          Section 7.1.  Value is case insensitive.
  14.  
  15.    expires_in
  16.          RECOMMENDED.  The lifetime in seconds of the access token.  For
  17.          example, the value "3600" denotes that the access token will
  18.          expire in one hour from the time the response was generated.
  19.          If omitted, the authorization server SHOULD provide the
  20.          expiration time via other means or document the default value.
  21.  
  22.    scope
  23.          OPTIONAL, if identical to the scope requested by the client;
  24.          otherwise, REQUIRED.  The scope of the access token as
  25.          described by Section 3.3.
  26.  
  27.    state
  28.          REQUIRED if the "state" parameter was present in the client
  29.          authorization request.  The exact value received from the
  30.          client.
  31.  
  32.    The authorization server MUST NOT issue a refresh token.
  33.  
  34.    For example, the authorization server redirects the user-agent by
  35.    sending the following HTTP response (with extra line breaks for
  36.    display purposes only):
  37.  
  38.      HTTP/1.1 302 Found
  39.      Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
  40.                &state=xyz&token_type=example&expires_in=3600
  41.  
  42.    Developers should note that some user-agents do not support the
  43.    inclusion of a fragment component in the HTTP "Location" response
  44.    header field.  Such clients will require using other methods for
  45.    redirecting the client than a 3xx redirection response -- for
  46.    example, returning an HTML page that includes a 'continue' button
  47.    with an action linked to the redirection URI.
  48.  
  49. Hardt                        Standards Track                   [Page 35]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The client MUST ignore unrecognized response parameters.  The access
  4.    token string size is left undefined by this specification.  The
  5.    client should avoid making assumptions about value sizes.  The
  6.    authorization server SHOULD document the size of any value it issues.
4.2.2.1. Error Response
  1.  
  2.    If the request fails due to a missing, invalid, or mismatching
  3.    redirection URI, or if the client identifier is missing or invalid,
  4.    the authorization server SHOULD inform the resource owner of the
  5.    error and MUST NOT automatically redirect the user-agent to the
  6.    invalid redirection URI.
  7.  
  8.    If the resource owner denies the access request or if the request
  9.    fails for reasons other than a missing or invalid redirection URI,
  10.    the authorization server informs the client by adding the following
  11.    parameters to the fragment component of the redirection URI using the
  12.    "application/x-www-form-urlencoded" format, per Appendix B:
  13.  
  14.    error
  15.          REQUIRED.  A single ASCII [USASCII] error code from the
  16.          following:
  17.  
  18.          invalid_request
  19.                The request is missing a required parameter, includes an
  20.                invalid parameter value, includes a parameter more than
  21.                once, or is otherwise malformed.
  22.  
  23.          unauthorized_client
  24.                The client is not authorized to request an access token
  25.                using this method.
  26.  
  27.          access_denied
  28.                The resource owner or authorization server denied the
  29.                request.
  30.  
  31.          unsupported_response_type
  32.                The authorization server does not support obtaining an
  33.                access token using this method.
  34.  
  35.          invalid_scope
  36.                The requested scope is invalid, unknown, or malformed.
  37.  
  38. Hardt                        Standards Track                   [Page 36]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.          server_error
  4.                The authorization server encountered an unexpected
  5.                condition that prevented it from fulfilling the request.
  6.                (This error code is needed because a 500 Internal Server
  7.                Error HTTP status code cannot be returned to the client
  8.                via an HTTP redirect.)
  9.  
  10.          temporarily_unavailable
  11.                The authorization server is currently unable to handle
  12.                the request due to a temporary overloading or maintenance
  13.                of the server.  (This error code is needed because a 503
  14.                Service Unavailable HTTP status code cannot be returned
  15.                to the client via an HTTP redirect.)
  16.  
  17.          Values for the "error" parameter MUST NOT include characters
  18.          outside the set %x20-21 / %x23-5B / %x5D-7E.
  19.  
  20.    error_description
  21.          OPTIONAL.  Human-readable ASCII [USASCII] text providing
  22.          additional information, used to assist the client developer in
  23.          understanding the error that occurred.
  24.          Values for the "error_description" parameter MUST NOT include
  25.          characters outside the set %x20-21 / %x23-5B / %x5D-7E.
  26.  
  27.    error_uri
  28.          OPTIONAL.  A URI identifying a human-readable web page with
  29.          information about the error, used to provide the client
  30.          developer with additional information about the error.
  31.          Values for the "error_uri" parameter MUST conform to the
  32.          URI-reference syntax and thus MUST NOT include characters
  33.          outside the set %x21 / %x23-5B / %x5D-7E.
  34.  
  35.    state
  36.          REQUIRED if a "state" parameter was present in the client
  37.          authorization request.  The exact value received from the
  38.          client.
  39.  
  40.    For example, the authorization server redirects the user-agent by
  41.    sending the following HTTP response:
  42.  
  43.    HTTP/1.1 302 Found
  44.    Location: https://client.example.com/cb#error=access_denied&state=xyz

4.3. Resource Owner Password Credentials Grant

  1.  
  2.    The resource owner password credentials grant type is suitable in
  3.    cases where the resource owner has a trust relationship with the
  4.    client, such as the device operating system or a highly privileged
  5.  
  6. Hardt                        Standards Track                   [Page 37]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    application.  The authorization server should take special care when
  4.    enabling this grant type and only allow it when other flows are not
  5.    viable.
  6.  
  7.    This grant type is suitable for clients capable of obtaining the
  8.    resource owner's credentials (username and password, typically using
  9.    an interactive form).  It is also used to migrate existing clients
  10.    using direct authentication schemes such as HTTP Basic or Digest
  11.    authentication to OAuth by converting the stored credentials to an
  12.    access token.
  13.  
  14.      +----------+
  15.      | Resource |
  16.      |  Owner   |
  17.      |          |
  18.      +----------+
  19.           v
  20.           |    Resource Owner
  21.          (A) Password Credentials
  22.           |
  23.           v
  24.      +---------+                                  +---------------+
  25.      |         |>--(B)---- Resource Owner ------->|               |
  26.      |         |         Password Credentials     | Authorization |
  27.      | Client  |                                  |     Server    |
  28.      |         |<--(C)---- Access Token ---------<|               |
  29.      |         |    (w/ Optional Refresh Token)   |               |
  30.      +---------+                                  +---------------+
  31.  
  32.             Figure 5: Resource Owner Password Credentials Flow
  33.  
  34.    The flow illustrated in Figure 5 includes the following steps:
  35.  
  36.    (A)  The resource owner provides the client with its username and
  37.         password.
  38.  
  39.    (B)  The client requests an access token from the authorization
  40.         server's token endpoint by including the credentials received
  41.         from the resource owner.  When making the request, the client
  42.         authenticates with the authorization server.
  43.  
  44.    (C)  The authorization server authenticates the client and validates
  45.         the resource owner credentials, and if valid, issues an access
  46.         token.
  47.  
  48. Hardt                        Standards Track                   [Page 38]

  1. RFC 6749                        OAuth 2.0                   October 2012

4.3.1. Authorization Request and Response

  1.  
  2.    The method through which the client obtains the resource owner
  3.    credentials is beyond the scope of this specification.  The client
  4.    MUST discard the credentials once an access token has been obtained.

4.3.2. Access Token Request

  1.  
  2.    The client makes a request to the token endpoint by adding the
  3.    following parameters using the "application/x-www-form-urlencoded"
  4.    format per Appendix B with a character encoding of UTF-8 in the HTTP
  5.    request entity-body:
  6.  
  7.    grant_type
  8.          REQUIRED.  Value MUST be set to "password".
  9.  
  10.    username
  11.          REQUIRED.  The resource owner username.
  12.  
  13.    password
  14.          REQUIRED.  The resource owner password.
  15.  
  16.    scope
  17.          OPTIONAL.  The scope of the access request as described by
  18.          Section 3.3.
  19.  
  20.    If the client type is confidential or the client was issued client
  21.    credentials (or assigned other authentication requirements), the
  22.    client MUST authenticate with the authorization server as described
  23.    in Section 3.2.1.
  24.  
  25.    For example, the client makes the following HTTP request using
  26.    transport-layer security (with extra line breaks for display purposes
  27.    only):
  28.  
  29.      POST /token HTTP/1.1
  30.      Host: server.example.com
  31.      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  32.      Content-Type: application/x-www-form-urlencoded
  33.  
  34.      grant_type=password&username=johndoe&password=A3ddj3w
  35.  
  36. Hardt                        Standards Track                   [Page 39]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The authorization server MUST:
  4.  
  5.    o  require client authentication for confidential clients or for any
  6.       client that was issued client credentials (or with other
  7.       authentication requirements),
  8.  
  9.    o  authenticate the client if client authentication is included, and
  10.  
  11.    o  validate the resource owner password credentials using its
  12.       existing password validation algorithm.
  13.  
  14.    Since this access token request utilizes the resource owner's
  15.    password, the authorization server MUST protect the endpoint against
  16.    brute force attacks (e.g., using rate-limitation or generating
  17.    alerts).

4.3.3. Access Token Response

  1.  
  2.    If the access token request is valid and authorized, the
  3.    authorization server issues an access token and optional refresh
  4.    token as described in Section 5.1.  If the request failed client
  5.    authentication or is invalid, the authorization server returns an
  6.    error response as described in Section 5.2.
  7.  
  8.    An example successful response:
  9.  
  10.      HTTP/1.1 200 OK
  11.      Content-Type: application/json;charset=UTF-8
  12.      Cache-Control: no-store
  13.      Pragma: no-cache
  14.  
  15.      {
  16.        "access_token":"2YotnFZFEjr1zCsicMWpAA",
  17.        "token_type":"example",
  18.        "expires_in":3600,
  19.        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  20.        "example_parameter":"example_value"
  21.      }

4.4. Client Credentials Grant

  1.  
  2.    The client can request an access token using only its client
  3.    credentials (or other supported means of authentication) when the
  4.    client is requesting access to the protected resources under its
  5.    control, or those of another resource owner that have been previously
  6.    arranged with the authorization server (the method of which is beyond
  7.    the scope of this specification).
  8.  
  9. Hardt                        Standards Track                   [Page 40]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The client credentials grant type MUST only be used by confidential
  4.    clients.
  5.  
  6.      +---------+                                  +---------------+
  7.      |         |                                  |               |
  8.      |         |>--(A)- Client Authentication --->| Authorization |
  9.      | Client  |                                  |     Server    |
  10.      |         |<--(B)---- Access Token ---------<|               |
  11.      |         |                                  |               |
  12.      +---------+                                  +---------------+
  13.  
  14.                      Figure 6: Client Credentials Flow
  15.  
  16.    The flow illustrated in Figure 6 includes the following steps:
  17.  
  18.    (A)  The client authenticates with the authorization server and
  19.         requests an access token from the token endpoint.
  20.  
  21.    (B)  The authorization server authenticates the client, and if valid,
  22.         issues an access token.

4.4.1. Authorization Request and Response

  1.  
  2.    Since the client authentication is used as the authorization grant,
  3.    no additional authorization request is needed.

4.4.2. Access Token Request

  1.  
  2.    The client makes a request to the token endpoint by adding the
  3.    following parameters using the "application/x-www-form-urlencoded"
  4.    format per Appendix B with a character encoding of UTF-8 in the HTTP
  5.    request entity-body:
  6.  
  7.    grant_type
  8.          REQUIRED.  Value MUST be set to "client_credentials".
  9.  
  10.    scope
  11.          OPTIONAL.  The scope of the access request as described by
  12.          Section 3.3.
  13.  
  14.    The client MUST authenticate with the authorization server as
  15.    described in Section 3.2.1.
  16.  
  17. Hardt                        Standards Track                   [Page 41]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    For example, the client makes the following HTTP request using
  4.    transport-layer security (with extra line breaks for display purposes
  5.    only):
  6.  
  7.      POST /token HTTP/1.1
  8.      Host: server.example.com
  9.      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  10.      Content-Type: application/x-www-form-urlencoded
  11.  
  12.      grant_type=client_credentials
  13.  
  14.    The authorization server MUST authenticate the client.

4.4.3. Access Token Response

  1.  
  2.    If the access token request is valid and authorized, the
  3.    authorization server issues an access token as described in
  4.    Section 5.1.  A refresh token SHOULD NOT be included.  If the request
  5.    failed client authentication or is invalid, the authorization server
  6.    returns an error response as described in Section 5.2.
  7.  
  8.    An example successful response:
  9.  
  10.      HTTP/1.1 200 OK
  11.      Content-Type: application/json;charset=UTF-8
  12.      Cache-Control: no-store
  13.      Pragma: no-cache
  14.  
  15.      {
  16.        "access_token":"2YotnFZFEjr1zCsicMWpAA",
  17.        "token_type":"example",
  18.        "expires_in":3600,
  19.        "example_parameter":"example_value"
  20.      }

4.5. Extension Grants

  1.  
  2.    The client uses an extension grant type by specifying the grant type
  3.    using an absolute URI (defined by the authorization server) as the
  4.    value of the "grant_type" parameter of the token endpoint, and by
  5.    adding any additional parameters necessary.
  6.  
  7. Hardt                        Standards Track                   [Page 42]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    For example, to request an access token using a Security Assertion
  4.    Markup Language (SAML) 2.0 assertion grant type as defined by
  5.    [OAuth-SAML2], the client could make the following HTTP request using
  6.    TLS (with extra line breaks for display purposes only):
  7.  
  8.      POST /token HTTP/1.1
  9.      Host: server.example.com
  10.      Content-Type: application/x-www-form-urlencoded
  11.  
  12.      grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
  13.      bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
  14.      [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
  15.  
  16.    If the access token request is valid and authorized, the
  17.    authorization server issues an access token and optional refresh
  18.    token as described in Section 5.1.  If the request failed client
  19.    authentication or is invalid, the authorization server returns an
  20.    error response as described in Section 5.2.

5. Issuing an Access Token

  1.  
  2.    If the access token request is valid and authorized, the
  3.    authorization server issues an access token and optional refresh
  4.    token as described in Section 5.1.  If the request failed client
  5.    authentication or is invalid, the authorization server returns an
  6.    error response as described in Section 5.2.

5.1. Successful Response

  1.  
  2.    The authorization server issues an access token and optional refresh
  3.    token, and constructs the response by adding the following parameters
  4.    to the entity-body of the HTTP response with a 200 (OK) status code:
  5.  
  6.    access_token
  7.          REQUIRED.  The access token issued by the authorization server.
  8.  
  9.    token_type
  10.          REQUIRED.  The type of the token issued as described in
  11.          Section 7.1.  Value is case insensitive.
  12.  
  13.    expires_in
  14.          RECOMMENDED.  The lifetime in seconds of the access token.  For
  15.          example, the value "3600" denotes that the access token will
  16.          expire in one hour from the time the response was generated.
  17.          If omitted, the authorization server SHOULD provide the
  18.          expiration time via other means or document the default value.
  19.  
  20. Hardt                        Standards Track                   [Page 43]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    refresh_token
  4.          OPTIONAL.  The refresh token, which can be used to obtain new
  5.          access tokens using the same authorization grant as described
  6.          in Section 6.
  7.  
  8.    scope
  9.          OPTIONAL, if identical to the scope requested by the client;
  10.          otherwise, REQUIRED.  The scope of the access token as
  11.          described by Section 3.3.
  12.  
  13.    The parameters are included in the entity-body of the HTTP response
  14.    using the "application/json" media type as defined by [RFC4627].  The
  15.    parameters are serialized into a JavaScript Object Notation (JSON)
  16.    structure by adding each parameter at the highest structure level.
  17.    Parameter names and string values are included as JSON strings.
  18.    Numerical values are included as JSON numbers.  The order of
  19.    parameters does not matter and can vary.
  20.  
  21.    The authorization server MUST include the HTTP "Cache-Control"
  22.    response header field [RFC2616] with a value of "no-store" in any
  23.    response containing tokens, credentials, or other sensitive
  24.    information, as well as the "Pragma" response header field [RFC2616]
  25.    with a value of "no-cache".
  26.  
  27.    For example:
  28.  
  29.      HTTP/1.1 200 OK
  30.      Content-Type: application/json;charset=UTF-8
  31.      Cache-Control: no-store
  32.      Pragma: no-cache
  33.  
  34.      {
  35.        "access_token":"2YotnFZFEjr1zCsicMWpAA",
  36.        "token_type":"example",
  37.        "expires_in":3600,
  38.        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  39.        "example_parameter":"example_value"
  40.      }
  41.  
  42.    The client MUST ignore unrecognized value names in the response.  The
  43.    sizes of tokens and other values received from the authorization
  44.    server are left undefined.  The client should avoid making
  45.    assumptions about value sizes.  The authorization server SHOULD
  46.    document the size of any value it issues.
  47.  
  48. Hardt                        Standards Track                   [Page 44]

  1. RFC 6749                        OAuth 2.0                   October 2012

5.2. Error Response

  1.  
  2.    The authorization server responds with an HTTP 400 (Bad Request)
  3.    status code (unless specified otherwise) and includes the following
  4.    parameters with the response:
  5.  
  6.    error
  7.          REQUIRED.  A single ASCII [USASCII] error code from the
  8.          following:
  9.  
  10.          invalid_request
  11.                The request is missing a required parameter, includes an
  12.                unsupported parameter value (other than grant type),
  13.                repeats a parameter, includes multiple credentials,
  14.                utilizes more than one mechanism for authenticating the
  15.                client, or is otherwise malformed.
  16.  
  17.          invalid_client
  18.                Client authentication failed (e.g., unknown client, no
  19.                client authentication included, or unsupported
  20.                authentication method).  The authorization server MAY
  21.                return an HTTP 401 (Unauthorized) status code to indicate
  22.                which HTTP authentication schemes are supported.  If the
  23.                client attempted to authenticate via the "Authorization"
  24.                request header field, the authorization server MUST
  25.                respond with an HTTP 401 (Unauthorized) status code and
  26.                include the "WWW-Authenticate" response header field
  27.                matching the authentication scheme used by the client.
  28.  
  29.          invalid_grant
  30.                The provided authorization grant (e.g., authorization
  31.                code, resource owner credentials) or refresh token is
  32.                invalid, expired, revoked, does not match the redirection
  33.                URI used in the authorization request, or was issued to
  34.                another client.
  35.  
  36.          unauthorized_client
  37.                The authenticated client is not authorized to use this
  38.                authorization grant type.
  39.  
  40.          unsupported_grant_type
  41.                The authorization grant type is not supported by the
  42.                authorization server.
  43.  
  44. Hardt                        Standards Track                   [Page 45]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.          invalid_scope
  4.                The requested scope is invalid, unknown, malformed, or
  5.                exceeds the scope granted by the resource owner.
  6.  
  7.          Values for the "error" parameter MUST NOT include characters
  8.          outside the set %x20-21 / %x23-5B / %x5D-7E.
  9.  
  10.    error_description
  11.          OPTIONAL.  Human-readable ASCII [USASCII] text providing
  12.          additional information, used to assist the client developer in
  13.          understanding the error that occurred.
  14.          Values for the "error_description" parameter MUST NOT include
  15.          characters outside the set %x20-21 / %x23-5B / %x5D-7E.
  16.  
  17.    error_uri
  18.          OPTIONAL.  A URI identifying a human-readable web page with
  19.          information about the error, used to provide the client
  20.          developer with additional information about the error.
  21.          Values for the "error_uri" parameter MUST conform to the
  22.          URI-reference syntax and thus MUST NOT include characters
  23.          outside the set %x21 / %x23-5B / %x5D-7E.
  24.  
  25.    The parameters are included in the entity-body of the HTTP response
  26.    using the "application/json" media type as defined by [RFC4627].  The
  27.    parameters are serialized into a JSON structure by adding each
  28.    parameter at the highest structure level.  Parameter names and string
  29.    values are included as JSON strings.  Numerical values are included
  30.    as JSON numbers.  The order of parameters does not matter and can
  31.    vary.
  32.  
  33.    For example:
  34.  
  35.      HTTP/1.1 400 Bad Request
  36.      Content-Type: application/json;charset=UTF-8
  37.      Cache-Control: no-store
  38.      Pragma: no-cache
  39.  
  40.      {
  41.        "error":"invalid_request"
  42.      }
  43.  
  44. Hardt                        Standards Track                   [Page 46]

  1. RFC 6749                        OAuth 2.0                   October 2012

6. Refreshing an Access Token

  1.  
  2.    If the authorization server issued a refresh token to the client, the
  3.    client makes a refresh request to the token endpoint by adding the
  4.    following parameters using the "application/x-www-form-urlencoded"
  5.    format per Appendix B with a character encoding of UTF-8 in the HTTP
  6.    request entity-body:
  7.  
  8.    grant_type
  9.          REQUIRED.  Value MUST be set to "refresh_token".
  10.  
  11.    refresh_token
  12.          REQUIRED.  The refresh token issued to the client.
  13.  
  14.    scope
  15.          OPTIONAL.  The scope of the access request as described by
  16.          Section 3.3.  The requested scope MUST NOT include any scope
  17.          not originally granted by the resource owner, and if omitted is
  18.          treated as equal to the scope originally granted by the
  19.          resource owner.
  20.  
  21.    Because refresh tokens are typically long-lasting credentials used to
  22.    request additional access tokens, the refresh token is bound to the
  23.    client to which it was issued.  If the client type is confidential or
  24.    the client was issued client credentials (or assigned other
  25.    authentication requirements), the client MUST authenticate with the
  26.    authorization server as described in Section 3.2.1.
  27.  
  28.    For example, the client makes the following HTTP request using
  29.    transport-layer security (with extra line breaks for display purposes
  30.    only):
  31.  
  32.      POST /token HTTP/1.1
  33.      Host: server.example.com
  34.      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  35.      Content-Type: application/x-www-form-urlencoded
  36.  
  37.      grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  38.  
  39. Hardt                        Standards Track                   [Page 47]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The authorization server MUST:
  4.  
  5.    o  require client authentication for confidential clients or for any
  6.       client that was issued client credentials (or with other
  7.       authentication requirements),
  8.  
  9.    o  authenticate the client if client authentication is included and
  10.       ensure that the refresh token was issued to the authenticated
  11.       client, and
  12.  
  13.    o  validate the refresh token.
  14.  
  15.    If valid and authorized, the authorization server issues an access
  16.    token as described in Section 5.1.  If the request failed
  17.    verification or is invalid, the authorization server returns an error
  18.    response as described in Section 5.2.
  19.  
  20.    The authorization server MAY issue a new refresh token, in which case
  21.    the client MUST discard the old refresh token and replace it with the
  22.    new refresh token.  The authorization server MAY revoke the old
  23.    refresh token after issuing a new refresh token to the client.  If a
  24.    new refresh token is issued, the refresh token scope MUST be
  25.    identical to that of the refresh token included by the client in the
  26.    request.

7. Accessing Protected Resources

  1.  
  2.    The client accesses protected resources by presenting the access
  3.    token to the resource server.  The resource server MUST validate the
  4.    access token and ensure that it has not expired and that its scope
  5.    covers the requested resource.  The methods used by the resource
  6.    server to validate the access token (as well as any error responses)
  7.    are beyond the scope of this specification but generally involve an
  8.    interaction or coordination between the resource server and the
  9.    authorization server.
  10.  
  11.    The method in which the client utilizes the access token to
  12.    authenticate with the resource server depends on the type of access
  13.    token issued by the authorization server.  Typically, it involves
  14.    using the HTTP "Authorization" request header field [RFC2617] with an
  15.    authentication scheme defined by the specification of the access
  16.    token type used, such as [RFC6750].
  17.  
  18. Hardt                        Standards Track                   [Page 48]

  1. RFC 6749                        OAuth 2.0                   October 2012

7.1. Access Token Types

  1.  
  2.    The access token type provides the client with the information
  3.    required to successfully utilize the access token to make a protected
  4.    resource request (along with type-specific attributes).  The client
  5.    MUST NOT use an access token if it does not understand the token
  6.    type.
  7.  
  8.    For example, the "bearer" token type defined in [RFC6750] is utilized
  9.    by simply including the access token string in the request:
  10.  
  11.      GET /resource/1 HTTP/1.1
  12.      Host: example.com
  13.      Authorization: Bearer mF_9.B5f-4.1JqM
  14.  
  15.    while the "mac" token type defined in [OAuth-HTTP-MAC] is utilized by
  16.    issuing a Message Authentication Code (MAC) key together with the
  17.    access token that is used to sign certain components of the HTTP
  18.    requests:
  19.  
  20.      GET /resource/1 HTTP/1.1
  21.      Host: example.com
  22.      Authorization: MAC id="h480djs93hd8",
  23.                         nonce="274312:dj83hs9s",
  24.                         mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
  25.  
  26.    The above examples are provided for illustration purposes only.
  27.    Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC]
  28.    specifications before use.
  29.  
  30.    Each access token type definition specifies the additional attributes
  31.    (if any) sent to the client together with the "access_token" response
  32.    parameter.  It also defines the HTTP authentication method used to
  33.    include the access token when making a protected resource request.

7.2. Error Response

  1.  
  2.    If a resource access request fails, the resource server SHOULD inform
  3.    the client of the error.  While the specifics of such error responses
  4.    are beyond the scope of this specification, this document establishes
  5.    a common registry in Section 11.4 for error values to be shared among
  6.    OAuth token authentication schemes.
  7.  
  8.    New authentication schemes designed primarily for OAuth token
  9.    authentication SHOULD define a mechanism for providing an error
  10.    status code to the client, in which the error values allowed are
  11.    registered in the error registry established by this specification.
  12.  
  13. Hardt                        Standards Track                   [Page 49]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Such schemes MAY limit the set of valid error codes to a subset of
  4.    the registered values.  If the error code is returned using a named
  5.    parameter, the parameter name SHOULD be "error".
  6.  
  7.    Other schemes capable of being used for OAuth token authentication,
  8.    but not primarily designed for that purpose, MAY bind their error
  9.    values to the registry in the same manner.
  10.  
  11.    New authentication schemes MAY choose to also specify the use of the
  12.    "error_description" and "error_uri" parameters to return error
  13.    information in a manner parallel to their usage in this
  14.    specification.

8. Extensibility

8.1. Defining Access Token Types

  1.  
  2.    Access token types can be defined in one of two ways: registered in
  3.    the Access Token Types registry (following the procedures in
  4.    Section 11.1), or by using a unique absolute URI as its name.
  5.  
  6.    Types utilizing a URI name SHOULD be limited to vendor-specific
  7.    implementations that are not commonly applicable, and are specific to
  8.    the implementation details of the resource server where they are
  9.    used.
  10.  
  11.    All other types MUST be registered.  Type names MUST conform to the
  12.    type-name ABNF.  If the type definition includes a new HTTP
  13.    authentication scheme, the type name SHOULD be identical to the HTTP
  14.    authentication scheme name (as defined by [RFC2617]).  The token type
  15.    "example" is reserved for use in examples.
  16.  
  17.      type-name  = 1*name-char
  18.      name-char  = "-" / "." / "_" / DIGIT / ALPHA

8.2. Defining New Endpoint Parameters

  1.  
  2.    New request or response parameters for use with the authorization
  3.    endpoint or the token endpoint are defined and registered in the
  4.    OAuth Parameters registry following the procedure in Section 11.2.
  5.  
  6.    Parameter names MUST conform to the param-name ABNF, and parameter
  7.    values syntax MUST be well-defined (e.g., using ABNF, or a reference
  8.    to the syntax of an existing parameter).
  9.  
  10.      param-name  = 1*name-char
  11.      name-char   = "-" / "." / "_" / DIGIT / ALPHA
  12.  
  13. Hardt                        Standards Track                   [Page 50]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Unregistered vendor-specific parameter extensions that are not
  4.    commonly applicable and that are specific to the implementation
  5.    details of the authorization server where they are used SHOULD
  6.    utilize a vendor-specific prefix that is not likely to conflict with
  7.    other registered values (e.g., begin with 'companyname_').

8.3. Defining New Authorization Grant Types

  1.  
  2.    New authorization grant types can be defined by assigning them a
  3.    unique absolute URI for use with the "grant_type" parameter.  If the
  4.    extension grant type requires additional token endpoint parameters,
  5.    they MUST be registered in the OAuth Parameters registry as described
  6.    by Section 11.2.

8.4. Defining New Authorization Endpoint Response Types

  1.  
  2.    New response types for use with the authorization endpoint are
  3.    defined and registered in the Authorization Endpoint Response Types
  4.    registry following the procedure in Section 11.3.  Response type
  5.    names MUST conform to the response-type ABNF.
  6.  
  7.      response-type  = response-name *( SP response-name )
  8.      response-name  = 1*response-char
  9.      response-char  = "_" / DIGIT / ALPHA
  10.  
  11.    If a response type contains one or more space characters (%x20), it
  12.    is compared as a space-delimited list of values in which the order of
  13.    values does not matter.  Only one order of values can be registered,
  14.    which covers all other arrangements of the same set of values.
  15.  
  16.    For example, the response type "token code" is left undefined by this
  17.    specification.  However, an extension can define and register the
  18.    "token code" response type.  Once registered, the same combination
  19.    cannot be registered as "code token", but both values can be used to
  20.    denote the same response type.

8.5. Defining Additional Error Codes

  1.  
  2.    In cases where protocol extensions (i.e., access token types,
  3.    extension parameters, or extension grant types) require additional
  4.    error codes to be used with the authorization code grant error
  5.    response (Section 4.1.2.1), the implicit grant error response
  6.    (Section 4.2.2.1), the token error response (Section 5.2), or the
  7.    resource access error response (Section 7.2), such error codes MAY be
  8.    defined.
  9.  
  10. Hardt                        Standards Track                   [Page 51]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Extension error codes MUST be registered (following the procedures in
  4.    Section 11.4) if the extension they are used in conjunction with is a
  5.    registered access token type, a registered endpoint parameter, or an
  6.    extension grant type.  Error codes used with unregistered extensions
  7.    MAY be registered.
  8.  
  9.    Error codes MUST conform to the error ABNF and SHOULD be prefixed by
  10.    an identifying name when possible.  For example, an error identifying
  11.    an invalid value set to the extension parameter "example" SHOULD be
  12.    named "example_invalid".
  13.  
  14.      error      = 1*error-char
  15.      error-char = %x20-21 / %x23-5B / %x5D-7E

9. Native Applications

  1.  
  2.    Native applications are clients installed and executed on the device
  3.    used by the resource owner (i.e., desktop application, native mobile
  4.    application).  Native applications require special consideration
  5.    related to security, platform capabilities, and overall end-user
  6.    experience.
  7.  
  8.    The authorization endpoint requires interaction between the client
  9.    and the resource owner's user-agent.  Native applications can invoke
  10.    an external user-agent or embed a user-agent within the application.
  11.    For example:
  12.  
  13.    o  External user-agent - the native application can capture the
  14.       response from the authorization server using a redirection URI
  15.       with a scheme registered with the operating system to invoke the
  16.       client as the handler, manual copy-and-paste of the credentials,
  17.       running a local web server, installing a user-agent extension, or
  18.       by providing a redirection URI identifying a server-hosted
  19.       resource under the client's control, which in turn makes the
  20.       response available to the native application.
  21.  
  22.    o  Embedded user-agent - the native application obtains the response
  23.       by directly communicating with the embedded user-agent by
  24.       monitoring state changes emitted during the resource load, or
  25.       accessing the user-agent's cookies storage.
  26.  
  27.    When choosing between an external or embedded user-agent, developers
  28.    should consider the following:
  29.  
  30.    o  An external user-agent may improve completion rate, as the
  31.       resource owner may already have an active session with the
  32.       authorization server, removing the need to re-authenticate.  It
  33.       provides a familiar end-user experience and functionality.  The
  34.  
  35. Hardt                        Standards Track                   [Page 52]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.       resource owner may also rely on user-agent features or extensions
  4.       to assist with authentication (e.g., password manager, 2-factor
  5.       device reader).
  6.  
  7.    o  An embedded user-agent may offer improved usability, as it removes
  8.       the need to switch context and open new windows.
  9.  
  10.    o  An embedded user-agent poses a security challenge because resource
  11.       owners are authenticating in an unidentified window without access
  12.       to the visual protections found in most external user-agents.  An
  13.       embedded user-agent educates end-users to trust unidentified
  14.       requests for authentication (making phishing attacks easier to
  15.       execute).
  16.  
  17.    When choosing between the implicit grant type and the authorization
  18.    code grant type, the following should be considered:
  19.  
  20.    o  Native applications that use the authorization code grant type
  21.       SHOULD do so without using client credentials, due to the native
  22.       application's inability to keep client credentials confidential.
  23.  
  24.    o  When using the implicit grant type flow, a refresh token is not
  25.       returned, which requires repeating the authorization process once
  26.       the access token expires.

10. Security Considerations

  1.  
  2.    As a flexible and extensible framework, OAuth's security
  3.    considerations depend on many factors.  The following sections
  4.    provide implementers with security guidelines focused on the three
  5.    client profiles described in Section 2.1: web application,
  6.    user-agent-based application, and native application.
  7.  
  8.    A comprehensive OAuth security model and analysis, as well as
  9.    background for the protocol design, is provided by
  10.    [OAuth-THREATMODEL].

10.1. Client Authentication

  1.  
  2.    The authorization server establishes client credentials with web
  3.    application clients for the purpose of client authentication.  The
  4.    authorization server is encouraged to consider stronger client
  5.    authentication means than a client password.  Web application clients
  6.    MUST ensure confidentiality of client passwords and other client
  7.    credentials.
  8.  
  9. Hardt                        Standards Track                   [Page 53]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    The authorization server MUST NOT issue client passwords or other
  4.    client credentials to native application or user-agent-based
  5.    application clients for the purpose of client authentication.  The
  6.    authorization server MAY issue a client password or other credentials
  7.    for a specific installation of a native application client on a
  8.    specific device.
  9.  
  10.    When client authentication is not possible, the authorization server
  11.    SHOULD employ other means to validate the client's identity -- for
  12.    example, by requiring the registration of the client redirection URI
  13.    or enlisting the resource owner to confirm identity.  A valid
  14.    redirection URI is not sufficient to verify the client's identity
  15.    when asking for resource owner authorization but can be used to
  16.    prevent delivering credentials to a counterfeit client after
  17.    obtaining resource owner authorization.
  18.  
  19.    The authorization server must consider the security implications of
  20.    interacting with unauthenticated clients and take measures to limit
  21.    the potential exposure of other credentials (e.g., refresh tokens)
  22.    issued to such clients.

10.2. Client Impersonation

  1.  
  2.    A malicious client can impersonate another client and obtain access
  3.    to protected resources if the impersonated client fails to, or is
  4.    unable to, keep its client credentials confidential.
  5.  
  6.    The authorization server MUST authenticate the client whenever
  7.    possible.  If the authorization server cannot authenticate the client
  8.    due to the client's nature, the authorization server MUST require the
  9.    registration of any redirection URI used for receiving authorization
  10.    responses and SHOULD utilize other means to protect resource owners
  11.    from such potentially malicious clients.  For example, the
  12.    authorization server can engage the resource owner to assist in
  13.    identifying the client and its origin.
  14.  
  15.    The authorization server SHOULD enforce explicit resource owner
  16.    authentication and provide the resource owner with information about
  17.    the client and the requested authorization scope and lifetime.  It is
  18.    up to the resource owner to review the information in the context of
  19.    the current client and to authorize or deny the request.
  20.  
  21.    The authorization server SHOULD NOT process repeated authorization
  22.    requests automatically (without active resource owner interaction)
  23.    without authenticating the client or relying on other measures to
  24.    ensure that the repeated request comes from the original client and
  25.    not an impersonator.
  26.  
  27. Hardt                        Standards Track                   [Page 54]

  1. RFC 6749                        OAuth 2.0                   October 2012

10.3. Access Tokens

  1.  
  2.    Access token credentials (as well as any confidential access token
  3.    attributes) MUST be kept confidential in transit and storage, and
  4.    only shared among the authorization server, the resource servers the
  5.    access token is valid for, and the client to whom the access token is
  6.    issued.  Access token credentials MUST only be transmitted using TLS
  7.    as described in Section 1.6 with server authentication as defined by
  8.    [RFC2818].
  9.  
  10.    When using the implicit grant type, the access token is transmitted
  11.    in the URI fragment, which can expose it to unauthorized parties.
  12.  
  13.    The authorization server MUST ensure that access tokens cannot be
  14.    generated, modified, or guessed to produce valid access tokens by
  15.    unauthorized parties.
  16.  
  17.    The client SHOULD request access tokens with the minimal scope
  18.    necessary.  The authorization server SHOULD take the client identity
  19.    into account when choosing how to honor the requested scope and MAY
  20.    issue an access token with less rights than requested.
  21.  
  22.    This specification does not provide any methods for the resource
  23.    server to ensure that an access token presented to it by a given
  24.    client was issued to that client by the authorization server.

10.4. Refresh Tokens

  1.  
  2.    Authorization servers MAY issue refresh tokens to web application
  3.    clients and native application clients.
  4.  
  5.    Refresh tokens MUST be kept confidential in transit and storage, and
  6.    shared only among the authorization server and the client to whom the
  7.    refresh tokens were issued.  The authorization server MUST maintain
  8.    the binding between a refresh token and the client to whom it was
  9.    issued.  Refresh tokens MUST only be transmitted using TLS as
  10.    described in Section 1.6 with server authentication as defined by
  11.    [RFC2818].
  12.  
  13.    The authorization server MUST verify the binding between the refresh
  14.    token and client identity whenever the client identity can be
  15.    authenticated.  When client authentication is not possible, the
  16.    authorization server SHOULD deploy other means to detect refresh
  17.    token abuse.
  18.  
  19.    For example, the authorization server could employ refresh token
  20.    rotation in which a new refresh token is issued with every access
  21.    token refresh response.  The previous refresh token is invalidated
  22.  
  23. Hardt                        Standards Track                   [Page 55]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    but retained by the authorization server.  If a refresh token is
  4.    compromised and subsequently used by both the attacker and the
  5.    legitimate client, one of them will present an invalidated refresh
  6.    token, which will inform the authorization server of the breach.
  7.  
  8.    The authorization server MUST ensure that refresh tokens cannot be
  9.    generated, modified, or guessed to produce valid refresh tokens by
  10.    unauthorized parties.

10.5. Authorization Codes

  1.  
  2.    The transmission of authorization codes SHOULD be made over a secure
  3.    channel, and the client SHOULD require the use of TLS with its
  4.    redirection URI if the URI identifies a network resource.  Since
  5.    authorization codes are transmitted via user-agent redirections, they
  6.    could potentially be disclosed through user-agent history and HTTP
  7.    referrer headers.
  8.  
  9.    Authorization codes operate as plaintext bearer credentials, used to
  10.    verify that the resource owner who granted authorization at the
  11.    authorization server is the same resource owner returning to the
  12.    client to complete the process.  Therefore, if the client relies on
  13.    the authorization code for its own resource owner authentication, the
  14.    client redirection endpoint MUST require the use of TLS.
  15.  
  16.    Authorization codes MUST be short lived and single-use.  If the
  17.    authorization server observes multiple attempts to exchange an
  18.    authorization code for an access token, the authorization server
  19.    SHOULD attempt to revoke all access tokens already granted based on
  20.    the compromised authorization code.
  21.  
  22.    If the client can be authenticated, the authorization servers MUST
  23.    authenticate the client and ensure that the authorization code was
  24.    issued to the same client.

10.6. Authorization Code Redirection URI Manipulation

  1.  
  2.    When requesting authorization using the authorization code grant
  3.    type, the client can specify a redirection URI via the "redirect_uri"
  4.    parameter.  If an attacker can manipulate the value of the
  5.    redirection URI, it can cause the authorization server to redirect
  6.    the resource owner user-agent to a URI under the control of the
  7.    attacker with the authorization code.
  8.  
  9.    An attacker can create an account at a legitimate client and initiate
  10.    the authorization flow.  When the attacker's user-agent is sent to
  11.    the authorization server to grant access, the attacker grabs the
  12.    authorization URI provided by the legitimate client and replaces the
  13.  
  14. Hardt                        Standards Track                   [Page 56]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    client's redirection URI with a URI under the control of the
  4.    attacker.  The attacker then tricks the victim into following the
  5.    manipulated link to authorize access to the legitimate client.
  6.  
  7.    Once at the authorization server, the victim is prompted with a
  8.    normal, valid request on behalf of a legitimate and trusted client,
  9.    and authorizes the request.  The victim is then redirected to an
  10.    endpoint under the control of the attacker with the authorization
  11.    code.  The attacker completes the authorization flow by sending the
  12.    authorization code to the client using the original redirection URI
  13.    provided by the client.  The client exchanges the authorization code
  14.    with an access token and links it to the attacker's client account,
  15.    which can now gain access to the protected resources authorized by
  16.    the victim (via the client).
  17.  
  18.    In order to prevent such an attack, the authorization server MUST
  19.    ensure that the redirection URI used to obtain the authorization code
  20.    is identical to the redirection URI provided when exchanging the
  21.    authorization code for an access token.  The authorization server
  22.    MUST require public clients and SHOULD require confidential clients
  23.    to register their redirection URIs.  If a redirection URI is provided
  24.    in the request, the authorization server MUST validate it against the
  25.    registered value.

10.7. Resource Owner Password Credentials

  1.  
  2.    The resource owner password credentials grant type is often used for
  3.    legacy or migration reasons.  It reduces the overall risk of storing
  4.    usernames and passwords by the client but does not eliminate the need
  5.    to expose highly privileged credentials to the client.
  6.  
  7.    This grant type carries a higher risk than other grant types because
  8.    it maintains the password anti-pattern this protocol seeks to avoid.
  9.    The client could abuse the password, or the password could
  10.    unintentionally be disclosed to an attacker (e.g., via log files or
  11.    other records kept by the client).
  12.  
  13.    Additionally, because the resource owner does not have control over
  14.    the authorization process (the resource owner's involvement ends when
  15.    it hands over its credentials to the client), the client can obtain
  16.    access tokens with a broader scope than desired by the resource
  17.    owner.  The authorization server should consider the scope and
  18.    lifetime of access tokens issued via this grant type.
  19.  
  20.    The authorization server and client SHOULD minimize use of this grant
  21.    type and utilize other grant types whenever possible.
  22.  
  23. Hardt                        Standards Track                   [Page 57]

  1. RFC 6749                        OAuth 2.0                   October 2012

10.8. Request Confidentiality

  1.  
  2.    Access tokens, refresh tokens, resource owner passwords, and client
  3.    credentials MUST NOT be transmitted in the clear.  Authorization
  4.    codes SHOULD NOT be transmitted in the clear.
  5.  
  6.    The "state" and "scope" parameters SHOULD NOT include sensitive
  7.    client or resource owner information in plain text, as they can be
  8.    transmitted over insecure channels or stored insecurely.

10.9. Ensuring Endpoint Authenticity

  1.  
  2.    In order to prevent man-in-the-middle attacks, the authorization
  3.    server MUST require the use of TLS with server authentication as
  4.    defined by [RFC2818] for any request sent to the authorization and
  5.    token endpoints.  The client MUST validate the authorization server's
  6.    TLS certificate as defined by [RFC6125] and in accordance with its
  7.    requirements for server identity authentication.

10.10. Credentials-Guessing Attacks

  1.  
  2.    The authorization server MUST prevent attackers from guessing access
  3.    tokens, authorization codes, refresh tokens, resource owner
  4.    passwords, and client credentials.
  5.  
  6.    The probability of an attacker guessing generated tokens (and other
  7.    credentials not intended for handling by end-users) MUST be less than
  8.    or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
  9.  
  10.    The authorization server MUST utilize other means to protect
  11.    credentials intended for end-user usage.

10.11. Phishing Attacks

  1.  
  2.    Wide deployment of this and similar protocols may cause end-users to
  3.    become inured to the practice of being redirected to websites where
  4.    they are asked to enter their passwords.  If end-users are not
  5.    careful to verify the authenticity of these websites before entering
  6.    their credentials, it will be possible for attackers to exploit this
  7.    practice to steal resource owners' passwords.
  8.  
  9.    Service providers should attempt to educate end-users about the risks
  10.    phishing attacks pose and should provide mechanisms that make it easy
  11.    for end-users to confirm the authenticity of their sites.  Client
  12.    developers should consider the security implications of how they
  13.    interact with the user-agent (e.g., external, embedded), and the
  14.    ability of the end-user to verify the authenticity of the
  15.    authorization server.
  16.  
  17. Hardt                        Standards Track                   [Page 58]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    To reduce the risk of phishing attacks, the authorization servers
  4.    MUST require the use of TLS on every endpoint used for end-user
  5.    interaction.

10.12. Cross-Site Request Forgery

  1.  
  2.    Cross-site request forgery (CSRF) is an exploit in which an attacker
  3.    causes the user-agent of a victim end-user to follow a malicious URI
  4.    (e.g., provided to the user-agent as a misleading link, image, or
  5.    redirection) to a trusting server (usually established via the
  6.    presence of a valid session cookie).
  7.  
  8.    A CSRF attack against the client's redirection URI allows an attacker
  9.    to inject its own authorization code or access token, which can
  10.    result in the client using an access token associated with the
  11.    attacker's protected resources rather than the victim's (e.g., save
  12.    the victim's bank account information to a protected resource
  13.    controlled by the attacker).
  14.  
  15.    The client MUST implement CSRF protection for its redirection URI.
  16.    This is typically accomplished by requiring any request sent to the
  17.    redirection URI endpoint to include a value that binds the request to
  18.    the user-agent's authenticated state (e.g., a hash of the session
  19.    cookie used to authenticate the user-agent).  The client SHOULD
  20.    utilize the "state" request parameter to deliver this value to the
  21.    authorization server when making an authorization request.
  22.  
  23.    Once authorization has been obtained from the end-user, the
  24.    authorization server redirects the end-user's user-agent back to the
  25.    client with the required binding value contained in the "state"
  26.    parameter.  The binding value enables the client to verify the
  27.    validity of the request by matching the binding value to the
  28.    user-agent's authenticated state.  The binding value used for CSRF
  29.    protection MUST contain a non-guessable value (as described in
  30.    Section 10.10), and the user-agent's authenticated state (e.g.,
  31.    session cookie, HTML5 local storage) MUST be kept in a location
  32.    accessible only to the client and the user-agent (i.e., protected by
  33.    same-origin policy).
  34.  
  35.    A CSRF attack against the authorization server's authorization
  36.    endpoint can result in an attacker obtaining end-user authorization
  37.    for a malicious client without involving or alerting the end-user.
  38.  
  39.    The authorization server MUST implement CSRF protection for its
  40.    authorization endpoint and ensure that a malicious client cannot
  41.    obtain authorization without the awareness and explicit consent of
  42.    the resource owner.
  43.  
  44. Hardt                        Standards Track                   [Page 59]

  1. RFC 6749                        OAuth 2.0                   October 2012

10.13. Clickjacking

  1.  
  2.    In a clickjacking attack, an attacker registers a legitimate client
  3.    and then constructs a malicious site in which it loads the
  4.    authorization server's authorization endpoint web page in a
  5.    transparent iframe overlaid on top of a set of dummy buttons, which
  6.    are carefully constructed to be placed directly under important
  7.    buttons on the authorization page.  When an end-user clicks a
  8.    misleading visible button, the end-user is actually clicking an
  9.    invisible button on the authorization page (such as an "Authorize"
  10.    button).  This allows an attacker to trick a resource owner into
  11.    granting its client access without the end-user's knowledge.
  12.  
  13.    To prevent this form of attack, native applications SHOULD use
  14.    external browsers instead of embedding browsers within the
  15.    application when requesting end-user authorization.  For most newer
  16.    browsers, avoidance of iframes can be enforced by the authorization
  17.    server using the (non-standard) "x-frame-options" header.  This
  18.    header can have two values, "deny" and "sameorigin", which will block
  19.    any framing, or framing by sites with a different origin,
  20.    respectively.  For older browsers, JavaScript frame-busting
  21.    techniques can be used but may not be effective in all browsers.

10.14. Code Injection and Input Validation

  1.  
  2.    A code injection attack occurs when an input or otherwise external
  3.    variable is used by an application unsanitized and causes
  4.    modification to the application logic.  This may allow an attacker to
  5.    gain access to the application device or its data, cause denial of
  6.    service, or introduce a wide range of malicious side-effects.
  7.  
  8.    The authorization server and client MUST sanitize (and validate when
  9.    possible) any value received -- in particular, the value of the
  10.    "state" and "redirect_uri" parameters.

10.15. Open Redirectors

  1.  
  2.    The authorization server, authorization endpoint, and client
  3.    redirection endpoint can be improperly configured and operate as open
  4.    redirectors.  An open redirector is an endpoint using a parameter to
  5.    automatically redirect a user-agent to the location specified by the
  6.    parameter value without any validation.
  7.  
  8.    Open redirectors can be used in phishing attacks, or by an attacker
  9.    to get end-users to visit malicious sites by using the URI authority
  10.    component of a familiar and trusted destination.  In addition, if the
  11.    authorization server allows the client to register only part of the
  12.    redirection URI, an attacker can use an open redirector operated by
  13.  
  14. Hardt                        Standards Track                   [Page 60]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    the client to construct a redirection URI that will pass the
  4.    authorization server validation but will send the authorization code
  5.    or access token to an endpoint under the control of the attacker.

10.16. Misuse of Access Token to Impersonate Resource Owner in Implicit

Flow

  1.  
  2.    For public clients using implicit flows, this specification does not
  3.    provide any method for the client to determine what client an access
  4.    token was issued to.
  5.  
  6.    A resource owner may willingly delegate access to a resource by
  7.    granting an access token to an attacker's malicious client.  This may
  8.    be due to phishing or some other pretext.  An attacker may also steal
  9.    a token via some other mechanism.  An attacker may then attempt to
  10.    impersonate the resource owner by providing the access token to a
  11.    legitimate public client.
  12.  
  13.    In the implicit flow (response_type=token), the attacker can easily
  14.    switch the token in the response from the authorization server,
  15.    replacing the real access token with the one previously issued to the
  16.    attacker.
  17.  
  18.    Servers communicating with native applications that rely on being
  19.    passed an access token in the back channel to identify the user of
  20.    the client may be similarly compromised by an attacker creating a
  21.    compromised application that can inject arbitrary stolen access
  22.    tokens.
  23.  
  24.    Any public client that makes the assumption that only the resource
  25.    owner can present it with a valid access token for the resource is
  26.    vulnerable to this type of attack.
  27.  
  28.    This type of attack may expose information about the resource owner
  29.    at the legitimate client to the attacker (malicious client).  This
  30.    will also allow the attacker to perform operations at the legitimate
  31.    client with the same permissions as the resource owner who originally
  32.    granted the access token or authorization code.
  33.  
  34.    Authenticating resource owners to clients is out of scope for this
  35.    specification.  Any specification that uses the authorization process
  36.    as a form of delegated end-user authentication to the client (e.g.,
  37.    third-party sign-in service) MUST NOT use the implicit flow without
  38.    additional security mechanisms that would enable the client to
  39.    determine if the access token was issued for its use (e.g., audience-
  40.    restricting the access token).
  41.  
  42. Hardt                        Standards Track                   [Page 61]

  1. RFC 6749                        OAuth 2.0                   October 2012

11. IANA Considerations

11.1. OAuth Access Token Types Registry

  1.  
  2.    This specification establishes the OAuth Access Token Types registry.
  3.  
  4.    Access token types are registered with a Specification Required
  5.    ([RFC5226]) after a two-week review period on the
  6.    oauth-ext-review@ietf.org mailing list, on the advice of one or more
  7.    Designated Experts.  However, to allow for the allocation of values
  8.    prior to publication, the Designated Expert(s) may approve
  9.    registration once they are satisfied that such a specification will
  10.    be published.
  11.  
  12.    Registration requests must be sent to the oauth-ext-review@ietf.org
  13.    mailing list for review and comment, with an appropriate subject
  14.    (e.g., "Request for access token type: example").
  15.  
  16.    Within the review period, the Designated Expert(s) will either
  17.    approve or deny the registration request, communicating this decision
  18.    to the review list and IANA.  Denials should include an explanation
  19.    and, if applicable, suggestions as to how to make the request
  20.    successful.
  21.  
  22.    IANA must only accept registry updates from the Designated Expert(s)
  23.    and should direct all requests for registration to the review mailing
  24.    list.

11.1.1. Registration Template

  1.  
  2.    Type name:
  3.       The name requested (e.g., "example").
  4.  
  5.    Additional Token Endpoint Response Parameters:
  6.       Additional response parameters returned together with the
  7.       "access_token" parameter.  New parameters MUST be separately
  8.       registered in the OAuth Parameters registry as described by
  9.       Section 11.2.
  10.  
  11.    HTTP Authentication Scheme(s):
  12.       The HTTP authentication scheme name(s), if any, used to
  13.       authenticate protected resource requests using access tokens of
  14.       this type.
  15.  
  16.    Change controller:
  17.       For Standards Track RFCs, state "IETF".  For others, give the name
  18.       of the responsible party.  Other details (e.g., postal address,
  19.       email address, home page URI) may also be included.
  20.  
  21. Hardt                        Standards Track                   [Page 62]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Specification document(s):
  4.       Reference to the document(s) that specify the parameter,
  5.       preferably including a URI that can be used to retrieve a copy of
  6.       the document(s).  An indication of the relevant sections may also
  7.       be included but is not required.

11.2. OAuth Parameters Registry

  1.  
  2.    This specification establishes the OAuth Parameters registry.
  3.  
  4.    Additional parameters for inclusion in the authorization endpoint
  5.    request, the authorization endpoint response, the token endpoint
  6.    request, or the token endpoint response are registered with a
  7.    Specification Required ([RFC5226]) after a two-week review period on
  8.    the oauth-ext-review@ietf.org mailing list, on the advice of one or
  9.    more Designated Experts.  However, to allow for the allocation of
  10.    values prior to publication, the Designated Expert(s) may approve
  11.    registration once they are satisfied that such a specification will
  12.    be published.
  13.  
  14.    Registration requests must be sent to the oauth-ext-review@ietf.org
  15.    mailing list for review and comment, with an appropriate subject
  16.    (e.g., "Request for parameter: example").
  17.  
  18.    Within the review period, the Designated Expert(s) will either
  19.    approve or deny the registration request, communicating this decision
  20.    to the review list and IANA.  Denials should include an explanation
  21.    and, if applicable, suggestions as to how to make the request
  22.    successful.
  23.  
  24.    IANA must only accept registry updates from the Designated Expert(s)
  25.    and should direct all requests for registration to the review mailing
  26.    list.

11.2.1. Registration Template

  1.  
  2.    Parameter name:
  3.       The name requested (e.g., "example").
  4.  
  5.    Parameter usage location:
  6.       The location(s) where parameter can be used.  The possible
  7.       locations are authorization request, authorization response, token
  8.       request, or token response.
  9.  
  10.    Change controller:
  11.       For Standards Track RFCs, state "IETF".  For others, give the name
  12.       of the responsible party.  Other details (e.g., postal address,
  13.       email address, home page URI) may also be included.
  14.  
  15. Hardt                        Standards Track                   [Page 63]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    Specification document(s):
  4.       Reference to the document(s) that specify the parameter,
  5.       preferably including a URI that can be used to retrieve a copy of
  6.       the document(s).  An indication of the relevant sections may also
  7.       be included but is not required.

11.2.2. Initial Registry Contents

  1.  
  2.    The OAuth Parameters registry's initial contents are:
  3.  
  4.    o  Parameter name: client_id
  5.    o  Parameter usage location: authorization request, token request
  6.    o  Change controller: IETF
  7.    o  Specification document(s): RFC 6749
  8.  
  9.    o  Parameter name: client_secret
  10.    o  Parameter usage location: token request
  11.    o  Change controller: IETF
  12.    o  Specification document(s): RFC 6749
  13.  
  14.    o  Parameter name: response_type
  15.    o  Parameter usage location: authorization request
  16.    o  Change controller: IETF
  17.    o  Specification document(s): RFC 6749
  18.  
  19.    o  Parameter name: redirect_uri
  20.    o  Parameter usage location: authorization request, token request
  21.    o  Change controller: IETF
  22.    o  Specification document(s): RFC 6749
  23.  
  24.    o  Parameter name: scope
  25.    o  Parameter usage location: authorization request, authorization
  26.       response, token request, token response
  27.    o  Change controller: IETF
  28.    o  Specification document(s): RFC 6749
  29.  
  30.    o  Parameter name: state
  31.    o  Parameter usage location: authorization request, authorization
  32.       response
  33.    o  Change controller: IETF
  34.    o  Specification document(s): RFC 6749
  35.  
  36.    o  Parameter name: code
  37.    o  Parameter usage location: authorization response, token request
  38.    o  Change controller: IETF
  39.    o  Specification document(s): RFC 6749
  40.  
  41. Hardt                        Standards Track                   [Page 64]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    o  Parameter name: error_description
  4.    o  Parameter usage location: authorization response, token response
  5.    o  Change controller: IETF
  6.    o  Specification document(s): RFC 6749
  7.  
  8.    o  Parameter name: error_uri
  9.    o  Parameter usage location: authorization response, token response
  10.    o  Change controller: IETF
  11.    o  Specification document(s): RFC 6749
  12.  
  13.    o  Parameter name: grant_type
  14.    o  Parameter usage location: token request
  15.    o  Change controller: IETF
  16.    o  Specification document(s): RFC 6749
  17.  
  18.    o  Parameter name: access_token
  19.    o  Parameter usage location: authorization response, token response
  20.    o  Change controller: IETF
  21.    o  Specification document(s): RFC 6749
  22.  
  23.    o  Parameter name: token_type
  24.    o  Parameter usage location: authorization response, token response
  25.    o  Change controller: IETF
  26.    o  Specification document(s): RFC 6749
  27.  
  28.    o  Parameter name: expires_in
  29.    o  Parameter usage location: authorization response, token response
  30.    o  Change controller: IETF
  31.    o  Specification document(s): RFC 6749
  32.  
  33.    o  Parameter name: username
  34.    o  Parameter usage location: token request
  35.    o  Change controller: IETF
  36.    o  Specification document(s): RFC 6749
  37.  
  38.    o  Parameter name: password
  39.    o  Parameter usage location: token request
  40.    o  Change controller: IETF
  41.    o  Specification document(s): RFC 6749
  42.  
  43.    o  Parameter name: refresh_token
  44.    o  Parameter usage location: token request, token response
  45.    o  Change controller: IETF
  46.    o  Specification document(s): RFC 6749
  47.  
  48. Hardt                        Standards Track                   [Page 65]

  1. RFC 6749                        OAuth 2.0                   October 2012

11.3. OAuth Authorization Endpoint Response Types Registry

  1.  
  2.    This specification establishes the OAuth Authorization Endpoint
  3.    Response Types registry.
  4.  
  5.    Additional response types for use with the authorization endpoint are
  6.    registered with a Specification Required ([RFC5226]) after a two-week
  7.    review period on the oauth-ext-review@ietf.org mailing list, on the
  8.    advice of one or more Designated Experts.  However, to allow for the
  9.    allocation of values prior to publication, the Designated Expert(s)
  10.    may approve registration once they are satisfied that such a
  11.    specification will be published.
  12.  
  13.    Registration requests must be sent to the oauth-ext-review@ietf.org
  14.    mailing list for review and comment, with an appropriate subject
  15.    (e.g., "Request for response type: example").
  16.  
  17.    Within the review period, the Designated Expert(s) will either
  18.    approve or deny the registration request, communicating this decision
  19.    to the review list and IANA.  Denials should include an explanation
  20.    and, if applicable, suggestions as to how to make the request
  21.    successful.
  22.  
  23.    IANA must only accept registry updates from the Designated Expert(s)
  24.    and should direct all requests for registration to the review mailing
  25.    list.

11.3.1. Registration Template

  1.  
  2.    Response type name:
  3.       The name requested (e.g., "example").
  4.  
  5.    Change controller:
  6.       For Standards Track RFCs, state "IETF".  For others, give the name
  7.       of the responsible party.  Other details (e.g., postal address,
  8.       email address, home page URI) may also be included.
  9.  
  10.    Specification document(s):
  11.       Reference to the document(s) that specify the type, preferably
  12.       including a URI that can be used to retrieve a copy of the
  13.       document(s).  An indication of the relevant sections may also be
  14.       included but is not required.
  15.  
  16. Hardt                        Standards Track                   [Page 66]

  1. RFC 6749                        OAuth 2.0                   October 2012

11.3.2. Initial Registry Contents

  1.  
  2.    The OAuth Authorization Endpoint Response Types registry's initial
  3.    contents are:
  4.  
  5.    o  Response type name: code
  6.    o  Change controller: IETF
  7.    o  Specification document(s): RFC 6749
  8.  
  9.    o  Response type name: token
  10.    o  Change controller: IETF
  11.    o  Specification document(s): RFC 6749

11.4. OAuth Extensions Error Registry

  1.  
  2.    This specification establishes the OAuth Extensions Error registry.
  3.  
  4.    Additional error codes used together with other protocol extensions
  5.    (i.e., extension grant types, access token types, or extension
  6.    parameters) are registered with a Specification Required ([RFC5226])
  7.    after a two-week review period on the oauth-ext-review@ietf.org
  8.    mailing list, on the advice of one or more Designated Experts.
  9.    However, to allow for the allocation of values prior to publication,
  10.    the Designated Expert(s) may approve registration once they are
  11.    satisfied that such a specification will be published.
  12.  
  13.    Registration requests must be sent to the oauth-ext-review@ietf.org
  14.    mailing list for review and comment, with an appropriate subject
  15.    (e.g., "Request for error code: example").
  16.  
  17.    Within the review period, the Designated Expert(s) will either
  18.    approve or deny the registration request, communicating this decision
  19.    to the review list and IANA.  Denials should include an explanation
  20.    and, if applicable, suggestions as to how to make the request
  21.    successful.
  22.  
  23.    IANA must only accept registry updates from the Designated Expert(s)
  24.    and should direct all requests for registration to the review mailing
  25.    list.
  26.  
  27. Hardt                        Standards Track                   [Page 67]

  1. RFC 6749                        OAuth 2.0                   October 2012

11.4.1. Registration Template

  1.  
  2.    Error name:
  3.       The name requested (e.g., "example").  Values for the error name
  4.       MUST NOT include characters outside the set %x20-21 / %x23-5B /
  5.       %x5D-7E.
  6.  
  7.    Error usage location:
  8.       The location(s) where the error can be used.  The possible
  9.       locations are authorization code grant error response
  10.       (Section 4.1.2.1), implicit grant error response
  11.       (Section 4.2.2.1), token error response (Section 5.2), or resource
  12.       access error response (Section 7.2).
  13.  
  14.    Related protocol extension:
  15.       The name of the extension grant type, access token type, or
  16.       extension parameter that the error code is used in conjunction
  17.       with.
  18.  
  19.    Change controller:
  20.       For Standards Track RFCs, state "IETF".  For others, give the name
  21.       of the responsible party.  Other details (e.g., postal address,
  22.       email address, home page URI) may also be included.
  23.  
  24.    Specification document(s):
  25.       Reference to the document(s) that specify the error code,
  26.       preferably including a URI that can be used to retrieve a copy of
  27.       the document(s).  An indication of the relevant sections may also
  28.       be included but is not required.

12. References

12.1. Normative References

  1.  
  2.    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  3.               Requirement Levels", BCP 14, RFC 2119, March 1997.
  4.  
  5.    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
  6.               RFC 2246, January 1999.
  7.  
  8.    [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
  9.               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
  10.               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  11.  
  12.    [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
  13.               Leach, P., Luotonen, A., and L. Stewart, "HTTP
  14.               Authentication: Basic and Digest Access Authentication",
  15.               RFC 2617, June 1999.
  16.  
  17. Hardt                        Standards Track                   [Page 68]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
  4.  
  5.    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
  6.               ISO 10646", STD 63, RFC 3629, November 2003.
  7.  
  8.    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
  9.               Resource Identifier (URI): Generic Syntax", STD 66,
  10.               RFC 3986, January 2005.
  11.  
  12.    [RFC4627]  Crockford, D., "The application/json Media Type for
  13.               JavaScript Object Notation (JSON)", RFC 4627, July 2006.
  14.  
  15.    [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
  16.               RFC 4949, August 2007.
  17.  
  18.    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
  19.               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
  20.               May 2008.
  21.  
  22.    [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
  23.               Specifications: ABNF", STD 68, RFC 5234, January 2008.
  24.  
  25.    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
  26.               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  27.  
  28.    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
  29.               Verification of Domain-Based Application Service Identity
  30.               within Internet Public Key Infrastructure Using X.509
  31.               (PKIX) Certificates in the Context of Transport Layer
  32.               Security (TLS)", RFC 6125, March 2011.
  33.  
  34.    [USASCII]  American National Standards Institute, "Coded Character
  35.               Set -- 7-bit American Standard Code for Information
  36.               Interchange", ANSI X3.4, 1986.
  37.  
  38.    [W3C.REC-html401-19991224]
  39.               Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
  40.               Specification", World Wide Web Consortium
  41.               Recommendation REC-html401-19991224, December 1999,
  42.               <http://www.w3.org/TR/1999/REC-html401-19991224>.
  43.  
  44.    [W3C.REC-xml-20081126]
  45.               Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
  46.               and F. Yergeau, "Extensible Markup Language (XML) 1.0
  47.               (Fifth Edition)", World Wide Web Consortium
  48.                Recommendation REC-xml-20081126, November 2008,
  49.               <http://www.w3.org/TR/2008/REC-xml-20081126>.
  50.  
  51. Hardt                        Standards Track                   [Page 69]

  1. RFC 6749                        OAuth 2.0                   October 2012

12.2. Informative References

  1.  
  2.    [OAuth-HTTP-MAC]
  3.               Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access
  4.               Authentication", Work in Progress, February 2012.
  5.  
  6.    [OAuth-SAML2]
  7.               Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
  8.               Profiles for OAuth 2.0", Work in Progress, September 2012.
  9.  
  10.    [OAuth-THREATMODEL]
  11.               Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
  12.               Threat Model and Security Considerations", Work
  13.               in Progress, October 2012.
  14.  
  15.    [OAuth-WRAP]
  16.               Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
  17.               Web Resource Authorization Profiles", Work in Progress,
  18.               January 2010.
  19.  
  20.    [RFC5849]  Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
  21.               April 2010.
  22.  
  23.    [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
  24.               Framework: Bearer Token Usage", RFC 6750, October 2012.
  25.  
  26. Hardt                        Standards Track                   [Page 70]

  1. RFC 6749                        OAuth 2.0                   October 2012

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

  1.  
  2.    This section provides Augmented Backus-Naur Form (ABNF) syntax
  3.    descriptions for the elements defined in this specification using the
  4.    notation of [RFC5234].  The ABNF below is defined in terms of Unicode
  5.    code points [W3C.REC-xml-20081126]; these characters are typically
  6.    encoded in UTF-8.  Elements are presented in the order first defined.
  7.  
  8.    Some of the definitions that follow use the "URI-reference"
  9.    definition from [RFC3986].
  10.  
  11.    Some of the definitions that follow use these common definitions:
  12.  
  13.      VSCHAR     = %x20-7E
  14.      NQCHAR     = %x21 / %x23-5B / %x5D-7E
  15.      NQSCHAR    = %x20-21 / %x23-5B / %x5D-7E
  16.      UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
  17.                          %xE000-FFFD / %x10000-10FFFF
  18.  
  19.    (The UNICODECHARNOCRLF definition is based upon the Char definition
  20.    in Section 2.2 of [W3C.REC-xml-20081126], but omitting the Carriage
  21.    Return and Linefeed characters.)

A.1. "client_id" Syntax

  1.  
  2.    The "client_id" element is defined in Section 2.3.1:
  3.  
  4.      client-id     = *VSCHAR

A.2. "client_secret" Syntax

  1.  
  2.    The "client_secret" element is defined in Section 2.3.1:
  3.  
  4.      client-secret = *VSCHAR

A.3. "response_type" Syntax

  1.  
  2.    The "response_type" element is defined in Sections 3.1.1 and 8.4:
  3.  
  4.      response-type = response-name *( SP response-name )
  5.      response-name = 1*response-char
  6.      response-char = "_" / DIGIT / ALPHA
  7.  
  8. Hardt                        Standards Track                   [Page 71]

  1. RFC 6749                        OAuth 2.0                   October 2012

A.4. "scope" Syntax

  1.  
  2.    The "scope" element is defined in Section 3.3:
  3.  
  4.      scope       = scope-token *( SP scope-token )
  5.      scope-token = 1*NQCHAR

A.5. "state" Syntax

  1.  
  2.    The "state" element is defined in Sections 4.1.1, 4.1.2, 4.1.2.1,
  3.    4.2.1, 4.2.2, and 4.2.2.1:
  4.  
  5.      state      = 1*VSCHAR

A.6. "redirect_uri" Syntax

  1.  
  2.    The "redirect_uri" element is defined in Sections 4.1.1, 4.1.3,
  3.    and 4.2.1:
  4.  
  5.      redirect-uri      = URI-reference

A.7. "error" Syntax

  1.  
  2.    The "error" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2,
  3.    7.2, and 8.5:
  4.  
  5.      error             = 1*NQSCHAR

A.8. "error_description" Syntax

  1.  
  2.    The "error_description" element is defined in Sections 4.1.2.1,
  3.    4.2.2.1, 5.2, and 7.2:
  4.  
  5.      error-description = 1*NQSCHAR

A.9. "error_uri" Syntax

  1.  
  2.    The "error_uri" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2,
  3.    and 7.2:
  4.  
  5.      error-uri         = URI-reference
  6.  
  7. Hardt                        Standards Track                   [Page 72]

  1. RFC 6749                        OAuth 2.0                   October 2012

A.10. "grant_type" Syntax

  1.  
  2.    The "grant_type" element is defined in Sections 4.1.3, 4.3.2, 4.4.2,
  3.    4.5, and 6:
  4.  
  5.      grant-type = grant-name / URI-reference
  6.      grant-name = 1*name-char
  7.      name-char  = "-" / "." / "_" / DIGIT / ALPHA

A.11. "code" Syntax

  1.  
  2.    The "code" element is defined in Section 4.1.3:
  3.  
  4.      code       = 1*VSCHAR

A.12. "access_token" Syntax

  1.  
  2.    The "access_token" element is defined in Sections 4.2.2 and 5.1:
  3.  
  4.      access-token = 1*VSCHAR

A.13. "token_type" Syntax

  1.  
  2.    The "token_type" element is defined in Sections 4.2.2, 5.1, and 8.1:
  3.  
  4.      token-type = type-name / URI-reference
  5.      type-name  = 1*name-char
  6.      name-char  = "-" / "." / "_" / DIGIT / ALPHA

A.14. "expires_in" Syntax

  1.  
  2.    The "expires_in" element is defined in Sections 4.2.2 and 5.1:
  3.  
  4.      expires-in = 1*DIGIT

A.15. "username" Syntax

  1.  
  2.    The "username" element is defined in Section 4.3.2:
  3.  
  4.      username = *UNICODECHARNOCRLF

A.16. "password" Syntax

  1.  
  2.    The "password" element is defined in Section 4.3.2:
  3.  
  4.      password = *UNICODECHARNOCRLF
  5.  
  6. Hardt                        Standards Track                   [Page 73]

  1. RFC 6749                        OAuth 2.0                   October 2012

A.17. "refresh_token" Syntax

  1.  
  2.    The "refresh_token" element is defined in Sections 5.1 and 6:
  3.  
  4.      refresh-token = 1*VSCHAR

A.18. Endpoint Parameter Syntax

  1.  
  2.    The syntax for new endpoint parameters is defined in Section 8.2:
  3.  
  4.      param-name = 1*name-char
  5.      name-char  = "-" / "." / "_" / DIGIT / ALPHA

Appendix B. Use of application/x-www-form-urlencoded Media Type

  1.  
  2.    At the time of publication of this specification, the
  3.    "application/x-www-form-urlencoded" media type was defined in
  4.    Section 17.13.4 of [W3C.REC-html401-19991224] but not registered in
  5.    the IANA MIME Media Types registry
  6.    (<http://www.iana.org/assignments/media-types>).  Furthermore, that
  7.    definition is incomplete, as it does not consider non-US-ASCII
  8.    characters.
  9.  
  10.    To address this shortcoming when generating payloads using this media
  11.    type, names and values MUST be encoded using the UTF-8 character
  12.    encoding scheme [RFC3629] first; the resulting octet sequence then
  13.    needs to be further encoded using the escaping rules defined in
  14.    [W3C.REC-html401-19991224].
  15.  
  16.    When parsing data from a payload using this media type, the names and
  17.    values resulting from reversing the name/value encoding consequently
  18.    need to be treated as octet sequences, to be decoded using the UTF-8
  19.    character encoding scheme.
  20.  
  21.    For example, the value consisting of the six Unicode code points
  22.    (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
  23.    (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
  24.    (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded
  25.    into the octet sequence below (using hexadecimal notation):
  26.  
  27.      20 25 26 2B C2 A3 E2 82 AC
  28.  
  29.    and then represented in the payload as:
  30.  
  31.      +%25%26%2B%C2%A3%E2%82%AC
  32.  
  33. Hardt                        Standards Track                   [Page 74]

  1. RFC 6749                        OAuth 2.0                   October 2012

Appendix C. Acknowledgements

  1.  
  2.    The initial OAuth 2.0 protocol specification was edited by David
  3.    Recordon, based on two previous publications: the OAuth 1.0 community
  4.    specification [RFC5849], and OAuth WRAP (OAuth Web Resource
  5.    Authorization Profiles) [OAuth-WRAP].  Eran Hammer then edited many
  6.    of the intermediate drafts that evolved into this RFC.  The Security
  7.    Considerations section was drafted by Torsten Lodderstedt, Mark
  8.    McGloin, Phil Hunt, Anthony Nadalin, and John Bradley.  The section
  9.    on use of the "application/x-www-form-urlencoded" media type was
  10.    drafted by Julian Reschke.  The ABNF section was drafted by Michael
  11.    B. Jones.
  12.  
  13.    The OAuth 1.0 community specification was edited by Eran Hammer and
  14.    authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M.
  15.    Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton,
  16.    Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris
  17.    Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
  18.    Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
  19.  
  20.    The OAuth WRAP specification was edited by Dick Hardt and authored by
  21.    Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom.
  22.  
  23.    This specification is the work of the OAuth Working Group, which
  24.    includes dozens of active and dedicated participants.  In particular,
  25.    the following individuals contributed ideas, feedback, and wording
  26.    that shaped and formed the final specification:
  27.  
  28.    Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
  29.    Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor,
  30.    Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre,
  31.    Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor
  32.    Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert,
  33.    Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer,
  34.    Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones,
  35.    Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara,
  36.    Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul
  37.    Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin,
  38.    Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin,
  39.    Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob
  40.    Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov,
  41.    Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner,
  42.    Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson,
  43.    Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar
  44.    Woodward.
  45.  
  46. Hardt                        Standards Track                   [Page 75]

  1. RFC 6749                        OAuth 2.0                   October 2012
  2.  
  3.    This document was produced under the chairmanship of Blaine Cook,
  4.    Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
  5.    The area directors included Lisa Dusseault, Peter Saint-Andre, and
  6.    Stephen Farrell.
  7.  
  8. Author's Address
  9.  
  10.    Dick Hardt (editor)
  11.    Microsoft
  12.  
  13.    EMail: dick.hardt@gmail.com
  14.    URI:   http://dickhardt.org/
  15.  
  16. Hardt                        Standards Track                   [Page 76]

Html markup produced by rfcmarkup 1.114, available from       https://tools.ietf.org/tools/rfcmarkup/       

The OAuth 2.0 Authorization Framework-摘自https://tools.ietf.org/html/rfc6749的更多相关文章

  1. OAuth 2.0 Authorization Framework RFC

    Internet Engineering Task Force (IETF) D. Hardt, Ed.Request for Comments: 6749 MicrosoftObsoletes: 5 ...

  2. The OAuth 2.0 Authorization Framework: Bearer Token Usage

    https://tools.ietf.org/html/rfc6750 1.2. Terminology Bearer Token A security token with the property ...

  3. The OAuth 2.0 Authorization Framework

      The OAuth 2.0 Authorization Framework Abstract The OAuth 2.0 authorization framework enables a thi ...

  4. The OAuth 2.0 Authorization Framework OAuth2.0的核心角色code 扫码登录

    RFC 6749 - The OAuth 2.0 Authorization Framework https://tools.ietf.org/html/rfc6749 The OAuth 2.0 a ...

  5. [转]OAuth 2.0 - Authorization Code授权方式详解

    本文转自:http://www.cnblogs.com/highend/archive/2012/07/06/oautn2_authorization_code.html I:OAuth 2.0 开发 ...

  6. OAuth 2.0 - Authorization Code授权方式详解

    I:OAuth 2.0 开发前期准备 天上不会自然掉馅饼让你轻松地去访问到人家资源服务器里面的用户数据资源,所以你需要做的前期开发准备工作就是把AppKey, AppSecret取到手 新浪获取传送门 ...

  7. OWIN OAuth 2.0 Authorization Server

    http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server The assumption ...

  8. https://tools.ietf.org/html/rfc8017

    PKCS #1: RSA Cryptography Specifications Version 2.2

  9. OAuth 2.0 / RCF6749 协议解读

    OAuth是第三方应用授权的开放标准,目前版本是2.0版,以下将要介绍的内容和概念主要来源于该版本.恐篇幅太长,OAuth 的诞生背景就不在这里赘述了,可参考 RFC 6749 . 四种角色定义: R ...

随机推荐

  1. 《OD学Hive》第六周20160730

    一.Hive的JDBC连接 日志分析结果数据,存储在hive中 <property> <name>hive.server2.thrift.port</name> & ...

  2. Indoor Positioning System & Real time location system

    背景 惨痛的背景,正如我前面提到的,参加了公司的一个训练营.刚进来公司的新人,内心充满着对未来的美好憧憬,期待自己能闯出属于自己的天地.更何况,作为一名程序员,无比的希望所有人对自己写得代码或者App ...

  3. [ionic开源项目教程] - 第7讲 实现下拉刷新上拉加载ion-refresher和ion-infinite-scroll

    第7讲 实现下拉刷新上拉加载ion-refresher和ion-infinite-scroll 1.将tab1.html的代码改为如下: <ion-content> <ion-ref ...

  4. 打印机C++

    m_prnDC.SetMapMode(MM_LOMETRIC);  m_iPrnX = m_prnDC.GetDeviceCaps(HORZRES);m_iPrnY = m_prnDC.GetDevi ...

  5. UIView的clipsToBounds属性，layoutSubViews及触摸事件传递（默认情况下）总结

    一.UIView的clipsToBounds属性 * 默认情况下,超出父控件尺寸范围的子控件还是可见的 * 如果设置父控件的clipsToBounds=YES,就会裁剪掉超出父控件尺寸范围内的子控件, ...

  6. wxWidgets进度条

    #include <wx/wx.h> #include <wx/progdlg.h> class myApp : public wxApp { public: bool OnI ...

  7. SeuRain的归来

    不知不觉二十载寒窗苦读要结束了,还没有到回顾过去的时候.马上进入研三了,现在要努力加油了.还记得曾经的那个在凌晨两点奋战的宇么?归来吧!

  8. 如何自定义一个优雅的ContentProvider

    最近在code review的时候发现很多人的provider定义的不是很好,写的很粗糙 以至于代码健壮性不够好,可读性也不强 但是你既然写了content provider 就是要给别人调用的,如果 ...

  9. jquery的jquery c.browser msie undefined的问题解决办法

    http://blchen.com/jQuery-can-not-read-property-msie-of-the-undefined-error-solution/ 转载: [jQuery] Ca ...

  10. ubuntu中flash的中文乱码解决方法

    ubuntu装好之后, 为浏览器firefox安装flash插件, 后来发现中文会变成方框. 如何解决? 输入:cd /etc/fonts/conf.d/ 为了安全,备份一下: sudo cp 49- ...