OAuth2 Multiple Response Type Encoding PracticesGoogle, Inc.breno@google.comGoogle, Inc.mscurtescu@google.comFacebookpt@fb.comThis specification aims to provide guidance on proper encoding of responses to
OAuth2 Authorization requests, where the request specifies a response type including
space characters.This specification also serves as the registration document for several
specific new response types, in accordance with the stipulations of
the OAuth Parameters Registry.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages, the
quotes MUST NOT be used as part of the value.The following definitions define additional terminology used in this
specification in addition to those defined in OAuth 2.0.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. A web resource mantained by
the server, and used to obtain authorization (grant) from the
resource owner via user-agent redirection.The client informs the
authorization server of the desired authorization processing flow using the
parameter response_type.
Process established by the OAuth2 specification for the registration of new
response_type parameters.The OAuth2 specification allows
for registration of space-separated response_type values.
If a response type contains one of more space characters (%20), it is
compared as a space-delimited list of values in which the order of
values does not matter.This specification does not provide guidance if, in a request, response_type includes
a value that requires the server to return data partially encoded in the query string
and partially encoded in the fragment.Otherwise, if a multiple-valued response type is defined, then it is RECOMMENDED
that the following encoding rules be applied for the issued response.If, in a request, response_type includes only values that require the server
to return data fully encoded within the query string then
the returned data in the response for this multiple-valued response_type
MUST be fully encoded within the query string. This recommendation
applies to both success and error responses.If, in a request, response_type includes any value that requires the server to
return data fully encoded within the fragment then the returned data in the
response for this multiple-valued response_type MUST be fully encoded
within the fragment. This recommendation applies to both success and error responses.Rationale: Whenever response_type values include fragment-encoded parts,
a user-agent client component must be involved to complete processing of the response.
If a new query parameter is added to the client URI, it will cause the user-agent
to re-fetch the client URI,
causing discontinuity of operation of the user-agent-based client components. If instead
only fragment encoding is used, the user-agent will simply re-active the client
component, at which time this component may process the fragment and
also convey any parameters to a client host as necessary, e.g., via XmlHttpRequest.
Therefore, full fragment encoding always results in lower latency for response processing.This section registers a new response type, the id_token, in accordance
with the stipulations in the OAuth2 specification, Section 8.4. The intended purpose of
the id_token is that it MUST provide an assertion of
the identity of the resource owner as understood by the server. The assertion MUST
specify a targeted audience, e.g. the requesting client. However, the specific semantics of
the assertion and how it can be validated are not specified in this document.If supplied as the response_type parameter in an OAuth2
Authorization Request, a successful response should include the parameter
id_token encoded in the fragment of the response URI.Returning the id_token in a fragment reduces the likelihood that the id_token leaks
during transport and mitigates the associated risks to the privacy of the user (resource owner).This section registers the response type none, in accordance
with the stipulations in the OAuth2 specification, Section 8.4.
The intended purpose is to enable
use cases where a party requests the server to register a grant of access to a protected
resource on behalf of a client but requires
no access credentials to be returned to the client at that time. The means
by which the client eventually obtains the access credentials is left unspecified here.One scenario is where a user wishes to purchase an
application from a market, and desires to authorize application installation and grant
the application access to protected resources in a single step. However, since the user is
not presently interacting with the (not yet active) application, it is not appropriate
to return access credentials simultaneously to the authorization step.When supplied as the response_type parameter in an OAuth2 authorization
request, the Authorization server SHOULD NOT return an OAuth2 code nor a token in a succesful
response to the grant request. If a redirect_uri is supplied, the user-agent SHOULD be redirected
there after granting or denying access. The request MAY include a state parameter, and if so the
server MUST echo its value by adding it to the redirect_uri when issuing a successful response.
Any parameters added to the redirect_uri should be query encoded. This applies to both successful
responses or error responses.The response type none SHOULD NOT be combined with other response types.This section registers combinations of the values code, token, and id_token, which are each
individually registered response types.When supplied as the value for the response_type parameter, a successful
response MUST include both an access token and an authorization code as defined in the OAuth2
specification. Both successful and error responses SHOULD be fragment-encoded.When supplied as the value for the response_type parameter,
a successful response MUST include both an authorization code as well as an id_token.
Both success and error responses SHOULD be fragment-encoded.When supplied as the value for the response_type parameter,
a successful response MUST include both an access token as well as an id_token.
Both success and error responses SHOULD be fragment-encoded.When supplied as the value for the response_type parameter,
a successful response MUST include an authorization code, an id_token, and an access token.
Both success and error responses SHOULD be fragment-encoded.A non-normative request/response example as issued/received by the user-agent:
OAuth 2.0 Authorization ProtocolYahooFacebookMicrosoftThe OpenID Community would like to thank the following people for the
work they've done in the drafting and editing of this specification.Naveen Agarwal (naa@google.com), GoogleBreno de Medeiros (breno@google.com), GoogleDavid Recordon (dr@fb.com), FacebookMarius Scurtescu (mscurtescu@google.com), GooglePaul Tarjan (pt@fb.com), Facebook[[ To be removed from the final specification ]]-01 Initial draft