doc: Add RFC documents

1 files changed, 4259 insertions, 0 deletions

diff --git a/doc/rfc/rfc6749.txt b/doc/rfc/rfc6749.txt
new file mode 100644
index 0000000..5a0046c
--- /dev/null
+++ b/doc/rfc/rfc6749.txt
@@ -0,0 +1,4259 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     D. Hardt, Ed.
+Request for Comments: 6749                                     Microsoft
+Obsoletes: 5849                                             October 2012
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                 The OAuth 2.0 Authorization Framework
+
+Abstract
+
+   The OAuth 2.0 authorization framework enables a third-party
+   application to obtain limited access to an HTTP service, either on
+   behalf of a resource owner by orchestrating an approval interaction
+   between the resource owner and the HTTP service, or by allowing the
+   third-party application to obtain access on its own behalf.  This
+   specification replaces and obsoletes the OAuth 1.0 protocol described
+   in RFC 5849.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6749.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Hardt                        Standards Track                    [Page 1]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Roles ......................................................6
+      1.2. Protocol Flow ..............................................7
+      1.3. Authorization Grant ........................................8
+           1.3.1. Authorization Code ..................................8
+           1.3.2. Implicit ............................................8
+           1.3.3. Resource Owner Password Credentials .................9
+           1.3.4. Client Credentials ..................................9
+      1.4. Access Token ..............................................10
+      1.5. Refresh Token .............................................10
+      1.6. TLS Version ...............................................12
+      1.7. HTTP Redirections .........................................12
+      1.8. Interoperability ..........................................12
+      1.9. Notational Conventions ....................................13
+   2. Client Registration ............................................13
+      2.1. Client Types ..............................................14
+      2.2. Client Identifier .........................................15
+      2.3. Client Authentication .....................................16
+           2.3.1. Client Password ....................................16
+           2.3.2. Other Authentication Methods .......................17
+      2.4. Unregistered Clients ......................................17
+   3. Protocol Endpoints .............................................18
+      3.1. Authorization Endpoint ....................................18
+           3.1.1. Response Type ......................................19
+           3.1.2. Redirection Endpoint ...............................19
+      3.2. Token Endpoint ............................................21
+           3.2.1. Client Authentication ..............................22
+      3.3. Access Token Scope ........................................23
+   4. Obtaining Authorization ........................................23
+      4.1. Authorization Code Grant ..................................24
+           4.1.1. Authorization Request ..............................25
+           4.1.2. Authorization Response .............................26
+           4.1.3. Access Token Request ...............................29
+           4.1.4. Access Token Response ..............................30
+      4.2. Implicit Grant ............................................31
+           4.2.1. Authorization Request ..............................33
+           4.2.2. Access Token Response ..............................35
+      4.3. Resource Owner Password Credentials Grant .................37
+           4.3.1. Authorization Request and Response .................39
+           4.3.2. Access Token Request ...............................39
+           4.3.3. Access Token Response ..............................40
+      4.4. Client Credentials Grant ..................................40
+           4.4.1. Authorization Request and Response .................41
+           4.4.2. Access Token Request ...............................41
+           4.4.3. Access Token Response ..............................42
+      4.5. Extension Grants ..........................................42
+
+
+
+Hardt                        Standards Track                    [Page 2]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   5. Issuing an Access Token ........................................43
+      5.1. Successful Response .......................................43
+      5.2. Error Response ............................................45
+   6. Refreshing an Access Token .....................................47
+   7. Accessing Protected Resources ..................................48
+      7.1. Access Token Types ........................................49
+      7.2. Error Response ............................................49
+   8. Extensibility ..................................................50
+      8.1. Defining Access Token Types ...............................50
+      8.2. Defining New Endpoint Parameters ..........................50
+      8.3. Defining New Authorization Grant Types ....................51
+      8.4. Defining New Authorization Endpoint Response Types ........51
+      8.5. Defining Additional Error Codes ...........................51
+   9. Native Applications ............................................52
+   10. Security Considerations .......................................53
+      10.1. Client Authentication ....................................53
+      10.2. Client Impersonation .....................................54
+      10.3. Access Tokens ............................................55
+      10.4. Refresh Tokens ...........................................55
+      10.5. Authorization Codes ......................................56
+      10.6. Authorization Code Redirection URI Manipulation ..........56
+      10.7. Resource Owner Password Credentials ......................57
+      10.8. Request Confidentiality ..................................58
+      10.9. Ensuring Endpoint Authenticity ...........................58
+      10.10. Credentials-Guessing Attacks ............................58
+      10.11. Phishing Attacks ........................................58
+      10.12. Cross-Site Request Forgery ..............................59
+      10.13. Clickjacking ............................................60
+      10.14. Code Injection and Input Validation .....................60
+      10.15. Open Redirectors ........................................60
+      10.16. Misuse of Access Token to Impersonate Resource
+             Owner in Implicit Flow ..................................61
+   11. IANA Considerations ...........................................62
+      11.1. OAuth Access Token Types Registry ........................62
+           11.1.1. Registration Template .............................62
+      11.2. OAuth Parameters Registry ................................63
+           11.2.1. Registration Template .............................63
+           11.2.2. Initial Registry Contents .........................64
+      11.3. OAuth Authorization Endpoint Response Types Registry .....66
+           11.3.1. Registration Template .............................66
+           11.3.2. Initial Registry Contents .........................67
+      11.4. OAuth Extensions Error Registry ..........................67
+           11.4.1. Registration Template .............................68
+   12. References ....................................................68
+      12.1. Normative References .....................................68
+      12.2. Informative References ...................................70
+
+
+
+
+
+Hardt                        Standards Track                    [Page 3]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71
+     A.1.  "client_id" Syntax ........................................71
+     A.2.  "client_secret" Syntax ....................................71
+     A.3.  "response_type" Syntax ....................................71
+     A.4.  "scope" Syntax ............................................72
+     A.5.  "state" Syntax ............................................72
+     A.6.  "redirect_uri" Syntax .....................................72
+     A.7.  "error" Syntax ............................................72
+     A.8.  "error_description" Syntax ................................72
+     A.9.  "error_uri" Syntax ........................................72
+     A.10. "grant_type" Syntax .......................................73
+     A.11. "code" Syntax .............................................73
+     A.12. "access_token" Syntax .....................................73
+     A.13. "token_type" Syntax .......................................73
+     A.14. "expires_in" Syntax .......................................73
+     A.15. "username" Syntax .........................................73
+     A.16. "password" Syntax .........................................73
+     A.17. "refresh_token" Syntax ....................................74
+     A.18. Endpoint Parameter Syntax .................................74
+   Appendix B. Use of application/x-www-form-urlencoded Media Type ...74
+   Appendix C. Acknowledgements ......................................75
+
+1.  Introduction
+
+   In the traditional client-server authentication model, the client
+   requests an access-restricted resource (protected resource) on the
+   server by authenticating with the server using the resource owner's
+   credentials.  In order to provide third-party applications access to
+   restricted resources, the resource owner shares its credentials with
+   the third party.  This creates several problems and limitations:
+
+   o  Third-party applications are required to store the resource
+      owner's credentials for future use, typically a password in
+      clear-text.
+
+   o  Servers are required to support password authentication, despite
+      the security weaknesses inherent in passwords.
+
+   o  Third-party applications gain overly broad access to the resource
+      owner's protected resources, leaving resource owners without any
+      ability to restrict duration or access to a limited subset of
+      resources.
+
+   o  Resource owners cannot revoke access to an individual third party
+      without revoking access to all third parties, and must do so by
+      changing the third party's password.
+
+
+
+
+
+Hardt                        Standards Track                    [Page 4]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   o  Compromise of any third-party application results in compromise of
+      the end-user's password and all of the data protected by that
+      password.
+
+   OAuth addresses these issues by introducing an authorization layer
+   and separating the role of the client from that of the resource
+   owner.  In OAuth, the client requests access to resources controlled
+   by the resource owner and hosted by the resource server, and is
+   issued a different set of credentials than those of the resource
+   owner.
+
+   Instead of using the resource owner's credentials to access protected
+   resources, the client obtains an access token -- a string denoting a
+   specific scope, lifetime, and other access attributes.  Access tokens
+   are issued to third-party clients by an authorization server with the
+   approval of the resource owner.  The client uses the access token to
+   access the protected resources hosted by the resource server.
+
+   For example, an end-user (resource owner) can grant a printing
+   service (client) access to her protected photos stored at a photo-
+   sharing service (resource server), without sharing her username and
+   password with the printing service.  Instead, she authenticates
+   directly with a server trusted by the photo-sharing service
+   (authorization server), which issues the printing service delegation-
+   specific credentials (access token).
+
+   This specification is designed for use with HTTP ([RFC2616]).  The
+   use of OAuth over any protocol other than HTTP is out of scope.
+
+   The OAuth 1.0 protocol ([RFC5849]), published as an informational
+   document, was the result of a small ad hoc community effort.  This
+   Standards Track specification builds on the OAuth 1.0 deployment
+   experience, as well as additional use cases and extensibility
+   requirements gathered from the wider IETF community.  The OAuth 2.0
+   protocol is not backward compatible with OAuth 1.0.  The two versions
+   may co-exist on the network, and implementations may choose to
+   support both.  However, it is the intention of this specification
+   that new implementations support OAuth 2.0 as specified in this
+   document and that OAuth 1.0 is used only to support existing
+   deployments.  The OAuth 2.0 protocol shares very few implementation
+   details with the OAuth 1.0 protocol.  Implementers familiar with
+   OAuth 1.0 should approach this document without any assumptions as to
+   its structure and details.
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                    [Page 5]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+1.1.  Roles
+
+   OAuth defines four roles:
+
+   resource owner
+      An entity capable of granting access to a protected resource.
+      When the resource owner is a person, it is referred to as an
+      end-user.
+
+   resource server
+      The server hosting the protected resources, capable of accepting
+      and responding to protected resource requests using access tokens.
+
+   client
+      An application making protected resource requests on behalf of the
+      resource owner and with its authorization.  The term "client" does
+      not imply any particular implementation characteristics (e.g.,
+      whether the application executes on a server, a desktop, or other
+      devices).
+
+   authorization server
+      The server issuing access tokens to the client after successfully
+      authenticating the resource owner and obtaining authorization.
+
+   The interaction between the authorization server and resource server
+   is beyond the scope of this specification.  The authorization server
+   may be the same server as the resource server or a separate entity.
+   A single authorization server may issue access tokens accepted by
+   multiple resource servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                    [Page 6]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+1.2.  Protocol Flow
+
+     +--------+                               +---------------+
+     |        |--(A)- Authorization Request ->|   Resource    |
+     |        |                               |     Owner     |
+     |        |<-(B)-- Authorization Grant ---|               |
+     |        |                               +---------------+
+     |        |
+     |        |                               +---------------+
+     |        |--(C)-- Authorization Grant -->| Authorization |
+     | Client |                               |     Server    |
+     |        |<-(D)----- Access Token -------|               |
+     |        |                               +---------------+
+     |        |
+     |        |                               +---------------+
+     |        |--(E)----- Access Token ------>|    Resource   |
+     |        |                               |     Server    |
+     |        |<-(F)--- Protected Resource ---|               |
+     +--------+                               +---------------+
+
+                     Figure 1: Abstract Protocol Flow
+
+   The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
+   interaction between the four roles and includes the following steps:
+
+   (A)  The client requests authorization from the resource owner.  The
+        authorization request can be made directly to the resource owner
+        (as shown), or preferably indirectly via the authorization
+        server as an intermediary.
+
+   (B)  The client receives an authorization grant, which is a
+        credential representing the resource owner's authorization,
+        expressed using one of four grant types defined in this
+        specification or using an extension grant type.  The
+        authorization grant type depends on the method used by the
+        client to request authorization and the types supported by the
+        authorization server.
+
+   (C)  The client requests an access token by authenticating with the
+        authorization server and presenting the authorization grant.
+
+   (D)  The authorization server authenticates the client and validates
+        the authorization grant, and if valid, issues an access token.
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                    [Page 7]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   (E)  The client requests the protected resource from the resource
+        server and authenticates by presenting the access token.
+
+   (F)  The resource server validates the access token, and if valid,
+        serves the request.
+
+   The preferred method for the client to obtain an authorization grant
+   from the resource owner (depicted in steps (A) and (B)) is to use the
+   authorization server as an intermediary, which is illustrated in
+   Figure 3 in Section 4.1.
+
+1.3.  Authorization Grant
+
+   An authorization grant is a credential representing the resource
+   owner's authorization (to access its protected resources) used by the
+   client to obtain an access token.  This specification defines four
+   grant types -- authorization code, implicit, resource owner password
+   credentials, and client credentials -- as well as an extensibility
+   mechanism for defining additional types.
+
+1.3.1.  Authorization Code
+
+   The authorization code is obtained by using an authorization server
+   as an intermediary between the client and resource owner.  Instead of
+   requesting authorization directly from the resource owner, the client
+   directs the resource owner to an authorization server (via its
+   user-agent as defined in [RFC2616]), which in turn directs the
+   resource owner back to the client with the authorization code.
+
+   Before directing the resource owner back to the client with the
+   authorization code, the authorization server authenticates the
+   resource owner and obtains authorization.  Because the resource owner
+   only authenticates with the authorization server, the resource
+   owner's credentials are never shared with the client.
+
+   The authorization code provides a few important security benefits,
+   such as the ability to authenticate the client, as well as the
+   transmission of the access token directly to the client without
+   passing it through the resource owner's user-agent and potentially
+   exposing it to others, including the resource owner.
+
+1.3.2.  Implicit
+
+   The implicit grant is a simplified authorization code flow optimized
+   for clients implemented in a browser using a scripting language such
+   as JavaScript.  In the implicit flow, instead of issuing the client
+   an authorization code, the client is issued an access token directly
+
+
+
+
+Hardt                        Standards Track                    [Page 8]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   (as the result of the resource owner authorization).  The grant type
+   is implicit, as no intermediate credentials (such as an authorization
+   code) are issued (and later used to obtain an access token).
+
+   When issuing an access token during the implicit grant flow, the
+   authorization server does not authenticate the client.  In some
+   cases, the client identity can be verified via the redirection URI
+   used to deliver the access token to the client.  The access token may
+   be exposed to the resource owner or other applications with access to
+   the resource owner's user-agent.
+
+   Implicit grants improve the responsiveness and efficiency of some
+   clients (such as a client implemented as an in-browser application),
+   since it reduces the number of round trips required to obtain an
+   access token.  However, this convenience should be weighed against
+   the security implications of using implicit grants, such as those
+   described in Sections 10.3 and 10.16, especially when the
+   authorization code grant type is available.
+
+1.3.3.  Resource Owner Password Credentials
+
+   The resource owner password credentials (i.e., username and password)
+   can be used directly as an authorization grant to obtain an access
+   token.  The credentials should only be used when there is a high
+   degree of trust between the resource owner and the client (e.g., the
+   client is part of the device operating system or a highly privileged
+   application), and when other authorization grant types are not
+   available (such as an authorization code).
+
+   Even though this grant type requires direct client access to the
+   resource owner credentials, the resource owner credentials are used
+   for a single request and are exchanged for an access token.  This
+   grant type can eliminate the need for the client to store the
+   resource owner credentials for future use, by exchanging the
+   credentials with a long-lived access token or refresh token.
+
+1.3.4.  Client Credentials
+
+   The client credentials (or other forms of client authentication) can
+   be used as an authorization grant when the authorization scope is
+   limited to the protected resources under the control of the client,
+   or to protected resources previously arranged with the authorization
+   server.  Client credentials are used as an authorization grant
+   typically when the client is acting on its own behalf (the client is
+   also the resource owner) or is requesting access to protected
+   resources based on an authorization previously arranged with the
+   authorization server.
+
+
+
+
+Hardt                        Standards Track                    [Page 9]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+1.4.  Access Token
+
+   Access tokens are credentials used to access protected resources.  An
+   access token is a string representing an authorization issued to the
+   client.  The string is usually opaque to the client.  Tokens
+   represent specific scopes and durations of access, granted by the
+   resource owner, and enforced by the resource server and authorization
+   server.
+
+   The token may denote an identifier used to retrieve the authorization
+   information or may self-contain the authorization information in a
+   verifiable manner (i.e., a token string consisting of some data and a
+   signature).  Additional authentication credentials, which are beyond
+   the scope of this specification, may be required in order for the
+   client to use a token.
+
+   The access token provides an abstraction layer, replacing different
+   authorization constructs (e.g., username and password) with a single
+   token understood by the resource server.  This abstraction enables
+   issuing access tokens more restrictive than the authorization grant
+   used to obtain them, as well as removing the resource server's need
+   to understand a wide range of authentication methods.
+
+   Access tokens can have different formats, structures, and methods of
+   utilization (e.g., cryptographic properties) based on the resource
+   server security requirements.  Access token attributes and the
+   methods used to access protected resources are beyond the scope of
+   this specification and are defined by companion specifications such
+   as [RFC6750].
+
+1.5.  Refresh Token
+
+   Refresh tokens are credentials used to obtain access tokens.  Refresh
+   tokens are issued to the client by the authorization server and are
+   used to obtain a new access token when the current access token
+   becomes invalid or expires, or to obtain additional access tokens
+   with identical or narrower scope (access tokens may have a shorter
+   lifetime and fewer permissions than authorized by the resource
+   owner).  Issuing a refresh token is optional at the discretion of the
+   authorization server.  If the authorization server issues a refresh
+   token, it is included when issuing an access token (i.e., step (D) in
+   Figure 1).
+
+   A refresh token is a string representing the authorization granted to
+   the client by the resource owner.  The string is usually opaque to
+   the client.  The token denotes an identifier used to retrieve the
+
+
+
+
+
+Hardt                        Standards Track                   [Page 10]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   authorization information.  Unlike access tokens, refresh tokens are
+   intended for use only with authorization servers and are never sent
+   to resource servers.
+
+  +--------+                                           +---------------+
+  |        |--(A)------- Authorization Grant --------->|               |
+  |        |                                           |               |
+  |        |<-(B)----------- Access Token -------------|               |
+  |        |               & Refresh Token             |               |
+  |        |                                           |               |
+  |        |                            +----------+   |               |
+  |        |--(C)---- Access Token ---->|          |   |               |
+  |        |                            |          |   |               |
+  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
+  | Client |                            |  Server  |   |     Server    |
+  |        |--(E)---- Access Token ---->|          |   |               |
+  |        |                            |          |   |               |
+  |        |<-(F)- Invalid Token Error -|          |   |               |
+  |        |                            +----------+   |               |
+  |        |                                           |               |
+  |        |--(G)----------- Refresh Token ----------->|               |
+  |        |                                           |               |
+  |        |<-(H)----------- Access Token -------------|               |
+  +--------+           & Optional Refresh Token        +---------------+
+
+               Figure 2: Refreshing an Expired Access Token
+
+   The flow illustrated in Figure 2 includes the following steps:
+
+   (A)  The client requests an access token by authenticating with the
+        authorization server and presenting an authorization grant.
+
+   (B)  The authorization server authenticates the client and validates
+        the authorization grant, and if valid, issues an access token
+        and a refresh token.
+
+   (C)  The client makes a protected resource request to the resource
+        server by presenting the access token.
+
+   (D)  The resource server validates the access token, and if valid,
+        serves the request.
+
+   (E)  Steps (C) and (D) repeat until the access token expires.  If the
+        client knows the access token expired, it skips to step (G);
+        otherwise, it makes another protected resource request.
+
+   (F)  Since the access token is invalid, the resource server returns
+        an invalid token error.
+
+
+
+Hardt                        Standards Track                   [Page 11]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   (G)  The client requests a new access token by authenticating with
+        the authorization server and presenting the refresh token.  The
+        client authentication requirements are based on the client type
+        and on the authorization server policies.
+
+   (H)  The authorization server authenticates the client and validates
+        the refresh token, and if valid, issues a new access token (and,
+        optionally, a new refresh token).
+
+   Steps (C), (D), (E), and (F) are outside the scope of this
+   specification, as described in Section 7.
+
+1.6.  TLS Version
+
+   Whenever Transport Layer Security (TLS) is used by this
+   specification, the appropriate version (or versions) of TLS will vary
+   over time, based on the widespread deployment and known security
+   vulnerabilities.  At the time of this writing, TLS version 1.2
+   [RFC5246] is the most recent version, but has a very limited
+   deployment base and might not be readily available for
+   implementation.  TLS version 1.0 [RFC2246] is the most widely
+   deployed version and will provide the broadest interoperability.
+
+   Implementations MAY also support additional transport-layer security
+   mechanisms that meet their security requirements.
+
+1.7.  HTTP Redirections
+
+   This specification makes extensive use of HTTP redirections, in which
+   the client or the authorization server directs the resource owner's
+   user-agent to another destination.  While the examples in this
+   specification show the use of the HTTP 302 status code, any other
+   method available via the user-agent to accomplish this redirection is
+   allowed and is considered to be an implementation detail.
+
+1.8.  Interoperability
+
+   OAuth 2.0 provides a rich authorization framework with well-defined
+   security properties.  However, as a rich and highly extensible
+   framework with many optional components, on its own, this
+   specification is likely to produce a wide range of non-interoperable
+   implementations.
+
+   In addition, this specification leaves a few required components
+   partially or fully undefined (e.g., client registration,
+   authorization server capabilities, endpoint discovery).  Without
+
+
+
+
+
+Hardt                        Standards Track                   [Page 12]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   these components, clients must be manually and specifically
+   configured against a specific authorization server and resource
+   server in order to interoperate.
+
+   This framework was designed with the clear expectation that future
+   work will define prescriptive profiles and extensions necessary to
+   achieve full web-scale interoperability.
+
+1.9.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   specification are to be interpreted as described in [RFC2119].
+
+   This specification uses the Augmented Backus-Naur Form (ABNF)
+   notation of [RFC5234].  Additionally, the rule URI-reference is
+   included from "Uniform Resource Identifier (URI): Generic Syntax"
+   [RFC3986].
+
+   Certain security-related terms are to be understood in the sense
+   defined in [RFC4949].  These terms include, but are not limited to,
+   "attack", "authentication", "authorization", "certificate",
+   "confidentiality", "credential", "encryption", "identity", "sign",
+   "signature", "trust", "validate", and "verify".
+
+   Unless otherwise noted, all the protocol parameter names and values
+   are case sensitive.
+
+2.  Client Registration
+
+   Before initiating the protocol, the client registers with the
+   authorization server.  The means through which the client registers
+   with the authorization server are beyond the scope of this
+   specification but typically involve end-user interaction with an HTML
+   registration form.
+
+   Client registration does not require a direct interaction between the
+   client and the authorization server.  When supported by the
+   authorization server, registration can rely on other means for
+   establishing trust and obtaining the required client properties
+   (e.g., redirection URI, client type).  For example, registration can
+   be accomplished using a self-issued or third-party-issued assertion,
+   or by the authorization server performing client discovery using a
+   trusted channel.
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 13]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   When registering a client, the client developer SHALL:
+
+   o  specify the client type as described in Section 2.1,
+
+   o  provide its client redirection URIs as described in Section 3.1.2,
+      and
+
+   o  include any other information required by the authorization server
+      (e.g., application name, website, description, logo image, the
+      acceptance of legal terms).
+
+2.1.  Client Types
+
+   OAuth defines two client types, based on their ability to
+   authenticate securely with the authorization server (i.e., ability to
+   maintain the confidentiality of their client credentials):
+
+   confidential
+      Clients capable of maintaining the confidentiality of their
+      credentials (e.g., client implemented on a secure server with
+      restricted access to the client credentials), or capable of secure
+      client authentication using other means.
+
+   public
+      Clients incapable of maintaining the confidentiality of their
+      credentials (e.g., clients executing on the device used by the
+      resource owner, such as an installed native application or a web
+      browser-based application), and incapable of secure client
+      authentication via any other means.
+
+   The client type designation is based on the authorization server's
+   definition of secure authentication and its acceptable exposure
+   levels of client credentials.  The authorization server SHOULD NOT
+   make assumptions about the client type.
+
+   A client may be implemented as a distributed set of components, each
+   with a different client type and security context (e.g., a
+   distributed client with both a confidential server-based component
+   and a public browser-based component).  If the authorization server
+   does not provide support for such clients or does not provide
+   guidance with regard to their registration, the client SHOULD
+   register each component as a separate client.
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 14]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   This specification has been designed around the following client
+   profiles:
+
+   web application
+      A web application is a confidential client running on a web
+      server.  Resource owners access the client via an HTML user
+      interface rendered in a user-agent on the device used by the
+      resource owner.  The client credentials as well as any access
+      token issued to the client are stored on the web server and are
+      not exposed to or accessible by the resource owner.
+
+   user-agent-based application
+      A user-agent-based application is a public client in which the
+      client code is downloaded from a web server and executes within a
+      user-agent (e.g., web browser) on the device used by the resource
+      owner.  Protocol data and credentials are easily accessible (and
+      often visible) to the resource owner.  Since such applications
+      reside within the user-agent, they can make seamless use of the
+      user-agent capabilities when requesting authorization.
+
+   native application
+      A native application is a public client installed and executed on
+      the device used by the resource owner.  Protocol data and
+      credentials are accessible to the resource owner.  It is assumed
+      that any client authentication credentials included in the
+      application can be extracted.  On the other hand, dynamically
+      issued credentials such as access tokens or refresh tokens can
+      receive an acceptable level of protection.  At a minimum, these
+      credentials are protected from hostile servers with which the
+      application may interact.  On some platforms, these credentials
+      might be protected from other applications residing on the same
+      device.
+
+2.2.  Client Identifier
+
+   The authorization server issues the registered client a client
+   identifier -- a unique string representing the registration
+   information provided by the client.  The client identifier is not a
+   secret; it is exposed to the resource owner and MUST NOT be used
+   alone for client authentication.  The client identifier is unique to
+   the authorization server.
+
+   The client identifier string size is left undefined by this
+   specification.  The client should avoid making assumptions about the
+   identifier size.  The authorization server SHOULD document the size
+   of any identifier it issues.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 15]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+2.3.  Client Authentication
+
+   If the client type is confidential, the client and authorization
+   server establish a client authentication method suitable for the
+   security requirements of the authorization server.  The authorization
+   server MAY accept any form of client authentication meeting its
+   security requirements.
+
+   Confidential clients are typically issued (or establish) a set of
+   client credentials used for authenticating with the authorization
+   server (e.g., password, public/private key pair).
+
+   The authorization server MAY establish a client authentication method
+   with public clients.  However, the authorization server MUST NOT rely
+   on public client authentication for the purpose of identifying the
+   client.
+
+   The client MUST NOT use more than one authentication method in each
+   request.
+
+2.3.1.  Client Password
+
+   Clients in possession of a client password MAY use the HTTP Basic
+   authentication scheme as defined in [RFC2617] to authenticate with
+   the authorization server.  The client identifier is encoded using the
+   "application/x-www-form-urlencoded" encoding algorithm per
+   Appendix B, and the encoded value is used as the username; the client
+   password is encoded using the same algorithm and used as the
+   password.  The authorization server MUST support the HTTP Basic
+   authentication scheme for authenticating clients that were issued a
+   client password.
+
+   For example (with extra line breaks for display purposes only):
+
+     Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
+
+   Alternatively, the authorization server MAY support including the
+   client credentials in the request-body using the following
+   parameters:
+
+   client_id
+         REQUIRED.  The client identifier issued to the client during
+         the registration process described by Section 2.2.
+
+   client_secret
+         REQUIRED.  The client secret.  The client MAY omit the
+         parameter if the client secret is an empty string.
+
+
+
+
+Hardt                        Standards Track                   [Page 16]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Including the client credentials in the request-body using the two
+   parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
+   to directly utilize the HTTP Basic authentication scheme (or other
+   password-based HTTP authentication schemes).  The parameters can only
+   be transmitted in the request-body and MUST NOT be included in the
+   request URI.
+
+   For example, a request to refresh an access token (Section 6) using
+   the body parameters (with extra line breaks for display purposes
+   only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
+     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
+
+   The authorization server MUST require the use of TLS as described in
+   Section 1.6 when sending requests using password authentication.
+
+   Since this client authentication method involves a password, the
+   authorization server MUST protect any endpoint utilizing it against
+   brute force attacks.
+
+2.3.2.  Other Authentication Methods
+
+   The authorization server MAY support any suitable HTTP authentication
+   scheme matching its security requirements.  When using other
+   authentication methods, the authorization server MUST define a
+   mapping between the client identifier (registration record) and
+   authentication scheme.
+
+2.4.  Unregistered Clients
+
+   This specification does not exclude the use of unregistered clients.
+   However, the use of such clients is beyond the scope of this
+   specification and requires additional security analysis and review of
+   its interoperability impact.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 17]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+3.  Protocol Endpoints
+
+   The authorization process utilizes two authorization server endpoints
+   (HTTP resources):
+
+   o  Authorization endpoint - used by the client to obtain
+      authorization from the resource owner via user-agent redirection.
+
+   o  Token endpoint - used by the client to exchange an authorization
+      grant for an access token, typically with client authentication.
+
+   As well as one client endpoint:
+
+   o  Redirection endpoint - used by the authorization server to return
+      responses containing authorization credentials to the client via
+      the resource owner user-agent.
+
+   Not every authorization grant type utilizes both endpoints.
+   Extension grant types MAY define additional endpoints as needed.
+
+3.1.  Authorization Endpoint
+
+   The authorization endpoint is used to interact with the resource
+   owner and obtain an authorization grant.  The authorization server
+   MUST first verify the identity of the resource owner.  The way in
+   which the authorization server authenticates the resource owner
+   (e.g., username and password login, session cookies) is beyond the
+   scope of this specification.
+
+   The means through which the client obtains the location of the
+   authorization endpoint are beyond the scope of this specification,
+   but the location is typically provided in the service documentation.
+
+   The endpoint URI MAY include an "application/x-www-form-urlencoded"
+   formatted (per Appendix B) query component ([RFC3986] Section 3.4),
+   which MUST be retained when adding additional query parameters.  The
+   endpoint URI MUST NOT include a fragment component.
+
+   Since requests to the authorization endpoint result in user
+   authentication and the transmission of clear-text credentials (in the
+   HTTP response), the authorization server MUST require the use of TLS
+   as described in Section 1.6 when sending requests to the
+   authorization endpoint.
+
+   The authorization server MUST support the use of the HTTP "GET"
+   method [RFC2616] for the authorization endpoint and MAY support the
+   use of the "POST" method as well.
+
+
+
+
+Hardt                        Standards Track                   [Page 18]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Parameters sent without a value MUST be treated as if they were
+   omitted from the request.  The authorization server MUST ignore
+   unrecognized request parameters.  Request and response parameters
+   MUST NOT be included more than once.
+
+3.1.1.  Response Type
+
+   The authorization endpoint is used by the authorization code grant
+   type and implicit grant type flows.  The client informs the
+   authorization server of the desired grant type using the following
+   parameter:
+
+   response_type
+         REQUIRED.  The value MUST be one of "code" for requesting an
+         authorization code as described by Section 4.1.1, "token" for
+         requesting an access token (implicit grant) as described by
+         Section 4.2.1, or a registered extension value as described by
+         Section 8.4.
+
+   Extension response types MAY contain a space-delimited (%x20) list of
+   values, where the order of values does not matter (e.g., response
+   type "a b" is the same as "b a").  The meaning of such composite
+   response types is defined by their respective specifications.
+
+   If an authorization request is missing the "response_type" parameter,
+   or if the response type is not understood, the authorization server
+   MUST return an error response as described in Section 4.1.2.1.
+
+3.1.2.  Redirection Endpoint
+
+   After completing its interaction with the resource owner, the
+   authorization server directs the resource owner's user-agent back to
+   the client.  The authorization server redirects the user-agent to the
+   client's redirection endpoint previously established with the
+   authorization server during the client registration process or when
+   making the authorization request.
+
+   The redirection endpoint URI MUST be an absolute URI as defined by
+   [RFC3986] Section 4.3.  The endpoint URI MAY include an
+   "application/x-www-form-urlencoded" formatted (per Appendix B) query
+   component ([RFC3986] Section 3.4), which MUST be retained when adding
+   additional query parameters.  The endpoint URI MUST NOT include a
+   fragment component.
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 19]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+3.1.2.1.  Endpoint Request Confidentiality
+
+   The redirection endpoint SHOULD require the use of TLS as described
+   in Section 1.6 when the requested response type is "code" or "token",
+   or when the redirection request will result in the transmission of
+   sensitive credentials over an open network.  This specification does
+   not mandate the use of TLS because at the time of this writing,
+   requiring clients to deploy TLS is a significant hurdle for many
+   client developers.  If TLS is not available, the authorization server
+   SHOULD warn the resource owner about the insecure endpoint prior to
+   redirection (e.g., display a message during the authorization
+   request).
+
+   Lack of transport-layer security can have a severe impact on the
+   security of the client and the protected resources it is authorized
+   to access.  The use of transport-layer security is particularly
+   critical when the authorization process is used as a form of
+   delegated end-user authentication by the client (e.g., third-party
+   sign-in service).
+
+3.1.2.2.  Registration Requirements
+
+   The authorization server MUST require the following clients to
+   register their redirection endpoint:
+
+   o  Public clients.
+
+   o  Confidential clients utilizing the implicit grant type.
+
+   The authorization server SHOULD require all clients to register their
+   redirection endpoint prior to utilizing the authorization endpoint.
+
+   The authorization server SHOULD require the client to provide the
+   complete redirection URI (the client MAY use the "state" request
+   parameter to achieve per-request customization).  If requiring the
+   registration of the complete redirection URI is not possible, the
+   authorization server SHOULD require the registration of the URI
+   scheme, authority, and path (allowing the client to dynamically vary
+   only the query component of the redirection URI when requesting
+   authorization).
+
+   The authorization server MAY allow the client to register multiple
+   redirection endpoints.
+
+   Lack of a redirection URI registration requirement can enable an
+   attacker to use the authorization endpoint as an open redirector as
+   described in Section 10.15.
+
+
+
+
+Hardt                        Standards Track                   [Page 20]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+3.1.2.3.  Dynamic Configuration
+
+   If multiple redirection URIs have been registered, if only part of
+   the redirection URI has been registered, or if no redirection URI has
+   been registered, the client MUST include a redirection URI with the
+   authorization request using the "redirect_uri" request parameter.
+
+   When a redirection URI is included in an authorization request, the
+   authorization server MUST compare and match the value received
+   against at least one of the registered redirection URIs (or URI
+   components) as defined in [RFC3986] Section 6, if any redirection
+   URIs were registered.  If the client registration included the full
+   redirection URI, the authorization server MUST compare the two URIs
+   using simple string comparison as defined in [RFC3986] Section 6.2.1.
+
+3.1.2.4.  Invalid Endpoint
+
+   If an authorization request fails validation due to a missing,
+   invalid, or mismatching redirection URI, the authorization server
+   SHOULD inform the resource owner of the error and MUST NOT
+   automatically redirect the user-agent to the invalid redirection URI.
+
+3.1.2.5.  Endpoint Content
+
+   The redirection request to the client's endpoint typically results in
+   an HTML document response, processed by the user-agent.  If the HTML
+   response is served directly as the result of the redirection request,
+   any script included in the HTML document will execute with full
+   access to the redirection URI and the credentials it contains.
+
+   The client SHOULD NOT include any third-party scripts (e.g., third-
+   party analytics, social plug-ins, ad networks) in the redirection
+   endpoint response.  Instead, it SHOULD extract the credentials from
+   the URI and redirect the user-agent again to another endpoint without
+   exposing the credentials (in the URI or elsewhere).  If third-party
+   scripts are included, the client MUST ensure that its own scripts
+   (used to extract and remove the credentials from the URI) will
+   execute first.
+
+3.2.  Token Endpoint
+
+   The token endpoint is used by the client to obtain an access token by
+   presenting its authorization grant or refresh token.  The token
+   endpoint is used with every authorization grant except for the
+   implicit grant type (since an access token is issued directly).
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 21]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The means through which the client obtains the location of the token
+   endpoint are beyond the scope of this specification, but the location
+   is typically provided in the service documentation.
+
+   The endpoint URI MAY include an "application/x-www-form-urlencoded"
+   formatted (per Appendix B) query component ([RFC3986] Section 3.4),
+   which MUST be retained when adding additional query parameters.  The
+   endpoint URI MUST NOT include a fragment component.
+
+   Since requests to the token endpoint result in the transmission of
+   clear-text credentials (in the HTTP request and response), the
+   authorization server MUST require the use of TLS as described in
+   Section 1.6 when sending requests to the token endpoint.
+
+   The client MUST use the HTTP "POST" method when making access token
+   requests.
+
+   Parameters sent without a value MUST be treated as if they were
+   omitted from the request.  The authorization server MUST ignore
+   unrecognized request parameters.  Request and response parameters
+   MUST NOT be included more than once.
+
+3.2.1.  Client Authentication
+
+   Confidential clients or other clients issued client credentials MUST
+   authenticate with the authorization server as described in
+   Section 2.3 when making requests to the token endpoint.  Client
+   authentication is used for:
+
+   o  Enforcing the binding of refresh tokens and authorization codes to
+      the client they were issued to.  Client authentication is critical
+      when an authorization code is transmitted to the redirection
+      endpoint over an insecure channel or when the redirection URI has
+      not been registered in full.
+
+   o  Recovering from a compromised client by disabling the client or
+      changing its credentials, thus preventing an attacker from abusing
+      stolen refresh tokens.  Changing a single set of client
+      credentials is significantly faster than revoking an entire set of
+      refresh tokens.
+
+   o  Implementing authentication management best practices, which
+      require periodic credential rotation.  Rotation of an entire set
+      of refresh tokens can be challenging, while rotation of a single
+      set of client credentials is significantly easier.
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 22]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   A client MAY use the "client_id" request parameter to identify itself
+   when sending requests to the token endpoint.  In the
+   "authorization_code" "grant_type" request to the token endpoint, an
+   unauthenticated client MUST send its "client_id" to prevent itself
+   from inadvertently accepting a code intended for a client with a
+   different "client_id".  This protects the client from substitution of
+   the authentication code.  (It provides no additional security for the
+   protected resource.)
+
+3.3.  Access Token Scope
+
+   The authorization and token endpoints allow the client to specify the
+   scope of the access request using the "scope" request parameter.  In
+   turn, the authorization server uses the "scope" response parameter to
+   inform the client of the scope of the access token issued.
+
+   The value of the scope parameter is expressed as a list of space-
+   delimited, case-sensitive strings.  The strings are defined by the
+   authorization server.  If the value contains multiple space-delimited
+   strings, their order does not matter, and each string adds an
+   additional access range to the requested scope.
+
+     scope       = scope-token *( SP scope-token )
+     scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
+
+   The authorization server MAY fully or partially ignore the scope
+   requested by the client, based on the authorization server policy or
+   the resource owner's instructions.  If the issued access token scope
+   is different from the one requested by the client, the authorization
+   server MUST include the "scope" response parameter to inform the
+   client of the actual scope granted.
+
+   If the client omits the scope parameter when requesting
+   authorization, the authorization server MUST either process the
+   request using a pre-defined default value or fail the request
+   indicating an invalid scope.  The authorization server SHOULD
+   document its scope requirements and default value (if defined).
+
+4.  Obtaining Authorization
+
+   To request an access token, the client obtains authorization from the
+   resource owner.  The authorization is expressed in the form of an
+   authorization grant, which the client uses to request the access
+   token.  OAuth defines four grant types: authorization code, implicit,
+   resource owner password credentials, and client credentials.  It also
+   provides an extension mechanism for defining additional grant types.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 23]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+4.1.  Authorization Code Grant
+
+   The authorization code grant type is used to obtain both access
+   tokens and refresh tokens and is optimized for confidential clients.
+   Since this is a redirection-based flow, the client must be capable of
+   interacting with the resource owner's user-agent (typically a web
+   browser) and capable of receiving incoming requests (via redirection)
+   from the authorization server.
+
+     +----------+
+     | Resource |
+     |   Owner  |
+     |          |
+     +----------+
+          ^
+          |
+         (B)
+     +----|-----+          Client Identifier      +---------------+
+     |         -+----(A)-- & Redirection URI ---->|               |
+     |  User-   |                                 | Authorization |
+     |  Agent  -+----(B)-- User authenticates --->|     Server    |
+     |          |                                 |               |
+     |         -+----(C)-- Authorization Code ---<|               |
+     +-|----|---+                                 +---------------+
+       |    |                                         ^      v
+      (A)  (C)                                        |      |
+       |    |                                         |      |
+       ^    v                                         |      |
+     +---------+                                      |      |
+     |         |>---(D)-- Authorization Code ---------'      |
+     |  Client |          & Redirection URI                  |
+     |         |                                             |
+     |         |<---(E)----- Access Token -------------------'
+     +---------+       (w/ Optional Refresh Token)
+
+   Note: The lines illustrating steps (A), (B), and (C) are broken into
+   two parts as they pass through the user-agent.
+
+                     Figure 3: Authorization Code Flow
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 24]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The flow illustrated in Figure 3 includes the following steps:
+
+   (A)  The client initiates the flow by directing the resource owner's
+        user-agent to the authorization endpoint.  The client includes
+        its client identifier, requested scope, local state, and a
+        redirection URI to which the authorization server will send the
+        user-agent back once access is granted (or denied).
+
+   (B)  The authorization server authenticates the resource owner (via
+        the user-agent) and establishes whether the resource owner
+        grants or denies the client's access request.
+
+   (C)  Assuming the resource owner grants access, the authorization
+        server redirects the user-agent back to the client using the
+        redirection URI provided earlier (in the request or during
+        client registration).  The redirection URI includes an
+        authorization code and any local state provided by the client
+        earlier.
+
+   (D)  The client requests an access token from the authorization
+        server's token endpoint by including the authorization code
+        received in the previous step.  When making the request, the
+        client authenticates with the authorization server.  The client
+        includes the redirection URI used to obtain the authorization
+        code for verification.
+
+   (E)  The authorization server authenticates the client, validates the
+        authorization code, and ensures that the redirection URI
+        received matches the URI used to redirect the client in
+        step (C).  If valid, the authorization server responds back with
+        an access token and, optionally, a refresh token.
+
+4.1.1.  Authorization Request
+
+   The client constructs the request URI by adding the following
+   parameters to the query component of the authorization endpoint URI
+   using the "application/x-www-form-urlencoded" format, per Appendix B:
+
+   response_type
+         REQUIRED.  Value MUST be set to "code".
+
+   client_id
+         REQUIRED.  The client identifier as described in Section 2.2.
+
+   redirect_uri
+         OPTIONAL.  As described in Section 3.1.2.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 25]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   scope
+         OPTIONAL.  The scope of the access request as described by
+         Section 3.3.
+
+   state
+         RECOMMENDED.  An opaque value used by the client to maintain
+         state between the request and callback.  The authorization
+         server includes this value when redirecting the user-agent back
+         to the client.  The parameter SHOULD be used for preventing
+         cross-site request forgery as described in Section 10.12.
+
+   The client directs the resource owner to the constructed URI using an
+   HTTP redirection response, or by other means available to it via the
+   user-agent.
+
+   For example, the client directs the user-agent to make the following
+   HTTP request using TLS (with extra line breaks for display purposes
+   only):
+
+    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
+        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
+    Host: server.example.com
+
+   The authorization server validates the request to ensure that all
+   required parameters are present and valid.  If the request is valid,
+   the authorization server authenticates the resource owner and obtains
+   an authorization decision (by asking the resource owner or by
+   establishing approval via other means).
+
+   When a decision is established, the authorization server directs the
+   user-agent to the provided client redirection URI using an HTTP
+   redirection response, or by other means available to it via the
+   user-agent.
+
+4.1.2.  Authorization Response
+
+   If the resource owner grants the access request, the authorization
+   server issues an authorization code and delivers it to the client by
+   adding the following parameters to the query component of the
+   redirection URI using the "application/x-www-form-urlencoded" format,
+   per Appendix B:
+
+   code
+         REQUIRED.  The authorization code generated by the
+         authorization server.  The authorization code MUST expire
+         shortly after it is issued to mitigate the risk of leaks.  A
+         maximum authorization code lifetime of 10 minutes is
+         RECOMMENDED.  The client MUST NOT use the authorization code
+
+
+
+Hardt                        Standards Track                   [Page 26]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+         more than once.  If an authorization code is used more than
+         once, the authorization server MUST deny the request and SHOULD
+         revoke (when possible) all tokens previously issued based on
+         that authorization code.  The authorization code is bound to
+         the client identifier and redirection URI.
+
+   state
+         REQUIRED if the "state" parameter was present in the client
+         authorization request.  The exact value received from the
+         client.
+
+   For example, the authorization server redirects the user-agent by
+   sending the following HTTP response:
+
+     HTTP/1.1 302 Found
+     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
+               &state=xyz
+
+   The client MUST ignore unrecognized response parameters.  The
+   authorization code string size is left undefined by this
+   specification.  The client should avoid making assumptions about code
+   value sizes.  The authorization server SHOULD document the size of
+   any value it issues.
+
+4.1.2.1.  Error Response
+
+   If the request fails due to a missing, invalid, or mismatching
+   redirection URI, or if the client identifier is missing or invalid,
+   the authorization server SHOULD inform the resource owner of the
+   error and MUST NOT automatically redirect the user-agent to the
+   invalid redirection URI.
+
+   If the resource owner denies the access request or if the request
+   fails for reasons other than a missing or invalid redirection URI,
+   the authorization server informs the client by adding the following
+   parameters to the query component of the redirection URI using the
+   "application/x-www-form-urlencoded" format, per Appendix B:
+
+   error
+         REQUIRED.  A single ASCII [USASCII] error code from the
+         following:
+
+         invalid_request
+               The request is missing a required parameter, includes an
+               invalid parameter value, includes a parameter more than
+               once, or is otherwise malformed.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 27]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+         unauthorized_client
+               The client is not authorized to request an authorization
+               code using this method.
+
+         access_denied
+               The resource owner or authorization server denied the
+               request.
+
+         unsupported_response_type
+               The authorization server does not support obtaining an
+               authorization code using this method.
+
+         invalid_scope
+               The requested scope is invalid, unknown, or malformed.
+
+         server_error
+               The authorization server encountered an unexpected
+               condition that prevented it from fulfilling the request.
+               (This error code is needed because a 500 Internal Server
+               Error HTTP status code cannot be returned to the client
+               via an HTTP redirect.)
+
+         temporarily_unavailable
+               The authorization server is currently unable to handle
+               the request due to a temporary overloading or maintenance
+               of the server.  (This error code is needed because a 503
+               Service Unavailable HTTP status code cannot be returned
+               to the client via an HTTP redirect.)
+
+         Values for the "error" parameter MUST NOT include characters
+         outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_description
+         OPTIONAL.  Human-readable ASCII [USASCII] text providing
+         additional information, used to assist the client developer in
+         understanding the error that occurred.
+         Values for the "error_description" parameter MUST NOT include
+         characters outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_uri
+         OPTIONAL.  A URI identifying a human-readable web page with
+         information about the error, used to provide the client
+         developer with additional information about the error.
+         Values for the "error_uri" parameter MUST conform to the
+         URI-reference syntax and thus MUST NOT include characters
+         outside the set %x21 / %x23-5B / %x5D-7E.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 28]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   state
+         REQUIRED if a "state" parameter was present in the client
+         authorization request.  The exact value received from the
+         client.
+
+   For example, the authorization server redirects the user-agent by
+   sending the following HTTP response:
+
+   HTTP/1.1 302 Found
+   Location: https://client.example.com/cb?error=access_denied&state=xyz
+
+4.1.3.  Access Token Request
+
+   The client makes a request to the token endpoint by sending the
+   following parameters using the "application/x-www-form-urlencoded"
+   format per Appendix B with a character encoding of UTF-8 in the HTTP
+   request entity-body:
+
+   grant_type
+         REQUIRED.  Value MUST be set to "authorization_code".
+
+   code
+         REQUIRED.  The authorization code received from the
+         authorization server.
+
+   redirect_uri
+         REQUIRED, if the "redirect_uri" parameter was included in the
+         authorization request as described in Section 4.1.1, and their
+         values MUST be identical.
+
+   client_id
+         REQUIRED, if the client is not authenticating with the
+         authorization server as described in Section 3.2.1.
+
+   If the client type is confidential or the client was issued client
+   credentials (or assigned other authentication requirements), the
+   client MUST authenticate with the authorization server as described
+   in Section 3.2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 29]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   For example, the client makes the following HTTP request using TLS
+   (with extra line breaks for display purposes only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
+     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
+
+   The authorization server MUST:
+
+   o  require client authentication for confidential clients or for any
+      client that was issued client credentials (or with other
+      authentication requirements),
+
+   o  authenticate the client if client authentication is included,
+
+   o  ensure that the authorization code was issued to the authenticated
+      confidential client, or if the client is public, ensure that the
+      code was issued to "client_id" in the request,
+
+   o  verify that the authorization code is valid, and
+
+   o  ensure that the "redirect_uri" parameter is present if the
+      "redirect_uri" parameter was included in the initial authorization
+      request as described in Section 4.1.1, and if included ensure that
+      their values are identical.
+
+4.1.4.  Access Token Response
+
+   If the access token request is valid and authorized, the
+   authorization server issues an access token and optional refresh
+   token as described in Section 5.1.  If the request client
+   authentication failed or is invalid, the authorization server returns
+   an error response as described in Section 5.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 30]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   An example successful response:
+
+     HTTP/1.1 200 OK
+     Content-Type: application/json;charset=UTF-8
+     Cache-Control: no-store
+     Pragma: no-cache
+
+     {
+       "access_token":"2YotnFZFEjr1zCsicMWpAA",
+       "token_type":"example",
+       "expires_in":3600,
+       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
+       "example_parameter":"example_value"
+     }
+
+4.2.  Implicit Grant
+
+   The implicit grant type is used to obtain access tokens (it does not
+   support the issuance of refresh tokens) and is optimized for public
+   clients known to operate a particular redirection URI.  These clients
+   are typically implemented in a browser using a scripting language
+   such as JavaScript.
+
+   Since this is a redirection-based flow, the client must be capable of
+   interacting with the resource owner's user-agent (typically a web
+   browser) and capable of receiving incoming requests (via redirection)
+   from the authorization server.
+
+   Unlike the authorization code grant type, in which the client makes
+   separate requests for authorization and for an access token, the
+   client receives the access token as the result of the authorization
+   request.
+
+   The implicit grant type does not include client authentication, and
+   relies on the presence of the resource owner and the registration of
+   the redirection URI.  Because the access token is encoded into the
+   redirection URI, it may be exposed to the resource owner and other
+   applications residing on the same device.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 31]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+     +----------+
+     | Resource |
+     |  Owner   |
+     |          |
+     +----------+
+          ^
+          |
+         (B)
+     +----|-----+          Client Identifier     +---------------+
+     |         -+----(A)-- & Redirection URI --->|               |
+     |  User-   |                                | Authorization |
+     |  Agent  -|----(B)-- User authenticates -->|     Server    |
+     |          |                                |               |
+     |          |<---(C)--- Redirection URI ----<|               |
+     |          |          with Access Token     +---------------+
+     |          |            in Fragment
+     |          |                                +---------------+
+     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
+     |          |          without Fragment      |     Client    |
+     |          |                                |    Resource   |
+     |     (F)  |<---(E)------- Script ---------<|               |
+     |          |                                +---------------+
+     +-|--------+
+       |    |
+      (A)  (G) Access Token
+       |    |
+       ^    v
+     +---------+
+     |         |
+     |  Client |
+     |         |
+     +---------+
+
+   Note: The lines illustrating steps (A) and (B) are broken into two
+   parts as they pass through the user-agent.
+
+                       Figure 4: Implicit Grant Flow
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 32]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The flow illustrated in Figure 4 includes the following steps:
+
+   (A)  The client initiates the flow by directing the resource owner's
+        user-agent to the authorization endpoint.  The client includes
+        its client identifier, requested scope, local state, and a
+        redirection URI to which the authorization server will send the
+        user-agent back once access is granted (or denied).
+
+   (B)  The authorization server authenticates the resource owner (via
+        the user-agent) and establishes whether the resource owner
+        grants or denies the client's access request.
+
+   (C)  Assuming the resource owner grants access, the authorization
+        server redirects the user-agent back to the client using the
+        redirection URI provided earlier.  The redirection URI includes
+        the access token in the URI fragment.
+
+   (D)  The user-agent follows the redirection instructions by making a
+        request to the web-hosted client resource (which does not
+        include the fragment per [RFC2616]).  The user-agent retains the
+        fragment information locally.
+
+   (E)  The web-hosted client resource returns a web page (typically an
+        HTML document with an embedded script) capable of accessing the
+        full redirection URI including the fragment retained by the
+        user-agent, and extracting the access token (and other
+        parameters) contained in the fragment.
+
+   (F)  The user-agent executes the script provided by the web-hosted
+        client resource locally, which extracts the access token.
+
+   (G)  The user-agent passes the access token to the client.
+
+   See Sections 1.3.2 and 9 for background on using the implicit grant.
+   See Sections 10.3 and 10.16 for important security considerations
+   when using the implicit grant.
+
+4.2.1.  Authorization Request
+
+   The client constructs the request URI by adding the following
+   parameters to the query component of the authorization endpoint URI
+   using the "application/x-www-form-urlencoded" format, per Appendix B:
+
+   response_type
+         REQUIRED.  Value MUST be set to "token".
+
+   client_id
+         REQUIRED.  The client identifier as described in Section 2.2.
+
+
+
+Hardt                        Standards Track                   [Page 33]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   redirect_uri
+         OPTIONAL.  As described in Section 3.1.2.
+
+   scope
+         OPTIONAL.  The scope of the access request as described by
+         Section 3.3.
+
+   state
+         RECOMMENDED.  An opaque value used by the client to maintain
+         state between the request and callback.  The authorization
+         server includes this value when redirecting the user-agent back
+         to the client.  The parameter SHOULD be used for preventing
+         cross-site request forgery as described in Section 10.12.
+
+   The client directs the resource owner to the constructed URI using an
+   HTTP redirection response, or by other means available to it via the
+   user-agent.
+
+   For example, the client directs the user-agent to make the following
+   HTTP request using TLS (with extra line breaks for display purposes
+   only):
+
+    GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
+        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
+    Host: server.example.com
+
+   The authorization server validates the request to ensure that all
+   required parameters are present and valid.  The authorization server
+   MUST verify that the redirection URI to which it will redirect the
+   access token matches a redirection URI registered by the client as
+   described in Section 3.1.2.
+
+   If the request is valid, the authorization server authenticates the
+   resource owner and obtains an authorization decision (by asking the
+   resource owner or by establishing approval via other means).
+
+   When a decision is established, the authorization server directs the
+   user-agent to the provided client redirection URI using an HTTP
+   redirection response, or by other means available to it via the
+   user-agent.
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 34]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+4.2.2.  Access Token Response
+
+   If the resource owner grants the access request, the authorization
+   server issues an access token and delivers it to the client by adding
+   the following parameters to the fragment component of the redirection
+   URI using the "application/x-www-form-urlencoded" format, per
+   Appendix B:
+
+   access_token
+         REQUIRED.  The access token issued by the authorization server.
+
+   token_type
+         REQUIRED.  The type of the token issued as described in
+         Section 7.1.  Value is case insensitive.
+
+   expires_in
+         RECOMMENDED.  The lifetime in seconds of the access token.  For
+         example, the value "3600" denotes that the access token will
+         expire in one hour from the time the response was generated.
+         If omitted, the authorization server SHOULD provide the
+         expiration time via other means or document the default value.
+
+   scope
+         OPTIONAL, if identical to the scope requested by the client;
+         otherwise, REQUIRED.  The scope of the access token as
+         described by Section 3.3.
+
+   state
+         REQUIRED if the "state" parameter was present in the client
+         authorization request.  The exact value received from the
+         client.
+
+   The authorization server MUST NOT issue a refresh token.
+
+   For example, the authorization server redirects the user-agent by
+   sending the following HTTP response (with extra line breaks for
+   display purposes only):
+
+     HTTP/1.1 302 Found
+     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
+               &state=xyz&token_type=example&expires_in=3600
+
+   Developers should note that some user-agents do not support the
+   inclusion of a fragment component in the HTTP "Location" response
+   header field.  Such clients will require using other methods for
+   redirecting the client than a 3xx redirection response -- for
+   example, returning an HTML page that includes a 'continue' button
+   with an action linked to the redirection URI.
+
+
+
+Hardt                        Standards Track                   [Page 35]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The client MUST ignore unrecognized response parameters.  The access
+   token string size is left undefined by this specification.  The
+   client should avoid making assumptions about value sizes.  The
+   authorization server SHOULD document the size of any value it issues.
+
+4.2.2.1.  Error Response
+
+   If the request fails due to a missing, invalid, or mismatching
+   redirection URI, or if the client identifier is missing or invalid,
+   the authorization server SHOULD inform the resource owner of the
+   error and MUST NOT automatically redirect the user-agent to the
+   invalid redirection URI.
+
+   If the resource owner denies the access request or if the request
+   fails for reasons other than a missing or invalid redirection URI,
+   the authorization server informs the client by adding the following
+   parameters to the fragment component of the redirection URI using the
+   "application/x-www-form-urlencoded" format, per Appendix B:
+
+   error
+         REQUIRED.  A single ASCII [USASCII] error code from the
+         following:
+
+         invalid_request
+               The request is missing a required parameter, includes an
+               invalid parameter value, includes a parameter more than
+               once, or is otherwise malformed.
+
+         unauthorized_client
+               The client is not authorized to request an access token
+               using this method.
+
+         access_denied
+               The resource owner or authorization server denied the
+               request.
+
+         unsupported_response_type
+               The authorization server does not support obtaining an
+               access token using this method.
+
+         invalid_scope
+               The requested scope is invalid, unknown, or malformed.
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 36]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+         server_error
+               The authorization server encountered an unexpected
+               condition that prevented it from fulfilling the request.
+               (This error code is needed because a 500 Internal Server
+               Error HTTP status code cannot be returned to the client
+               via an HTTP redirect.)
+
+         temporarily_unavailable
+               The authorization server is currently unable to handle
+               the request due to a temporary overloading or maintenance
+               of the server.  (This error code is needed because a 503
+               Service Unavailable HTTP status code cannot be returned
+               to the client via an HTTP redirect.)
+
+         Values for the "error" parameter MUST NOT include characters
+         outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_description
+         OPTIONAL.  Human-readable ASCII [USASCII] text providing
+         additional information, used to assist the client developer in
+         understanding the error that occurred.
+         Values for the "error_description" parameter MUST NOT include
+         characters outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_uri
+         OPTIONAL.  A URI identifying a human-readable web page with
+         information about the error, used to provide the client
+         developer with additional information about the error.
+         Values for the "error_uri" parameter MUST conform to the
+         URI-reference syntax and thus MUST NOT include characters
+         outside the set %x21 / %x23-5B / %x5D-7E.
+
+   state
+         REQUIRED if a "state" parameter was present in the client
+         authorization request.  The exact value received from the
+         client.
+
+   For example, the authorization server redirects the user-agent by
+   sending the following HTTP response:
+
+   HTTP/1.1 302 Found
+   Location: https://client.example.com/cb#error=access_denied&state=xyz
+
+4.3.  Resource Owner Password Credentials Grant
+
+   The resource owner password credentials grant type is suitable in
+   cases where the resource owner has a trust relationship with the
+   client, such as the device operating system or a highly privileged
+
+
+
+Hardt                        Standards Track                   [Page 37]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   application.  The authorization server should take special care when
+   enabling this grant type and only allow it when other flows are not
+   viable.
+
+   This grant type is suitable for clients capable of obtaining the
+   resource owner's credentials (username and password, typically using
+   an interactive form).  It is also used to migrate existing clients
+   using direct authentication schemes such as HTTP Basic or Digest
+   authentication to OAuth by converting the stored credentials to an
+   access token.
+
+     +----------+
+     | Resource |
+     |  Owner   |
+     |          |
+     +----------+
+          v
+          |    Resource Owner
+         (A) Password Credentials
+          |
+          v
+     +---------+                                  +---------------+
+     |         |>--(B)---- Resource Owner ------->|               |
+     |         |         Password Credentials     | Authorization |
+     | Client  |                                  |     Server    |
+     |         |<--(C)---- Access Token ---------<|               |
+     |         |    (w/ Optional Refresh Token)   |               |
+     +---------+                                  +---------------+
+
+            Figure 5: Resource Owner Password Credentials Flow
+
+   The flow illustrated in Figure 5 includes the following steps:
+
+   (A)  The resource owner provides the client with its username and
+        password.
+
+   (B)  The client requests an access token from the authorization
+        server's token endpoint by including the credentials received
+        from the resource owner.  When making the request, the client
+        authenticates with the authorization server.
+
+   (C)  The authorization server authenticates the client and validates
+        the resource owner credentials, and if valid, issues an access
+        token.
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 38]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+4.3.1.  Authorization Request and Response
+
+   The method through which the client obtains the resource owner
+   credentials is beyond the scope of this specification.  The client
+   MUST discard the credentials once an access token has been obtained.
+
+4.3.2.  Access Token Request
+
+   The client makes a request to the token endpoint by adding the
+   following parameters using the "application/x-www-form-urlencoded"
+   format per Appendix B with a character encoding of UTF-8 in the HTTP
+   request entity-body:
+
+   grant_type
+         REQUIRED.  Value MUST be set to "password".
+
+   username
+         REQUIRED.  The resource owner username.
+
+   password
+         REQUIRED.  The resource owner password.
+
+   scope
+         OPTIONAL.  The scope of the access request as described by
+         Section 3.3.
+
+   If the client type is confidential or the client was issued client
+   credentials (or assigned other authentication requirements), the
+   client MUST authenticate with the authorization server as described
+   in Section 3.2.1.
+
+   For example, the client makes the following HTTP request using
+   transport-layer security (with extra line breaks for display purposes
+   only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=password&username=johndoe&password=A3ddj3w
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 39]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The authorization server MUST:
+
+   o  require client authentication for confidential clients or for any
+      client that was issued client credentials (or with other
+      authentication requirements),
+
+   o  authenticate the client if client authentication is included, and
+
+   o  validate the resource owner password credentials using its
+      existing password validation algorithm.
+
+   Since this access token request utilizes the resource owner's
+   password, the authorization server MUST protect the endpoint against
+   brute force attacks (e.g., using rate-limitation or generating
+   alerts).
+
+4.3.3.  Access Token Response
+
+   If the access token request is valid and authorized, the
+   authorization server issues an access token and optional refresh
+   token as described in Section 5.1.  If the request failed client
+   authentication or is invalid, the authorization server returns an
+   error response as described in Section 5.2.
+
+   An example successful response:
+
+     HTTP/1.1 200 OK
+     Content-Type: application/json;charset=UTF-8
+     Cache-Control: no-store
+     Pragma: no-cache
+
+     {
+       "access_token":"2YotnFZFEjr1zCsicMWpAA",
+       "token_type":"example",
+       "expires_in":3600,
+       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
+       "example_parameter":"example_value"
+     }
+
+4.4.  Client Credentials Grant
+
+   The client can request an access token using only its client
+   credentials (or other supported means of authentication) when the
+   client is requesting access to the protected resources under its
+   control, or those of another resource owner that have been previously
+   arranged with the authorization server (the method of which is beyond
+   the scope of this specification).
+
+
+
+
+Hardt                        Standards Track                   [Page 40]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The client credentials grant type MUST only be used by confidential
+   clients.
+
+     +---------+                                  +---------------+
+     |         |                                  |               |
+     |         |>--(A)- Client Authentication --->| Authorization |
+     | Client  |                                  |     Server    |
+     |         |<--(B)---- Access Token ---------<|               |
+     |         |                                  |               |
+     +---------+                                  +---------------+
+
+                     Figure 6: Client Credentials Flow
+
+   The flow illustrated in Figure 6 includes the following steps:
+
+   (A)  The client authenticates with the authorization server and
+        requests an access token from the token endpoint.
+
+   (B)  The authorization server authenticates the client, and if valid,
+        issues an access token.
+
+4.4.1.  Authorization Request and Response
+
+   Since the client authentication is used as the authorization grant,
+   no additional authorization request is needed.
+
+4.4.2.  Access Token Request
+
+   The client makes a request to the token endpoint by adding the
+   following parameters using the "application/x-www-form-urlencoded"
+   format per Appendix B with a character encoding of UTF-8 in the HTTP
+   request entity-body:
+
+   grant_type
+         REQUIRED.  Value MUST be set to "client_credentials".
+
+   scope
+         OPTIONAL.  The scope of the access request as described by
+         Section 3.3.
+
+   The client MUST authenticate with the authorization server as
+   described in Section 3.2.1.
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 41]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   For example, the client makes the following HTTP request using
+   transport-layer security (with extra line breaks for display purposes
+   only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=client_credentials
+
+   The authorization server MUST authenticate the client.
+
+4.4.3.  Access Token Response
+
+   If the access token request is valid and authorized, the
+   authorization server issues an access token as described in
+   Section 5.1.  A refresh token SHOULD NOT be included.  If the request
+   failed client authentication or is invalid, the authorization server
+   returns an error response as described in Section 5.2.
+
+   An example successful response:
+
+     HTTP/1.1 200 OK
+     Content-Type: application/json;charset=UTF-8
+     Cache-Control: no-store
+     Pragma: no-cache
+
+     {
+       "access_token":"2YotnFZFEjr1zCsicMWpAA",
+       "token_type":"example",
+       "expires_in":3600,
+       "example_parameter":"example_value"
+     }
+
+4.5.  Extension Grants
+
+   The client uses an extension grant type by specifying the grant type
+   using an absolute URI (defined by the authorization server) as the
+   value of the "grant_type" parameter of the token endpoint, and by
+   adding any additional parameters necessary.
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 42]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   For example, to request an access token using a Security Assertion
+   Markup Language (SAML) 2.0 assertion grant type as defined by
+   [OAuth-SAML2], the client could make the following HTTP request using
+   TLS (with extra line breaks for display purposes only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
+     bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
+     [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
+
+   If the access token request is valid and authorized, the
+   authorization server issues an access token and optional refresh
+   token as described in Section 5.1.  If the request failed client
+   authentication or is invalid, the authorization server returns an
+   error response as described in Section 5.2.
+
+5.  Issuing an Access Token
+
+   If the access token request is valid and authorized, the
+   authorization server issues an access token and optional refresh
+   token as described in Section 5.1.  If the request failed client
+   authentication or is invalid, the authorization server returns an
+   error response as described in Section 5.2.
+
+5.1.  Successful Response
+
+   The authorization server issues an access token and optional refresh
+   token, and constructs the response by adding the following parameters
+   to the entity-body of the HTTP response with a 200 (OK) status code:
+
+   access_token
+         REQUIRED.  The access token issued by the authorization server.
+
+   token_type
+         REQUIRED.  The type of the token issued as described in
+         Section 7.1.  Value is case insensitive.
+
+   expires_in
+         RECOMMENDED.  The lifetime in seconds of the access token.  For
+         example, the value "3600" denotes that the access token will
+         expire in one hour from the time the response was generated.
+         If omitted, the authorization server SHOULD provide the
+         expiration time via other means or document the default value.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 43]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   refresh_token
+         OPTIONAL.  The refresh token, which can be used to obtain new
+         access tokens using the same authorization grant as described
+         in Section 6.
+
+   scope
+         OPTIONAL, if identical to the scope requested by the client;
+         otherwise, REQUIRED.  The scope of the access token as
+         described by Section 3.3.
+
+   The parameters are included in the entity-body of the HTTP response
+   using the "application/json" media type as defined by [RFC4627].  The
+   parameters are serialized into a JavaScript Object Notation (JSON)
+   structure by adding each parameter at the highest structure level.
+   Parameter names and string values are included as JSON strings.
+   Numerical values are included as JSON numbers.  The order of
+   parameters does not matter and can vary.
+
+   The authorization server MUST include the HTTP "Cache-Control"
+   response header field [RFC2616] with a value of "no-store" in any
+   response containing tokens, credentials, or other sensitive
+   information, as well as the "Pragma" response header field [RFC2616]
+   with a value of "no-cache".
+
+   For example:
+
+     HTTP/1.1 200 OK
+     Content-Type: application/json;charset=UTF-8
+     Cache-Control: no-store
+     Pragma: no-cache
+
+     {
+       "access_token":"2YotnFZFEjr1zCsicMWpAA",
+       "token_type":"example",
+       "expires_in":3600,
+       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
+       "example_parameter":"example_value"
+     }
+
+   The client MUST ignore unrecognized value names in the response.  The
+   sizes of tokens and other values received from the authorization
+   server are left undefined.  The client should avoid making
+   assumptions about value sizes.  The authorization server SHOULD
+   document the size of any value it issues.
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 44]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+5.2.  Error Response
+
+   The authorization server responds with an HTTP 400 (Bad Request)
+   status code (unless specified otherwise) and includes the following
+   parameters with the response:
+
+   error
+         REQUIRED.  A single ASCII [USASCII] error code from the
+         following:
+
+         invalid_request
+               The request is missing a required parameter, includes an
+               unsupported parameter value (other than grant type),
+               repeats a parameter, includes multiple credentials,
+               utilizes more than one mechanism for authenticating the
+               client, or is otherwise malformed.
+
+         invalid_client
+               Client authentication failed (e.g., unknown client, no
+               client authentication included, or unsupported
+               authentication method).  The authorization server MAY
+               return an HTTP 401 (Unauthorized) status code to indicate
+               which HTTP authentication schemes are supported.  If the
+               client attempted to authenticate via the "Authorization"
+               request header field, the authorization server MUST
+               respond with an HTTP 401 (Unauthorized) status code and
+               include the "WWW-Authenticate" response header field
+               matching the authentication scheme used by the client.
+
+         invalid_grant
+               The provided authorization grant (e.g., authorization
+               code, resource owner credentials) or refresh token is
+               invalid, expired, revoked, does not match the redirection
+               URI used in the authorization request, or was issued to
+               another client.
+
+         unauthorized_client
+               The authenticated client is not authorized to use this
+               authorization grant type.
+
+         unsupported_grant_type
+               The authorization grant type is not supported by the
+               authorization server.
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 45]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+         invalid_scope
+               The requested scope is invalid, unknown, malformed, or
+               exceeds the scope granted by the resource owner.
+
+         Values for the "error" parameter MUST NOT include characters
+         outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_description
+         OPTIONAL.  Human-readable ASCII [USASCII] text providing
+         additional information, used to assist the client developer in
+         understanding the error that occurred.
+         Values for the "error_description" parameter MUST NOT include
+         characters outside the set %x20-21 / %x23-5B / %x5D-7E.
+
+   error_uri
+         OPTIONAL.  A URI identifying a human-readable web page with
+         information about the error, used to provide the client
+         developer with additional information about the error.
+         Values for the "error_uri" parameter MUST conform to the
+         URI-reference syntax and thus MUST NOT include characters
+         outside the set %x21 / %x23-5B / %x5D-7E.
+
+   The parameters are included in the entity-body of the HTTP response
+   using the "application/json" media type as defined by [RFC4627].  The
+   parameters are serialized into a JSON structure by adding each
+   parameter at the highest structure level.  Parameter names and string
+   values are included as JSON strings.  Numerical values are included
+   as JSON numbers.  The order of parameters does not matter and can
+   vary.
+
+   For example:
+
+     HTTP/1.1 400 Bad Request
+     Content-Type: application/json;charset=UTF-8
+     Cache-Control: no-store
+     Pragma: no-cache
+
+     {
+       "error":"invalid_request"
+     }
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 46]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+6.  Refreshing an Access Token
+
+   If the authorization server issued a refresh token to the client, the
+   client makes a refresh request to the token endpoint by adding the
+   following parameters using the "application/x-www-form-urlencoded"
+   format per Appendix B with a character encoding of UTF-8 in the HTTP
+   request entity-body:
+
+   grant_type
+         REQUIRED.  Value MUST be set to "refresh_token".
+
+   refresh_token
+         REQUIRED.  The refresh token issued to the client.
+
+   scope
+         OPTIONAL.  The scope of the access request as described by
+         Section 3.3.  The requested scope MUST NOT include any scope
+         not originally granted by the resource owner, and if omitted is
+         treated as equal to the scope originally granted by the
+         resource owner.
+
+   Because refresh tokens are typically long-lasting credentials used to
+   request additional access tokens, the refresh token is bound to the
+   client to which it was issued.  If the client type is confidential or
+   the client was issued client credentials (or assigned other
+   authentication requirements), the client MUST authenticate with the
+   authorization server as described in Section 3.2.1.
+
+   For example, the client makes the following HTTP request using
+   transport-layer security (with extra line breaks for display purposes
+   only):
+
+     POST /token HTTP/1.1
+     Host: server.example.com
+     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
+     Content-Type: application/x-www-form-urlencoded
+
+     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 47]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The authorization server MUST:
+
+   o  require client authentication for confidential clients or for any
+      client that was issued client credentials (or with other
+      authentication requirements),
+
+   o  authenticate the client if client authentication is included and
+      ensure that the refresh token was issued to the authenticated
+      client, and
+
+   o  validate the refresh token.
+
+   If valid and authorized, the authorization server issues an access
+   token as described in Section 5.1.  If the request failed
+   verification or is invalid, the authorization server returns an error
+   response as described in Section 5.2.
+
+   The authorization server MAY issue a new refresh token, in which case
+   the client MUST discard the old refresh token and replace it with the
+   new refresh token.  The authorization server MAY revoke the old
+   refresh token after issuing a new refresh token to the client.  If a
+   new refresh token is issued, the refresh token scope MUST be
+   identical to that of the refresh token included by the client in the
+   request.
+
+7.  Accessing Protected Resources
+
+   The client accesses protected resources by presenting the access
+   token to the resource server.  The resource server MUST validate the
+   access token and ensure that it has not expired and that its scope
+   covers the requested resource.  The methods used by the resource
+   server to validate the access token (as well as any error responses)
+   are beyond the scope of this specification but generally involve an
+   interaction or coordination between the resource server and the
+   authorization server.
+
+   The method in which the client utilizes the access token to
+   authenticate with the resource server depends on the type of access
+   token issued by the authorization server.  Typically, it involves
+   using the HTTP "Authorization" request header field [RFC2617] with an
+   authentication scheme defined by the specification of the access
+   token type used, such as [RFC6750].
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 48]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+7.1.  Access Token Types
+
+   The access token type provides the client with the information
+   required to successfully utilize the access token to make a protected
+   resource request (along with type-specific attributes).  The client
+   MUST NOT use an access token if it does not understand the token
+   type.
+
+   For example, the "bearer" token type defined in [RFC6750] is utilized
+   by simply including the access token string in the request:
+
+     GET /resource/1 HTTP/1.1
+     Host: example.com
+     Authorization: Bearer mF_9.B5f-4.1JqM
+
+   while the "mac" token type defined in [OAuth-HTTP-MAC] is utilized by
+   issuing a Message Authentication Code (MAC) key together with the
+   access token that is used to sign certain components of the HTTP
+   requests:
+
+     GET /resource/1 HTTP/1.1
+     Host: example.com
+     Authorization: MAC id="h480djs93hd8",
+                        nonce="274312:dj83hs9s",
+                        mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
+
+   The above examples are provided for illustration purposes only.
+   Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC]
+   specifications before use.
+
+   Each access token type definition specifies the additional attributes
+   (if any) sent to the client together with the "access_token" response
+   parameter.  It also defines the HTTP authentication method used to
+   include the access token when making a protected resource request.
+
+7.2.  Error Response
+
+   If a resource access request fails, the resource server SHOULD inform
+   the client of the error.  While the specifics of such error responses
+   are beyond the scope of this specification, this document establishes
+   a common registry in Section 11.4 for error values to be shared among
+   OAuth token authentication schemes.
+
+   New authentication schemes designed primarily for OAuth token
+   authentication SHOULD define a mechanism for providing an error
+   status code to the client, in which the error values allowed are
+   registered in the error registry established by this specification.
+
+
+
+
+Hardt                        Standards Track                   [Page 49]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Such schemes MAY limit the set of valid error codes to a subset of
+   the registered values.  If the error code is returned using a named
+   parameter, the parameter name SHOULD be "error".
+
+   Other schemes capable of being used for OAuth token authentication,
+   but not primarily designed for that purpose, MAY bind their error
+   values to the registry in the same manner.
+
+   New authentication schemes MAY choose to also specify the use of the
+   "error_description" and "error_uri" parameters to return error
+   information in a manner parallel to their usage in this
+   specification.
+
+8.  Extensibility
+
+8.1.  Defining Access Token Types
+
+   Access token types can be defined in one of two ways: registered in
+   the Access Token Types registry (following the procedures in
+   Section 11.1), or by using a unique absolute URI as its name.
+
+   Types utilizing a URI name SHOULD be limited to vendor-specific
+   implementations that are not commonly applicable, and are specific to
+   the implementation details of the resource server where they are
+   used.
+
+   All other types MUST be registered.  Type names MUST conform to the
+   type-name ABNF.  If the type definition includes a new HTTP
+   authentication scheme, the type name SHOULD be identical to the HTTP
+   authentication scheme name (as defined by [RFC2617]).  The token type
+   "example" is reserved for use in examples.
+
+     type-name  = 1*name-char
+     name-char  = "-" / "." / "_" / DIGIT / ALPHA
+
+8.2.  Defining New Endpoint Parameters
+
+   New request or response parameters for use with the authorization
+   endpoint or the token endpoint are defined and registered in the
+   OAuth Parameters registry following the procedure in Section 11.2.
+
+   Parameter names MUST conform to the param-name ABNF, and parameter
+   values syntax MUST be well-defined (e.g., using ABNF, or a reference
+   to the syntax of an existing parameter).
+
+     param-name  = 1*name-char
+     name-char   = "-" / "." / "_" / DIGIT / ALPHA
+
+
+
+
+Hardt                        Standards Track                   [Page 50]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Unregistered vendor-specific parameter extensions that are not
+   commonly applicable and that are specific to the implementation
+   details of the authorization server where they are used SHOULD
+   utilize a vendor-specific prefix that is not likely to conflict with
+   other registered values (e.g., begin with 'companyname_').
+
+8.3.  Defining New Authorization Grant Types
+
+   New authorization grant types can be defined by assigning them a
+   unique absolute URI for use with the "grant_type" parameter.  If the
+   extension grant type requires additional token endpoint parameters,
+   they MUST be registered in the OAuth Parameters registry as described
+   by Section 11.2.
+
+8.4.  Defining New Authorization Endpoint Response Types
+
+   New response types for use with the authorization endpoint are
+   defined and registered in the Authorization Endpoint Response Types
+   registry following the procedure in Section 11.3.  Response type
+   names MUST conform to the response-type ABNF.
+
+     response-type  = response-name *( SP response-name )
+     response-name  = 1*response-char
+     response-char  = "_" / DIGIT / ALPHA
+
+   If a response type contains one or more space characters (%x20), it
+   is compared as a space-delimited list of values in which the order of
+   values does not matter.  Only one order of values can be registered,
+   which covers all other arrangements of the same set of values.
+
+   For example, the response type "token code" is left undefined by this
+   specification.  However, an extension can define and register the
+   "token code" response type.  Once registered, the same combination
+   cannot be registered as "code token", but both values can be used to
+   denote the same response type.
+
+8.5.  Defining Additional Error Codes
+
+   In cases where protocol extensions (i.e., access token types,
+   extension parameters, or extension grant types) require additional
+   error codes to be used with the authorization code grant error
+   response (Section 4.1.2.1), the implicit grant error response
+   (Section 4.2.2.1), the token error response (Section 5.2), or the
+   resource access error response (Section 7.2), such error codes MAY be
+   defined.
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 51]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Extension error codes MUST be registered (following the procedures in
+   Section 11.4) if the extension they are used in conjunction with is a
+   registered access token type, a registered endpoint parameter, or an
+   extension grant type.  Error codes used with unregistered extensions
+   MAY be registered.
+
+   Error codes MUST conform to the error ABNF and SHOULD be prefixed by
+   an identifying name when possible.  For example, an error identifying
+   an invalid value set to the extension parameter "example" SHOULD be
+   named "example_invalid".
+
+     error      = 1*error-char
+     error-char = %x20-21 / %x23-5B / %x5D-7E
+
+9.  Native Applications
+
+   Native applications are clients installed and executed on the device
+   used by the resource owner (i.e., desktop application, native mobile
+   application).  Native applications require special consideration
+   related to security, platform capabilities, and overall end-user
+   experience.
+
+   The authorization endpoint requires interaction between the client
+   and the resource owner's user-agent.  Native applications can invoke
+   an external user-agent or embed a user-agent within the application.
+   For example:
+
+   o  External user-agent - the native application can capture the
+      response from the authorization server using a redirection URI
+      with a scheme registered with the operating system to invoke the
+      client as the handler, manual copy-and-paste of the credentials,
+      running a local web server, installing a user-agent extension, or
+      by providing a redirection URI identifying a server-hosted
+      resource under the client's control, which in turn makes the
+      response available to the native application.
+
+   o  Embedded user-agent - the native application obtains the response
+      by directly communicating with the embedded user-agent by
+      monitoring state changes emitted during the resource load, or
+      accessing the user-agent's cookies storage.
+
+   When choosing between an external or embedded user-agent, developers
+   should consider the following:
+
+   o  An external user-agent may improve completion rate, as the
+      resource owner may already have an active session with the
+      authorization server, removing the need to re-authenticate.  It
+      provides a familiar end-user experience and functionality.  The
+
+
+
+Hardt                        Standards Track                   [Page 52]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+      resource owner may also rely on user-agent features or extensions
+      to assist with authentication (e.g., password manager, 2-factor
+      device reader).
+
+   o  An embedded user-agent may offer improved usability, as it removes
+      the need to switch context and open new windows.
+
+   o  An embedded user-agent poses a security challenge because resource
+      owners are authenticating in an unidentified window without access
+      to the visual protections found in most external user-agents.  An
+      embedded user-agent educates end-users to trust unidentified
+      requests for authentication (making phishing attacks easier to
+      execute).
+
+   When choosing between the implicit grant type and the authorization
+   code grant type, the following should be considered:
+
+   o  Native applications that use the authorization code grant type
+      SHOULD do so without using client credentials, due to the native
+      application's inability to keep client credentials confidential.
+
+   o  When using the implicit grant type flow, a refresh token is not
+      returned, which requires repeating the authorization process once
+      the access token expires.
+
+10.  Security Considerations
+
+   As a flexible and extensible framework, OAuth's security
+   considerations depend on many factors.  The following sections
+   provide implementers with security guidelines focused on the three
+   client profiles described in Section 2.1: web application,
+   user-agent-based application, and native application.
+
+   A comprehensive OAuth security model and analysis, as well as
+   background for the protocol design, is provided by
+   [OAuth-THREATMODEL].
+
+10.1.  Client Authentication
+
+   The authorization server establishes client credentials with web
+   application clients for the purpose of client authentication.  The
+   authorization server is encouraged to consider stronger client
+   authentication means than a client password.  Web application clients
+   MUST ensure confidentiality of client passwords and other client
+   credentials.
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 53]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   The authorization server MUST NOT issue client passwords or other
+   client credentials to native application or user-agent-based
+   application clients for the purpose of client authentication.  The
+   authorization server MAY issue a client password or other credentials
+   for a specific installation of a native application client on a
+   specific device.
+
+   When client authentication is not possible, the authorization server
+   SHOULD employ other means to validate the client's identity -- for
+   example, by requiring the registration of the client redirection URI
+   or enlisting the resource owner to confirm identity.  A valid
+   redirection URI is not sufficient to verify the client's identity
+   when asking for resource owner authorization but can be used to
+   prevent delivering credentials to a counterfeit client after
+   obtaining resource owner authorization.
+
+   The authorization server must consider the security implications of
+   interacting with unauthenticated clients and take measures to limit
+   the potential exposure of other credentials (e.g., refresh tokens)
+   issued to such clients.
+
+10.2.  Client Impersonation
+
+   A malicious client can impersonate another client and obtain access
+   to protected resources if the impersonated client fails to, or is
+   unable to, keep its client credentials confidential.
+
+   The authorization server MUST authenticate the client whenever
+   possible.  If the authorization server cannot authenticate the client
+   due to the client's nature, the authorization server MUST require the
+   registration of any redirection URI used for receiving authorization
+   responses and SHOULD utilize other means to protect resource owners
+   from such potentially malicious clients.  For example, the
+   authorization server can engage the resource owner to assist in
+   identifying the client and its origin.
+
+   The authorization server SHOULD enforce explicit resource owner
+   authentication and provide the resource owner with information about
+   the client and the requested authorization scope and lifetime.  It is
+   up to the resource owner to review the information in the context of
+   the current client and to authorize or deny the request.
+
+   The authorization server SHOULD NOT process repeated authorization
+   requests automatically (without active resource owner interaction)
+   without authenticating the client or relying on other measures to
+   ensure that the repeated request comes from the original client and
+   not an impersonator.
+
+
+
+
+Hardt                        Standards Track                   [Page 54]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+10.3.  Access Tokens
+
+   Access token credentials (as well as any confidential access token
+   attributes) MUST be kept confidential in transit and storage, and
+   only shared among the authorization server, the resource servers the
+   access token is valid for, and the client to whom the access token is
+   issued.  Access token credentials MUST only be transmitted using TLS
+   as described in Section 1.6 with server authentication as defined by
+   [RFC2818].
+
+   When using the implicit grant type, the access token is transmitted
+   in the URI fragment, which can expose it to unauthorized parties.
+
+   The authorization server MUST ensure that access tokens cannot be
+   generated, modified, or guessed to produce valid access tokens by
+   unauthorized parties.
+
+   The client SHOULD request access tokens with the minimal scope
+   necessary.  The authorization server SHOULD take the client identity
+   into account when choosing how to honor the requested scope and MAY
+   issue an access token with less rights than requested.
+
+   This specification does not provide any methods for the resource
+   server to ensure that an access token presented to it by a given
+   client was issued to that client by the authorization server.
+
+10.4.  Refresh Tokens
+
+   Authorization servers MAY issue refresh tokens to web application
+   clients and native application clients.
+
+   Refresh tokens MUST be kept confidential in transit and storage, and
+   shared only among the authorization server and the client to whom the
+   refresh tokens were issued.  The authorization server MUST maintain
+   the binding between a refresh token and the client to whom it was
+   issued.  Refresh tokens MUST only be transmitted using TLS as
+   described in Section 1.6 with server authentication as defined by
+   [RFC2818].
+
+   The authorization server MUST verify the binding between the refresh
+   token and client identity whenever the client identity can be
+   authenticated.  When client authentication is not possible, the
+   authorization server SHOULD deploy other means to detect refresh
+   token abuse.
+
+   For example, the authorization server could employ refresh token
+   rotation in which a new refresh token is issued with every access
+   token refresh response.  The previous refresh token is invalidated
+
+
+
+Hardt                        Standards Track                   [Page 55]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   but retained by the authorization server.  If a refresh token is
+   compromised and subsequently used by both the attacker and the
+   legitimate client, one of them will present an invalidated refresh
+   token, which will inform the authorization server of the breach.
+
+   The authorization server MUST ensure that refresh tokens cannot be
+   generated, modified, or guessed to produce valid refresh tokens by
+   unauthorized parties.
+
+10.5.  Authorization Codes
+
+   The transmission of authorization codes SHOULD be made over a secure
+   channel, and the client SHOULD require the use of TLS with its
+   redirection URI if the URI identifies a network resource.  Since
+   authorization codes are transmitted via user-agent redirections, they
+   could potentially be disclosed through user-agent history and HTTP
+   referrer headers.
+
+   Authorization codes operate as plaintext bearer credentials, used to
+   verify that the resource owner who granted authorization at the
+   authorization server is the same resource owner returning to the
+   client to complete the process.  Therefore, if the client relies on
+   the authorization code for its own resource owner authentication, the
+   client redirection endpoint MUST require the use of TLS.
+
+   Authorization codes MUST be short lived and single-use.  If the
+   authorization server observes multiple attempts to exchange an
+   authorization code for an access token, the authorization server
+   SHOULD attempt to revoke all access tokens already granted based on
+   the compromised authorization code.
+
+   If the client can be authenticated, the authorization servers MUST
+   authenticate the client and ensure that the authorization code was
+   issued to the same client.
+
+10.6.  Authorization Code Redirection URI Manipulation
+
+   When requesting authorization using the authorization code grant
+   type, the client can specify a redirection URI via the "redirect_uri"
+   parameter.  If an attacker can manipulate the value of the
+   redirection URI, it can cause the authorization server to redirect
+   the resource owner user-agent to a URI under the control of the
+   attacker with the authorization code.
+
+   An attacker can create an account at a legitimate client and initiate
+   the authorization flow.  When the attacker's user-agent is sent to
+   the authorization server to grant access, the attacker grabs the
+   authorization URI provided by the legitimate client and replaces the
+
+
+
+Hardt                        Standards Track                   [Page 56]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   client's redirection URI with a URI under the control of the
+   attacker.  The attacker then tricks the victim into following the
+   manipulated link to authorize access to the legitimate client.
+
+   Once at the authorization server, the victim is prompted with a
+   normal, valid request on behalf of a legitimate and trusted client,
+   and authorizes the request.  The victim is then redirected to an
+   endpoint under the control of the attacker with the authorization
+   code.  The attacker completes the authorization flow by sending the
+   authorization code to the client using the original redirection URI
+   provided by the client.  The client exchanges the authorization code
+   with an access token and links it to the attacker's client account,
+   which can now gain access to the protected resources authorized by
+   the victim (via the client).
+
+   In order to prevent such an attack, the authorization server MUST
+   ensure that the redirection URI used to obtain the authorization code
+   is identical to the redirection URI provided when exchanging the
+   authorization code for an access token.  The authorization server
+   MUST require public clients and SHOULD require confidential clients
+   to register their redirection URIs.  If a redirection URI is provided
+   in the request, the authorization server MUST validate it against the
+   registered value.
+
+10.7.  Resource Owner Password Credentials
+
+   The resource owner password credentials grant type is often used for
+   legacy or migration reasons.  It reduces the overall risk of storing
+   usernames and passwords by the client but does not eliminate the need
+   to expose highly privileged credentials to the client.
+
+   This grant type carries a higher risk than other grant types because
+   it maintains the password anti-pattern this protocol seeks to avoid.
+   The client could abuse the password, or the password could
+   unintentionally be disclosed to an attacker (e.g., via log files or
+   other records kept by the client).
+
+   Additionally, because the resource owner does not have control over
+   the authorization process (the resource owner's involvement ends when
+   it hands over its credentials to the client), the client can obtain
+   access tokens with a broader scope than desired by the resource
+   owner.  The authorization server should consider the scope and
+   lifetime of access tokens issued via this grant type.
+
+   The authorization server and client SHOULD minimize use of this grant
+   type and utilize other grant types whenever possible.
+
+
+
+
+
+Hardt                        Standards Track                   [Page 57]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+10.8.  Request Confidentiality
+
+   Access tokens, refresh tokens, resource owner passwords, and client
+   credentials MUST NOT be transmitted in the clear.  Authorization
+   codes SHOULD NOT be transmitted in the clear.
+
+   The "state" and "scope" parameters SHOULD NOT include sensitive
+   client or resource owner information in plain text, as they can be
+   transmitted over insecure channels or stored insecurely.
+
+10.9.  Ensuring Endpoint Authenticity
+
+   In order to prevent man-in-the-middle attacks, the authorization
+   server MUST require the use of TLS with server authentication as
+   defined by [RFC2818] for any request sent to the authorization and
+   token endpoints.  The client MUST validate the authorization server's
+   TLS certificate as defined by [RFC6125] and in accordance with its
+   requirements for server identity authentication.
+
+10.10.  Credentials-Guessing Attacks
+
+   The authorization server MUST prevent attackers from guessing access
+   tokens, authorization codes, refresh tokens, resource owner
+   passwords, and client credentials.
+
+   The probability of an attacker guessing generated tokens (and other
+   credentials not intended for handling by end-users) MUST be less than
+   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
+
+   The authorization server MUST utilize other means to protect
+   credentials intended for end-user usage.
+
+10.11.  Phishing Attacks
+
+   Wide deployment of this and similar protocols may cause end-users to
+   become inured to the practice of being redirected to websites where
+   they are asked to enter their passwords.  If end-users are not
+   careful to verify the authenticity of these websites before entering
+   their credentials, it will be possible for attackers to exploit this
+   practice to steal resource owners' passwords.
+
+   Service providers should attempt to educate end-users about the risks
+   phishing attacks pose and should provide mechanisms that make it easy
+   for end-users to confirm the authenticity of their sites.  Client
+   developers should consider the security implications of how they
+   interact with the user-agent (e.g., external, embedded), and the
+   ability of the end-user to verify the authenticity of the
+   authorization server.
+
+
+
+Hardt                        Standards Track                   [Page 58]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   To reduce the risk of phishing attacks, the authorization servers
+   MUST require the use of TLS on every endpoint used for end-user
+   interaction.
+
+10.12.  Cross-Site Request Forgery
+
+   Cross-site request forgery (CSRF) is an exploit in which an attacker
+   causes the user-agent of a victim end-user to follow a malicious URI
+   (e.g., provided to the user-agent as a misleading link, image, or
+   redirection) to a trusting server (usually established via the
+   presence of a valid session cookie).
+
+   A CSRF attack against the client's redirection URI allows an attacker
+   to inject its own authorization code or access token, which can
+   result in the client using an access token associated with the
+   attacker's protected resources rather than the victim's (e.g., save
+   the victim's bank account information to a protected resource
+   controlled by the attacker).
+
+   The client MUST implement CSRF protection for its redirection URI.
+   This is typically accomplished by requiring any request sent to the
+   redirection URI endpoint to include a value that binds the request to
+   the user-agent's authenticated state (e.g., a hash of the session
+   cookie used to authenticate the user-agent).  The client SHOULD
+   utilize the "state" request parameter to deliver this value to the
+   authorization server when making an authorization request.
+
+   Once authorization has been obtained from the end-user, the
+   authorization server redirects the end-user's user-agent back to the
+   client with the required binding value contained in the "state"
+   parameter.  The binding value enables the client to verify the
+   validity of the request by matching the binding value to the
+   user-agent's authenticated state.  The binding value used for CSRF
+   protection MUST contain a non-guessable value (as described in
+   Section 10.10), and the user-agent's authenticated state (e.g.,
+   session cookie, HTML5 local storage) MUST be kept in a location
+   accessible only to the client and the user-agent (i.e., protected by
+   same-origin policy).
+
+   A CSRF attack against the authorization server's authorization
+   endpoint can result in an attacker obtaining end-user authorization
+   for a malicious client without involving or alerting the end-user.
+
+   The authorization server MUST implement CSRF protection for its
+   authorization endpoint and ensure that a malicious client cannot
+   obtain authorization without the awareness and explicit consent of
+   the resource owner.
+
+
+
+
+Hardt                        Standards Track                   [Page 59]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+10.13.  Clickjacking
+
+   In a clickjacking attack, an attacker registers a legitimate client
+   and then constructs a malicious site in which it loads the
+   authorization server's authorization endpoint web page in a
+   transparent iframe overlaid on top of a set of dummy buttons, which
+   are carefully constructed to be placed directly under important
+   buttons on the authorization page.  When an end-user clicks a
+   misleading visible button, the end-user is actually clicking an
+   invisible button on the authorization page (such as an "Authorize"
+   button).  This allows an attacker to trick a resource owner into
+   granting its client access without the end-user's knowledge.
+
+   To prevent this form of attack, native applications SHOULD use
+   external browsers instead of embedding browsers within the
+   application when requesting end-user authorization.  For most newer
+   browsers, avoidance of iframes can be enforced by the authorization
+   server using the (non-standard) "x-frame-options" header.  This
+   header can have two values, "deny" and "sameorigin", which will block
+   any framing, or framing by sites with a different origin,
+   respectively.  For older browsers, JavaScript frame-busting
+   techniques can be used but may not be effective in all browsers.
+
+10.14.  Code Injection and Input Validation
+
+   A code injection attack occurs when an input or otherwise external
+   variable is used by an application unsanitized and causes
+   modification to the application logic.  This may allow an attacker to
+   gain access to the application device or its data, cause denial of
+   service, or introduce a wide range of malicious side-effects.
+
+   The authorization server and client MUST sanitize (and validate when
+   possible) any value received -- in particular, the value of the
+   "state" and "redirect_uri" parameters.
+
+10.15.  Open Redirectors
+
+   The authorization server, authorization endpoint, and client
+   redirection endpoint can be improperly configured and operate as open
+   redirectors.  An open redirector is an endpoint using a parameter to
+   automatically redirect a user-agent to the location specified by the
+   parameter value without any validation.
+
+   Open redirectors can be used in phishing attacks, or by an attacker
+   to get end-users to visit malicious sites by using the URI authority
+   component of a familiar and trusted destination.  In addition, if the
+   authorization server allows the client to register only part of the
+   redirection URI, an attacker can use an open redirector operated by
+
+
+
+Hardt                        Standards Track                   [Page 60]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   the client to construct a redirection URI that will pass the
+   authorization server validation but will send the authorization code
+   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
+
+   For public clients using implicit flows, this specification does not
+   provide any method for the client to determine what client an access
+   token was issued to.
+
+   A resource owner may willingly delegate access to a resource by
+   granting an access token to an attacker's malicious client.  This may
+   be due to phishing or some other pretext.  An attacker may also steal
+   a token via some other mechanism.  An attacker may then attempt to
+   impersonate the resource owner by providing the access token to a
+   legitimate public client.
+
+   In the implicit flow (response_type=token), the attacker can easily
+   switch the token in the response from the authorization server,
+   replacing the real access token with the one previously issued to the
+   attacker.
+
+   Servers communicating with native applications that rely on being
+   passed an access token in the back channel to identify the user of
+   the client may be similarly compromised by an attacker creating a
+   compromised application that can inject arbitrary stolen access
+   tokens.
+
+   Any public client that makes the assumption that only the resource
+   owner can present it with a valid access token for the resource is
+   vulnerable to this type of attack.
+
+   This type of attack may expose information about the resource owner
+   at the legitimate client to the attacker (malicious client).  This
+   will also allow the attacker to perform operations at the legitimate
+   client with the same permissions as the resource owner who originally
+   granted the access token or authorization code.
+
+   Authenticating resource owners to clients is out of scope for this
+   specification.  Any specification that uses the authorization process
+   as a form of delegated end-user authentication to the client (e.g.,
+   third-party sign-in service) MUST NOT use the implicit flow without
+   additional security mechanisms that would enable the client to
+   determine if the access token was issued for its use (e.g., audience-
+   restricting the access token).
+
+
+
+
+
+Hardt                        Standards Track                   [Page 61]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+11.  IANA Considerations
+
+11.1.  OAuth Access Token Types Registry
+
+   This specification establishes the OAuth Access Token Types registry.
+
+   Access token types are registered with a Specification Required
+   ([RFC5226]) after a two-week review period on the
+   oauth-ext-review@ietf.org mailing list, on the advice of one or more
+   Designated Experts.  However, to allow for the allocation of values
+   prior to publication, the Designated Expert(s) may approve
+   registration once they are satisfied that such a specification will
+   be published.
+
+   Registration requests must be sent to the oauth-ext-review@ietf.org
+   mailing list for review and comment, with an appropriate subject
+   (e.g., "Request for access token type: example").
+
+   Within the review period, the Designated Expert(s) will either
+   approve or deny the registration request, communicating this decision
+   to the review list and IANA.  Denials should include an explanation
+   and, if applicable, suggestions as to how to make the request
+   successful.
+
+   IANA must only accept registry updates from the Designated Expert(s)
+   and should direct all requests for registration to the review mailing
+   list.
+
+11.1.1.  Registration Template
+
+   Type name:
+      The name requested (e.g., "example").
+
+   Additional Token Endpoint Response Parameters:
+      Additional response parameters returned together with the
+      "access_token" parameter.  New parameters MUST be separately
+      registered in the OAuth Parameters registry as described by
+      Section 11.2.
+
+   HTTP Authentication Scheme(s):
+      The HTTP authentication scheme name(s), if any, used to
+      authenticate protected resource requests using access tokens of
+      this type.
+
+   Change controller:
+      For Standards Track RFCs, state "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+
+
+Hardt                        Standards Track                   [Page 62]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Specification document(s):
+      Reference to the document(s) that specify the parameter,
+      preferably including a URI that can be used to retrieve a copy of
+      the document(s).  An indication of the relevant sections may also
+      be included but is not required.
+
+11.2.  OAuth Parameters Registry
+
+   This specification establishes the OAuth Parameters registry.
+
+   Additional parameters for inclusion in the authorization endpoint
+   request, the authorization endpoint response, the token endpoint
+   request, or the token endpoint response are registered with a
+   Specification Required ([RFC5226]) after a two-week review period on
+   the oauth-ext-review@ietf.org mailing list, on the advice of one or
+   more Designated Experts.  However, to allow for the allocation of
+   values prior to publication, the Designated Expert(s) may approve
+   registration once they are satisfied that such a specification will
+   be published.
+
+   Registration requests must be sent to the oauth-ext-review@ietf.org
+   mailing list for review and comment, with an appropriate subject
+   (e.g., "Request for parameter: example").
+
+   Within the review period, the Designated Expert(s) will either
+   approve or deny the registration request, communicating this decision
+   to the review list and IANA.  Denials should include an explanation
+   and, if applicable, suggestions as to how to make the request
+   successful.
+
+   IANA must only accept registry updates from the Designated Expert(s)
+   and should direct all requests for registration to the review mailing
+   list.
+
+11.2.1.  Registration Template
+
+   Parameter name:
+      The name requested (e.g., "example").
+
+   Parameter usage location:
+      The location(s) where parameter can be used.  The possible
+      locations are authorization request, authorization response, token
+      request, or token response.
+
+   Change controller:
+      For Standards Track RFCs, state "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+
+
+Hardt                        Standards Track                   [Page 63]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   Specification document(s):
+      Reference to the document(s) that specify the parameter,
+      preferably including a URI that can be used to retrieve a copy of
+      the document(s).  An indication of the relevant sections may also
+      be included but is not required.
+
+11.2.2.  Initial Registry Contents
+
+   The OAuth Parameters registry's initial contents are:
+
+   o  Parameter name: client_id
+   o  Parameter usage location: authorization request, token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: client_secret
+   o  Parameter usage location: token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: response_type
+   o  Parameter usage location: authorization request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: redirect_uri
+   o  Parameter usage location: authorization request, token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: scope
+   o  Parameter usage location: authorization request, authorization
+      response, token request, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: state
+   o  Parameter usage location: authorization request, authorization
+      response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: code
+   o  Parameter usage location: authorization response, token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+
+
+
+
+Hardt                        Standards Track                   [Page 64]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   o  Parameter name: error_description
+   o  Parameter usage location: authorization response, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: error_uri
+   o  Parameter usage location: authorization response, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: grant_type
+   o  Parameter usage location: token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: access_token
+   o  Parameter usage location: authorization response, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: token_type
+   o  Parameter usage location: authorization response, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: expires_in
+   o  Parameter usage location: authorization response, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: username
+   o  Parameter usage location: token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: password
+   o  Parameter usage location: token request
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Parameter name: refresh_token
+   o  Parameter usage location: token request, token response
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 65]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+11.3.  OAuth Authorization Endpoint Response Types Registry
+
+   This specification establishes the OAuth Authorization Endpoint
+   Response Types registry.
+
+   Additional response types for use with the authorization endpoint are
+   registered with a Specification Required ([RFC5226]) after a two-week
+   review period on the oauth-ext-review@ietf.org mailing list, on the
+   advice of one or more Designated Experts.  However, to allow for the
+   allocation of values prior to publication, the Designated Expert(s)
+   may approve registration once they are satisfied that such a
+   specification will be published.
+
+   Registration requests must be sent to the oauth-ext-review@ietf.org
+   mailing list for review and comment, with an appropriate subject
+   (e.g., "Request for response type: example").
+
+   Within the review period, the Designated Expert(s) will either
+   approve or deny the registration request, communicating this decision
+   to the review list and IANA.  Denials should include an explanation
+   and, if applicable, suggestions as to how to make the request
+   successful.
+
+   IANA must only accept registry updates from the Designated Expert(s)
+   and should direct all requests for registration to the review mailing
+   list.
+
+11.3.1.  Registration Template
+
+   Response type name:
+      The name requested (e.g., "example").
+
+   Change controller:
+      For Standards Track RFCs, state "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+   Specification document(s):
+      Reference to the document(s) that specify the type, preferably
+      including a URI that can be used to retrieve a copy of the
+      document(s).  An indication of the relevant sections may also be
+      included but is not required.
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 66]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+11.3.2.  Initial Registry Contents
+
+   The OAuth Authorization Endpoint Response Types registry's initial
+   contents are:
+
+   o  Response type name: code
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+   o  Response type name: token
+   o  Change controller: IETF
+   o  Specification document(s): RFC 6749
+
+11.4.  OAuth Extensions Error Registry
+
+   This specification establishes the OAuth Extensions Error registry.
+
+   Additional error codes used together with other protocol extensions
+   (i.e., extension grant types, access token types, or extension
+   parameters) are registered with a Specification Required ([RFC5226])
+   after a two-week review period on the oauth-ext-review@ietf.org
+   mailing list, on the advice of one or more Designated Experts.
+   However, to allow for the allocation of values prior to publication,
+   the Designated Expert(s) may approve registration once they are
+   satisfied that such a specification will be published.
+
+   Registration requests must be sent to the oauth-ext-review@ietf.org
+   mailing list for review and comment, with an appropriate subject
+   (e.g., "Request for error code: example").
+
+   Within the review period, the Designated Expert(s) will either
+   approve or deny the registration request, communicating this decision
+   to the review list and IANA.  Denials should include an explanation
+   and, if applicable, suggestions as to how to make the request
+   successful.
+
+   IANA must only accept registry updates from the Designated Expert(s)
+   and should direct all requests for registration to the review mailing
+   list.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 67]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+11.4.1.  Registration Template
+
+   Error name:
+      The name requested (e.g., "example").  Values for the error name
+      MUST NOT include characters outside the set %x20-21 / %x23-5B /
+      %x5D-7E.
+
+   Error usage location:
+      The location(s) where the error can be used.  The possible
+      locations are authorization code grant error response
+      (Section 4.1.2.1), implicit grant error response
+      (Section 4.2.2.1), token error response (Section 5.2), or resource
+      access error response (Section 7.2).
+
+   Related protocol extension:
+      The name of the extension grant type, access token type, or
+      extension parameter that the error code is used in conjunction
+      with.
+
+   Change controller:
+      For Standards Track RFCs, state "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+   Specification document(s):
+      Reference to the document(s) that specify the error code,
+      preferably including a URI that can be used to retrieve a copy of
+      the document(s).  An indication of the relevant sections may also
+      be included but is not required.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A., and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+
+
+Hardt                        Standards Track                   [Page 68]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
+              ISO 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4627]  Crockford, D., "The application/json Media Type for
+              JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [USASCII]  American National Standards Institute, "Coded Character
+              Set -- 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+   [W3C.REC-html401-19991224]
+              Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
+              Specification", World Wide Web Consortium
+              Recommendation REC-html401-19991224, December 1999,
+              <http://www.w3.org/TR/1999/REC-html401-19991224>.
+
+   [W3C.REC-xml-20081126]
+              Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
+              and F. Yergeau, "Extensible Markup Language (XML) 1.0
+              (Fifth Edition)", World Wide Web Consortium
+               Recommendation REC-xml-20081126, November 2008,
+              <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+
+
+
+Hardt                        Standards Track                   [Page 69]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+12.2.  Informative References
+
+   [OAuth-HTTP-MAC]
+              Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access
+              Authentication", Work in Progress, February 2012.
+
+   [OAuth-SAML2]
+              Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
+              Profiles for OAuth 2.0", Work in Progress, September 2012.
+
+   [OAuth-THREATMODEL]
+              Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
+              Threat Model and Security Considerations", Work
+              in Progress, October 2012.
+
+   [OAuth-WRAP]
+              Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
+              Web Resource Authorization Profiles", Work in Progress,
+              January 2010.
+
+   [RFC5849]  Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
+              April 2010.
+
+   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
+              Framework: Bearer Token Usage", RFC 6750, October 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 70]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax
+
+   This section provides Augmented Backus-Naur Form (ABNF) syntax
+   descriptions for the elements defined in this specification using the
+   notation of [RFC5234].  The ABNF below is defined in terms of Unicode
+   code points [W3C.REC-xml-20081126]; these characters are typically
+   encoded in UTF-8.  Elements are presented in the order first defined.
+
+   Some of the definitions that follow use the "URI-reference"
+   definition from [RFC3986].
+
+   Some of the definitions that follow use these common definitions:
+
+     VSCHAR     = %x20-7E
+     NQCHAR     = %x21 / %x23-5B / %x5D-7E
+     NQSCHAR    = %x20-21 / %x23-5B / %x5D-7E
+     UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
+                         %xE000-FFFD / %x10000-10FFFF
+
+   (The UNICODECHARNOCRLF definition is based upon the Char definition
+   in Section 2.2 of [W3C.REC-xml-20081126], but omitting the Carriage
+   Return and Linefeed characters.)
+
+A.1.  "client_id" Syntax
+
+   The "client_id" element is defined in Section 2.3.1:
+
+     client-id     = *VSCHAR
+
+A.2.  "client_secret" Syntax
+
+   The "client_secret" element is defined in Section 2.3.1:
+
+     client-secret = *VSCHAR
+
+A.3.  "response_type" Syntax
+
+   The "response_type" element is defined in Sections 3.1.1 and 8.4:
+
+     response-type = response-name *( SP response-name )
+     response-name = 1*response-char
+     response-char = "_" / DIGIT / ALPHA
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 71]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+A.4.  "scope" Syntax
+
+   The "scope" element is defined in Section 3.3:
+
+     scope       = scope-token *( SP scope-token )
+     scope-token = 1*NQCHAR
+
+A.5.  "state" Syntax
+
+   The "state" element is defined in Sections 4.1.1, 4.1.2, 4.1.2.1,
+   4.2.1, 4.2.2, and 4.2.2.1:
+
+     state      = 1*VSCHAR
+
+A.6.  "redirect_uri" Syntax
+
+   The "redirect_uri" element is defined in Sections 4.1.1, 4.1.3,
+   and 4.2.1:
+
+     redirect-uri      = URI-reference
+
+A.7.  "error" Syntax
+
+   The "error" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2,
+   7.2, and 8.5:
+
+     error             = 1*NQSCHAR
+
+A.8.  "error_description" Syntax
+
+   The "error_description" element is defined in Sections 4.1.2.1,
+   4.2.2.1, 5.2, and 7.2:
+
+     error-description = 1*NQSCHAR
+
+A.9.  "error_uri" Syntax
+
+   The "error_uri" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2,
+   and 7.2:
+
+     error-uri         = URI-reference
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 72]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+A.10.  "grant_type" Syntax
+
+   The "grant_type" element is defined in Sections 4.1.3, 4.3.2, 4.4.2,
+   4.5, and 6:
+
+     grant-type = grant-name / URI-reference
+     grant-name = 1*name-char
+     name-char  = "-" / "." / "_" / DIGIT / ALPHA
+
+A.11.  "code" Syntax
+
+   The "code" element is defined in Section 4.1.3:
+
+     code       = 1*VSCHAR
+
+A.12.  "access_token" Syntax
+
+   The "access_token" element is defined in Sections 4.2.2 and 5.1:
+
+     access-token = 1*VSCHAR
+
+A.13.  "token_type" Syntax
+
+   The "token_type" element is defined in Sections 4.2.2, 5.1, and 8.1:
+
+     token-type = type-name / URI-reference
+     type-name  = 1*name-char
+     name-char  = "-" / "." / "_" / DIGIT / ALPHA
+
+A.14.  "expires_in" Syntax
+
+   The "expires_in" element is defined in Sections 4.2.2 and 5.1:
+
+     expires-in = 1*DIGIT
+
+A.15.  "username" Syntax
+
+   The "username" element is defined in Section 4.3.2:
+
+     username = *UNICODECHARNOCRLF
+
+A.16.  "password" Syntax
+
+   The "password" element is defined in Section 4.3.2:
+
+     password = *UNICODECHARNOCRLF
+
+
+
+
+
+Hardt                        Standards Track                   [Page 73]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+A.17.  "refresh_token" Syntax
+
+   The "refresh_token" element is defined in Sections 5.1 and 6:
+
+     refresh-token = 1*VSCHAR
+
+A.18.  Endpoint Parameter Syntax
+
+   The syntax for new endpoint parameters is defined in Section 8.2:
+
+     param-name = 1*name-char
+     name-char  = "-" / "." / "_" / DIGIT / ALPHA
+
+Appendix B.  Use of application/x-www-form-urlencoded Media Type
+
+   At the time of publication of this specification, the
+   "application/x-www-form-urlencoded" media type was defined in
+   Section 17.13.4 of [W3C.REC-html401-19991224] but not registered in
+   the IANA MIME Media Types registry
+   (<http://www.iana.org/assignments/media-types>).  Furthermore, that
+   definition is incomplete, as it does not consider non-US-ASCII
+   characters.
+
+   To address this shortcoming when generating payloads using this media
+   type, names and values MUST be encoded using the UTF-8 character
+   encoding scheme [RFC3629] first; the resulting octet sequence then
+   needs to be further encoded using the escaping rules defined in
+   [W3C.REC-html401-19991224].
+
+   When parsing data from a payload using this media type, the names and
+   values resulting from reversing the name/value encoding consequently
+   need to be treated as octet sequences, to be decoded using the UTF-8
+   character encoding scheme.
+
+   For example, the value consisting of the six Unicode code points
+   (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
+   (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
+   (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded
+   into the octet sequence below (using hexadecimal notation):
+
+     20 25 26 2B C2 A3 E2 82 AC
+
+   and then represented in the payload as:
+
+     +%25%26%2B%C2%A3%E2%82%AC
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 74]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+Appendix C.  Acknowledgements
+
+   The initial OAuth 2.0 protocol specification was edited by David
+   Recordon, based on two previous publications: the OAuth 1.0 community
+   specification [RFC5849], and OAuth WRAP (OAuth Web Resource
+   Authorization Profiles) [OAuth-WRAP].  Eran Hammer then edited many
+   of the intermediate drafts that evolved into this RFC.  The Security
+   Considerations section was drafted by Torsten Lodderstedt, Mark
+   McGloin, Phil Hunt, Anthony Nadalin, and John Bradley.  The section
+   on use of the "application/x-www-form-urlencoded" media type was
+   drafted by Julian Reschke.  The ABNF section was drafted by Michael
+   B. Jones.
+
+   The OAuth 1.0 community specification was edited by Eran Hammer and
+   authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M.
+   Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton,
+   Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris
+   Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
+   Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
+
+   The OAuth WRAP specification was edited by Dick Hardt and authored by
+   Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom.
+
+   This specification is the work of the OAuth Working Group, which
+   includes dozens of active and dedicated participants.  In particular,
+   the following individuals contributed ideas, feedback, and wording
+   that shaped and formed the final specification:
+
+   Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
+   Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor,
+   Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre,
+   Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor
+   Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert,
+   Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer,
+   Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones,
+   Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara,
+   Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul
+   Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin,
+   Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin,
+   Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob
+   Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov,
+   Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner,
+   Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson,
+   Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar
+   Woodward.
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 75]
+
+RFC 6749                        OAuth 2.0                   October 2012
+
+
+   This document was produced under the chairmanship of Blaine Cook,
+   Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
+   The area directors included Lisa Dusseault, Peter Saint-Andre, and
+   Stephen Farrell.
+
+Author's Address
+
+   Dick Hardt (editor)
+   Microsoft
+
+   EMail: dick.hardt@gmail.com
+   URI:   http://dickhardt.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardt                        Standards Track                   [Page 76]
+