<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect Standard 1.0 - draft 05</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Standard 1.0 - draft 05">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">N. Sakimura, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Protiviti</td></tr>
<tr><td class="header"> </td><td class="header">B. de Medeiros</td></tr>
<tr><td class="header"> </td><td class="header">Google</td></tr>
<tr><td class="header"> </td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">E. Jay</td></tr>
<tr><td class="header"> </td><td class="header">MGI1</td></tr>
<tr><td class="header"> </td><td class="header">September 30, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Standard 1.0 - draft 05</h1>
<h3>Abstract</h3>
<p>OpenID Connect 1.0 is a simple identity layer on top of OAuth
2.0 protocol. It allows a web site or application to verify the
identity of the user based on the authentication performed by
the authorization server, as well as to obtain basic profile information
about the user in an interoperable and RESTful manner.
</p>
<p>OpenID Connect Standard 1.0 is an HTTP protocol binding for
OpenID Connect Messages 1.0 request and response messages.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#rnc">1.</a>
Requirements Notation and Conventions<br />
<a href="#terminology">2.</a>
Terminology<br />
<a href="#anchor1">3.</a>
HTTP Protocol Binding<br />
<a href="#anchor2">4.</a>
Authorization Endpoint<br />
<a href="#openid_scopes">4.1.</a>
OpenID Connect Scopes<br />
<a href="#protocol_flows">4.2.</a>
Protocol Flows<br />
<a href="#retrieving_code_token">4.2.1.</a>
How To Get An Authorization Code, Access Token, and ID Token<br />
<a href="#code_flow">4.2.2.</a>
Authorization Code Flow<br />
<a href="#implicit_flow">4.2.3.</a>
Implicit Flow<br />
<a href="#auth_request">4.3.</a>
Authorization Request<br />
<a href="#rf_prep">4.3.1.</a>
Client prepares an Authorization Request<br />
<a href="#anchor6">4.3.2.</a>
Authorization Server Authenticates the End-User<br />
<a href="#anchor7">4.3.3.</a>
Authorization Server Obtains the End-User Consent/Authorization<br />
<a href="#art_res">4.3.4.</a>
Authorization Server Sends the End-User Back to the Client <br />
<a href="#token_ep">5.</a>
Token Endpoint<br />
<a href="#anchor8">5.1.</a>
Requesting an Access Token<br />
<a href="#anchor9">5.1.1.</a>
Access Token Request<br />
<a href="#anchor10">5.1.2.</a>
Access Token Response<br />
<a href="#anchor13">5.2.</a>
Refreshing an Access Token<br />
<a href="#anchor14">5.2.1.</a>
Positive Assertion<br />
<a href="#userinfo_ep">6.</a>
UserInfo Endpoint<br />
<a href="#anchor15">6.1.</a>
UserInfo Request<br />
<a href="#id_res">6.2.</a>
UserInfo Response<br />
<a href="#anchor16">6.2.1.</a>
UserInfo Error Response<br />
<a href="#check_id_ep">7.</a>
Check ID Endpoint<br />
<a href="#anchor17">7.1.</a>
Check ID Requests<br />
<a href="#intro_res">7.2.</a>
Check ID Response<br />
<a href="#anchor18">7.2.1.</a>
Check ID Error Response<br />
<a href="#session_eps">8.</a>
Session Management Endpoints<br />
<a href="#disco_reg">9.</a>
Discovery and Registration<br />
<a href="#security_considerations">10.</a>
Security Considerations<br />
<a href="#anchor19">10.1.</a>
Implicit Grant Flow Threats<br />
<a href="#IANA">11.</a>
IANA Considerations<br />
<a href="#rfc.references1">12.</a>
Normative References<br />
<a href="#anchor21">Appendix A.</a>
Footnotes<br />
<a href="#anchor22">A.1.</a>
Example JWT Values<br />
<a href="#anchor23">Appendix B.</a>
Acknowledgements<br />
<a href="#anchor24">Appendix C.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Requirements Notation and Conventions</h3>
<p>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 <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> .
</p>
<p>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.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Terminology</h3>
<p>Followings are the additional terminology defined in this
specification in addition to those defined in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] and <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Request File</dt>
<dd>A JSON structure that captures the <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]
Authorization Request parameters that can be pointed by a URL that
is reachable by the Authorization Server.
</dd>
<dt>Request URI</dt>
<dd>A URL that points to the Request File. It
MUST be accessible by the Authorization Server.
</dd>
<dt>Request Registration Endpoint</dt>
<dd>An HTTPS Endpoint URL
provided by the Authorization Server that enables the client to store
a Request File at the Authorization Server and receive back a Request
URI that uniquelyidentifies the registered Request File.
</dd>
</dl></blockquote>
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
HTTP Protocol Binding</h3>
<p>The <a class='info' href='#RFC2616'>HTTP<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] protocol is a widely used
application level protocol for distributed, collaborative, hypermedia
systems. Its ubiquitousness makes it an ideal protocol for use by
OpenID Connect. This specification describes the binding of the HTTP
protocol with the various endpoints described in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Authorization Endpoint</h3>
<p>The Authorization Endpoint performs authentication services for the
End-User and requests authorization from the End-User to release
information to OpenID Connect Relying Party clients. When an End-User
accesses a Relying Party client application which requires
the End-User's identity and other information, it sends the End-User to
the Authorization Server's Authorization Endpoint for authentication and
authorization. The Authorization Sever then issues an ID Token which
asserts the End-User's identity and an Access Token which allows the
client to access the End-User's information at protected resource
endpoints. Protected resource endpoints MAY perform different actions or
return different information based on the scopes associated with the
presented Access Token.
Clients MUST specify
how the Access Token and ID Token are to be returned is determined by the
<tt>response_type</tt>
parameter in the Authorization Request.
</p>
<a name="openid_scopes"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
OpenID Connect Scopes</h3>
<p>Clients MUST specify the desired scopes in an authorization request to
obtain an Access Token with the proper permissions.
</p>
<p>OpenID Connect clients use scopes as defined in 3.3 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0] to specify what
access privileges are requested for Access Tokens. The scopes associated
with Access Tokens determine what resources will be available when they
are used to access OAuth 2 protected endpoints. For OpenID Connect,
scopes request what information is to be made available from the
UserInfo Endpoint and to request a ID Token. OAuth 2.0 allows additional
scopes to be specified as extensions. This specification only describes
scopes that are part of openID Connect.
</p>
<p>OpenID Connect defines the following scopes:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>openid</dt>
<dd>REQUIRED. Informs the Authorization Server that
the client is making an OpenID request. If the <tt>openid</tt> scope is not specified, the Authorization
Server SHOULD treat the request as a generic OAuth 2.0 request, and
perform no OpenID Connect processing.
</dd>
<dt>profile</dt>
<dd>OPTIONAL. Requests default profile
information.
</dd>
<dt>email</dt>
<dd>OPTIONAL. Requests an email address.
</dd>
<dt>address</dt>
<dd>OPTIONAL. Requests an address.
</dd>
</dl></blockquote>
<p>Multiple scopes MAY be requested by creating a space delimited, case
sensitive list of scope values.
</p>
<p>The End-User may decline a scope request by the client.
</p>
<p>To increase conversion, a client may elect to only request a subset
of the information from the UserInfo Endpoint.
</p>
<p>
<p>The following is a non-normative example of a Scope
Request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>scope=openid profile email phone</pre></div>
<a name="protocol_flows"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Protocol Flows</h3>
<p>Authorization requests follow two main paths to obtain Access Tokens
and ID Tokens, the Implicit Flow and the Authorization Code Flow. The
flows determine how the Access Token and ID Token are returned to the
client. Access Token contain Resource Owners' credentials to protected
resources. As such, they SHOULD NOT be exposed.
</p>
<p>The Implicit Flow is mainly used by clients implemented in a browser
using a scripting language. The Access Token and ID Token are returned
directly to the client, which MAY expose them to the Resource Owner and
other applications which have access to the Resource Owner's user-agent.
The Authorization Server does not perform client authentication before
issuing the Access Token.
</p>
<p>The Authorization Code Flow returns an Authorization Code to the
client, which can then exchange it for an Access Token directly. This
provides the added benefit of not exposing the Access Token to the
Resource Owner and possibly other mailicious applications with access
to the Resource Owner's user-agent. The Authorization Server can also
authenticate the client before exchanging the Authorization Code for an
Access Token. The Authorization Code flow is suitable for clients that
can securely maintain a client secret between themselves and the
Authorization server whereas the Implicit flow is suitable for clients
that cannot.
</p>
<a name="retrieving_code_token"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2.1"></a><h3>4.2.1.
How To Get An Authorization Code, Access Token, and ID Token</h3>
<p>To use the Implicit Flow, the client simply requests for an Access
Token to be returned in the Authorization Request. To use the
Authorization Code Flow, the client requests for an Authorization Code
to be returnd in the Authorization Request. The Authorization Request
contains the parameter, <tt>response_type</tt>,
which specifies which values are to be returned.
</p>
<p>The <tt>response_type</tt> is a space, delimited,
case sensitive list of string values. Acceptable values include
<tt>code</tt>, <tt>token</tt>,
and <tt>id_token</tt>. The ordering of the values
is not considered. The value <tt>code</tt> returns
an Authorization Code in the <tt>code</tt>
parameter of the Authorization Response. The value <tt>token</tt> returns an Access Token in the <tt>access_token</tt> parameter of the Authorization
Response. The value <tt>id_token</tt> returns and
ID Token in the <tt>id_token</tt> parameter of the
Authorization Response.
</p>
<p>The following
<tt>request_type</tt> combinations are supported:
</p>
<ul class="text">
<li><tt>code</tt>
</li>
<li><tt>code id_token</tt>
</li>
<li><tt>token</tt>
</li>
<li><tt>token id_token</tt>
</li>
<li><tt>code token</tt>
</li>
<li><tt>code token id_token</tt>
</li>
</ul><p>
The client can then use the Authorization Code, Access Token, or ID
Token.
</p>
<a name="code_flow"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2.2"></a><h3>4.2.2.
Authorization Code Flow</h3>
<p>The Authorization Code Flow goes through the following
steps.
</p>
<p></p>
<ol class="text">
<li>Client prepares an Authorization Request containing the desired
request parameters.
</li>
<li>Client sends a request to the Authorization Server.
</li>
<li>Authorization Server Authenticates the End-User
</li>
<li>Authorization Server Obtains the End-User
Consent/Authorization
</li>
<li>Authorization Server Sends the End-User back to the Client with
an Authorization Code
</li>
<li>Client requests Assertion using the Authorization Code at the
<a class='info' href='#token_ep'>Token Endpoint<span> (</span><span class='info'>Token Endpoint</span><span>)</span></a>
</li>
<li>Client receives Assertion which contains an Access Token and ID
Token in the response body
</li>
<li>(OPTIONAL) Client validates the ID Token at the <a class='info' href='#check_id_ep'>Check ID Endpoint<span> (</span><span class='info'>Check ID Endpoint</span><span>)</span></a>
</li>
<li>(OPTIONAL) Client receives ID Token Response with the End-Users's
identity
</li>
<li>(OPTIONAL) Client accesses the <a class='info' href='#userinfo_ep'>UserInfo Endpoint<span> (</span><span class='info'>UserInfo Endpoint</span><span>)</span></a> with the Access
Token
</li>
<li>(OPTIONAL) Client receives UserInfo Response
</li>
</ol><p>Note that in each step, the party that receives a message
MUST verify it according to the verification rule set in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<a name="implicit_flow"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2.3"></a><h3>4.2.3.
Implicit Flow</h3>
<p>The implicit flow follows the following steps:
</p>
<p></p>
<ol class="text">
<li>Client prepares an Authorization Request containing the desired
request parameters.
</li>
<li>Client sends a request to the Authorization Server.
</li>
<li>Authorization Server Authenticates the End-User
</li>
<li>Authorization Server Obtains the End-User
Consent/Authorization
</li>
<li>Authorization Server Sends the End-User back to the Client with
an Access Token and an ID Token if requested
</li>
<li>(OPTIONAL) Client validates the ID Token at the <a class='info' href='#check_id_ep'>Check ID Endpoint<span> (</span><span class='info'>Check ID Endpoint</span><span>)</span></a>
</li>
<li>(OPTIONAL) Client receives ID Token Response with the End-Users's
identity
</li>
<li>(OPTIONAL) Client accesses the <a class='info' href='#userinfo_ep'>UserInfo Endpoint<span> (</span><span class='info'>UserInfo Endpoint</span><span>)</span></a> with the Access
Token
</li>
<li>(OPTIONAL) Client receives UserInfo Response
</li>
</ol><p>Note that in each step, the party that receives a message
MUST verify it according to the verification rule set in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<a name="auth_request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.
Authorization Request</h3>
<p>When the user wishes to access a Protected Resource, and the
End-User Authorization has not yet been obtained, the Client
prepares an Authorization Request to the authorization endpoint.
</p>
<p>Authorization servers MUST require the use of a transport-layer
security mechanism at the Authorization Endpoint. The Authorization
Server MUST support TLS 1.2 as described in <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and MAY support other transport-layer
mechanisms with equivalent security.
</p>
<p>Authorization servers MUST support the use of the HTTP "GET" and
"POST" methods defined in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] at the
Authorization Endpoint.
</p>
<p>Clients MAY use the HTTP "GET" or "POST" method to send the
Authorization Request to the Authorization Server. If using the HTTP
"GET" method, the request parameters are serialized using URI query
string serialization as defined in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]. If using the HTTP "POST" method,
the request parameters are added to the HTTP request entity-body using
"application/x-www-form-urlencoded" format.
</p>
<a name="rf_prep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1"></a><h3>4.3.1.
Client prepares an Authorization Request</h3>
<p>The client prepares an Authorization Request to the Authorization
Endpoint with the request parameters using the HTTP "GET" or "POST"
method. The scheme used in the Authorization URL MUST be HTTPS.
</p>
<p>The required Authorization Request parameters are as follows:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>A space delimited, case sensitive list
of values that specifies whether the Access Token, Authorization
Code, and ID Token are to be returned. As described in
<a class='info' href='#retrieving_code_token'>How To Get An Authorization Code, Access Token, and ID Token<span> (</span><span class='info'>How To Get An Authorization Code, Access Token, and ID Token</span><span>)</span></a>
, the following values are supported:
<ul class="text">
<li><tt>code</tt>
</li>
<li><tt>code id_token</tt>
</li>
<li><tt>token</tt>
</li>
<li><tt>token id_token</tt>
</li>
<li><tt>code token</tt>
</li>
<li><tt>code token id_token</tt>
</li>
</ul>
</dd>
<dt>client_id</dt>
<dd>The client identifier.
</dd>
<dt>scope</dt>
<dd>It MUST include <tt>openid</tt>
as one of the strings. Other values that MAY be included are
<tt>profile</tt>, <tt>email</tt>,
<tt>address</tt>, and <tt>PPID</tt>.
The values specify an additive list of claims that are returned
by the UserInfo Endpoint as described by <a class='info' href='#openid_scopes'>OpenID Connect Scopes<span> (</span><span class='info'>OpenID Connect Scopes</span><span>)</span></a>.
</dd>
<dt>redirect_uri</dt>
<dd>A redirection URI where the response
will be sent.
</dd>
<dt>nonce</dt>
<dd>A random, unique string value used
to mitigate replay attacks.
</dd>
</dl></blockquote>
<p>The request can contain the following optional parameters:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>state</dt>
<dd>An opaque value used to maintain state
between the request and the callback.
</dd>
<dt>request</dt>
<dd>A <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT] encoded
<a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID
Request Object</a>.
</dd>
<dt>request_uri</dt>
<dd>A URL that points to an <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID
Request Object</a>.
</dd>
<dt>display</dt>
<dd>A string value that specifies
how the Authorization Server displays the authentication page to
the user. The following values are supported: <tt>none</tt> or <tt>scopes</tt>.
Refer to <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] for
more information.
</dd>
<dt>prompt</dt>
<dd>A space delimited list that can contain
<tt>login</tt>, <tt>consent</tt>,
and <tt>select_account</tt>. Refer to <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] for
more information
</dd>
<dt>audience</dt>
<dd>The identifier of the target audience for
an ID token.
</dd>
</dl></blockquote>
<p>There are three methods to construct and send the request to the
authorization endpoint:
</p>
<blockquote class="text"><dl>
<dt>a.</dt>
<dd>Simple Request Method
</dd>
<dt>b.</dt>
<dd>Request Parameter Method
</dd>
<dt>c.</dt>
<dd>Request File Method
</dd>
</dl></blockquote>
<p>The Simple Request Method is used in simple cases when default
UserInfo and ID Token claims are desired and requests and responses
do not need to be signed or encrypted.
</p>
<p>The Request Parameter Method is used by sending an OpenID Request
Object when the client desires to retrieve a different set of
UserInfo and ID Token claims. The request parameter method also
allows requests and responses to be signed or encrypted.
</p>
<p>The Request Rile Method works similar to the Request Parameter
Method but differs in that it sends an URL as a reference to the
OpenID Request Object. It enables large requests to be sent
securely and compactly even on browsers with limited capabilities.
Clients SHOULD use the request file method to minimize the request
size.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.1"></a><h3>4.3.1.1.
Simple Request Method</h3>
<p>The Client prepares an Authorization Request to the
Authorization endpoint using the appropriate parameters. If using
the HTTP "GET" method, the request parameters are serialized using
URI query string serialization as defined in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]. If using
the HTTP "POST" method, the request parameters are added to the HTTP
request entity-body using "application/x-www-form-urlencoded"
format.
</p>
<p>
<p>The following is a non-normative example of an
Authorization Request URL. Note that the line wraps within the
values are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj</pre></div>
<a name="norm_req"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.1.1"></a><h3>4.3.1.1.1.
Client sends a request to the Authorization Server</h3>
<p>Having constructed the Authorization Request, the client it
to the HTTPS End-User Authorization Endpoint. This
MAY happen via HTTPS redirect, hyperlinking, or any other means
of directing the User-Agent to the Authorization Endpoint URL.
</p>
<p>Following is a non-normative example using HTTP redirect.
Note: Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
</pre></div>
<a name="req_param_method"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.2"></a><h3>4.3.1.2.
Request Parameter Method</h3>
<p>The Client prepares an Authorization Request to the
Authorization Endpoint using the appropriate HTTP parameters
serialization. The client SHOULD construct the request using the
HTTP "POST" method, but MAY use the HTTP "GET" method.
</p>
<p>The Authorization Request MUST include the
<tt>request</tt> parameter defined in the <a class='info' href='#rf_prep'>Client Prepares an Authorization Request<span> (</span><span class='info'>Client prepares an Authorization Request</span><span>)</span></a>
section. The Authorization Request MUST NOT include the
<tt>request_uri</tt> parameter.
</p>
<p>The <tt>request</tt> parameter is a
<a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT] encoded <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID
Request Object</a>
which contains the Authorization Request and also
specifies the content and format of
the responses returned from the UserInfo and Check ID
Endpoints. The JWT object MAY be signed or signed and encrypted via
<a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS] and <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE]
respectively, thereby providing authentication, integrity,
non-repudiation and/or confidentiality.
</p>
<p>All Authorization Request parameters that are part of the
Authorization Request excluding the <tt>request</tt>
and <tt>request_uri</tt>
parameters MUST also be <a href='http://openid.net/specs/openid-connect-messages-1_0.html#js'>JSON
Serialized</a> into the <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID Request Object</a> with the same values. This allows
the client to send signed and/or encrypted requests to the
Authorization Server and maintain conformance to OAuth 2.0.
</p>
<p>
<p>The following is a non-normative example of an
OpenID Request Object before JWT encoding. Note that the line
wraps within the values are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.com/cb",
"scope": "openid profile",
"state": "af0ifjsldkj",
"userinfo":
{
"claims":
{
"name": null,
"nickname": {"optional": true},
"email": null,
"verified": null,
"picture": {"optional": true},
},
"format": "signed"
}
"id_token":
{
"max_age": 86400,
"iso29115": "2"
}
}</pre></div>
<p>The following is a non-normative example of a <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT] encoded OpenID Request Object. Note
that the line wraps within the values are for display purpose
only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
JWT algorithm = HS256
HMAC HASH Key = 'aaa'
JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}"
JSON Encoded Payload = "{"response_type":"code id_token",
"client_id":"s6BhdRkqt3",
"redirect_uri":"https://client.example.com/cb",
"scope":"openid profile",
"state":"af0ifjsldkj",
"userinfo":{"claims":{"name":null,"nickname":{"optional":true},
"email":null,"verified":null,
"picture":{"optional":true}},"format":"signed"},
"id_token":{"max_age":86400,"iso29115":"2"}}"
JWT = eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ
SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI
HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zI
jp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiO
m51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sI
mZvcm1hdCI6InNpZ25lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvM
jkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
</pre></div>
<p>
<p>The following is a non-normative example of an
Authorization Request with the OpenID Request Method. Note that
the line wraps within the values are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://server.example.com/authorize?
response_type=code%02id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbW
UiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcm
lmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ2
5lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqR
grbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY</pre></div>
<a name="request_req"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.2.1"></a><h3>4.3.1.2.1.
Client Sends a Request to the Authorization Server</h3>
<p>Having constructed the Authorization Request, the client sends
it to the HTTPS Authorization Endpoint. This
MAY happen via HTTPS redirect, hyperlinking, or any other means
of directing the User-Agent to the Authorization Endpoint.
</p>
<p>Following is a non-normative example using HTTP redirect.
Note: Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbW
UiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcm
lmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ2
5lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqR
grbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
</pre></div>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.3"></a><h3>4.3.1.3.
Request File Method</h3>
<p>The Request File Method differs from the other methods in that
it uses a request file which contains a JSON encoded <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID Request Object</a>. It then sends the request file URL as
part of the Authorization Request.
</p>
<p>The Client prepares an Authorization Request using the desired
HTTP "GET" or "POST" method. The Client SHOULD use the HTTP "GET"
method, but MAY use the HTTP "POST" method.
</p>
<p> The Authorization Request MUST NOT include the
<tt>request</tt> parameter. The Authorization
Request MUST include the <tt>request_uri</tt>
parameter which is a globally reachable URL. The contents of the URL
is a JWT which is a <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID Request Object</a>.
</p>
<p>All Authorization Request parameters
that are part of the Authorization Request excluding the
<tt>request</tt> parameter MUST also be <a href='http://openid.net/specs/openid-connect-messages-1_0.html#js'>JSON
Serialized</a> into the <a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID Request Object</a> with the same values. This allows
the client to send signed and/or encrypted requests to the
Authorization Server and maintain conformance to OAuth 2.0. The
<a href='http://openid.net/specs/openid-connect-messages-1_0.html#OpenIDReq'>OpenID Request Object</a> MAY
be signed and encrypted via <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS]
and <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE] respectively, thereby providing
authentication, integrity, non-repudiation and/or
confidentiality.
</p>
<p>
<p>Following is a non-normative example of a Request
File. Note that the line wraps within the values are for
display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF9
0b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczp
cL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJ
zdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbWUiOm51bGw
sIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcmlmaWVkIjp
udWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ25lZCJ9LCJ
pZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqRgrbrHkA1F
Z5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
}</pre></div>
<a name="rurl_create"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.3.1"></a><h3>4.3.1.3.1.
Client Obtains the URL of the Request File</h3>
<p>The Client then records the Request File either locally or
remotely and obtains the Request URI, <tt>"request_uri"</tt>.
</p>
<p>Optionally, the Authorization Server may provide the Request
File registration service at the Request Registration Endpoint,
which allows the Client to register the Request File and obtain
the URL for it in exchange. This is especially useful for the
cases when the RP is behind the firewall or lives on a client
device that cannot be accessed from the Authorization
Server.
</p>
<a name="art_req"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.3.2"></a><h3>4.3.1.3.2.
Client Sends a Request to Authorization Server via HTTPS Redirect</h3>
<p>The Client sends the Authorization Request to the Authorization
Endpooint.
</p>
<p>The entire URL MUST NOT exceed 512 bytes.
</p>
<p>Following is a non-normative example. Note: Line
wraps are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://server.example.com/authorize
?response_type=code%20id_token
&cliend_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Frf%2Ejs
&state=af0ifjsldkj&scope=openid</pre></div>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.1.3.3"></a><h3>4.3.1.3.3.
Authorization Server Fetches the Request File</h3>
<p>Upon receipt of the Request, the Authorization Server MUST
send a GET request to the <tt>request_uri</tt>
to retrieve the content unless it is already cached and parse it
to recreate the authorization request parameters.
</p>
<p>Following is a non-normative example of this fetch
process. Note: Line wraps are for display purpose
only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /rf.js HTTP/1.1
Host: client.example.com</pre></div>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.2"></a><h3>4.3.2.
Authorization Server Authenticates the End-User</h3>
<p>The Authorization Server validates the request to ensure all
required parameters are present and valid. If the request is valid,
the authorization server MUST authenticate the End-User. The way in
which the authorization server authenticates the End-User (e.g.
username and password login, session cookies) is beyond the scope of
this specification. An authentication user interface MAY be displayed
by the Authorization Server depending on the authentication method
used.
</p>
<p>The Authorization Server MUST attempt to authenticate the
user in the following cases:
</p>
<ul class="text">
<li>The End-User is not already authenticated by the Authorization
Server.
</li>
<li>The Authorization Request contains the <tt>prompt</tt> parameter with the value "login". The
Authorization Server MUST reauthenticate the user
even if the user is already authenticated.
</li>
</ul>
<p>The Authorization Server MUST NOT attempt authentication
in the following cases:
</p>
<ul class="text">
<li>The Authorization Request contains the <tt>"display"</tt> parameter with the value "none".
The Authorization Server MUST return an error if the user is
unauthenticated.
</li>
</ul>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.3"></a><h3>4.3.3.
Authorization Server Obtains the End-User Consent/Authorization</h3>
<p>Once the user is authenticated, the Authorization Server MUST
obtain an authorization decision. This MAY be done by presenting the
user with a dialogue that allows the user to recognize what he is
consenting to and obtain his consent or by establishing approval via
other means (for example, via previous administrative approval).
</p>
<p>The Authorization Server MUST attempt to request authorization
from the user in the following cases:
</p>
<ul class="text">
<li>The End-User has not pre-authorized the client for the
authorization request.
</li>
<li>The Authorization Request contains the <tt>prompt</tt> parameter with the value "consent". The
Authorization Server MUST request user authorization even if the
user has previously authorized the client.
</li>
</ul>
<p>The Authorization Server MUST NOT request user authorization in the
following cases:
</p>
<ul class="text">
<li>The Authorization Request contains the <tt>"display"</tt> parameter with the value "none".
The Authorization Server MUST return an error if the user has
not pre-authorized the client.
</li>
</ul>
<a name="art_res"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.4"></a><h3>4.3.4.
Authorization Server Sends the End-User Back to the Client </h3>
<p>Once the authorization is determined, the Authorization Server
returns a positive or negative response.
</p>
<a name="art_res_ok"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.4.1"></a><h3>4.3.4.1.
End-User Grants Authorization</h3>
<p>If the resource owner grants the access request, the
Authorization Server issues an Authorization Response and delivers it
to the client by adding the response parameters to redirection URI
specified in the Authorization Request using the
"application/x-www-form-urlencoded" format.
</p>
<p>If the <tt>response_type</tt> parameter in the
Authorization Request includes the string value "code", the
following response parameters are included:
</p>
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The Authorization Code.
</dd>
</dl></blockquote><p>
Upon receipt of the <tt>"code"</tt>, the
Client requests an Assertion that includes the <tt>"access_token"</tt> and other variables. The
requests and responses are described in the <a class='info' href='#token_ep'>Token endpoint<span> (</span><span class='info'>Token Endpoint</span><span>)</span></a> section.
</p>
<p>If the <tt>response_type</tt> parameter in the
Authorization Request includes the string value "token", the
following response parameters are included :
</p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access Token
</dd>
<dt>token_type</dt>
<dd>REQUIRED. This specification only
supports the <a class='info' href='#OAuth.2.0.Bearer'>Bearer
Token<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] scheme. As such, this value MUST be set to
"<tt>Bearer</tt>".
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The lifetime in seconds of
the Access Token.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scopes of the issued Access
Token.
</dd>
</dl></blockquote>
<p>If the <tt>response_type</tt> parameter in the
Authorization Request includes the string value "id_token", the
following response parameters are returned :
</p>
<blockquote class="text"><dl>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token of the for the
authentication session.
</dd>
</dl></blockquote>
<p>The response parameters MAY also be include:
</p>
<blockquote class="text"><dl>
<dt>state</dt>
<dd>REQUIRED if the <tt>state</tt>
parameter is present in the Authorization Request.
Set it to the exact value of the <tt>state</tt> parameter received from the
client.
</dd>
</dl></blockquote>
<p>No other parameter SHOULD be returned.
</p>
<p>If the <tt>response_type</tt> parameter in the
Authorization Request includes the string value "token" or
"id_token", all response parameters SHOULD be added to the fragment
component of the redirection URI. Otherwise, the response parameters
are added to the query component of the redirection URI.
</p>
<p>The following are some non-normative examples. Line wraps
are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj
HTTP/1.1 302 Found
Location: https://client.example.com/cb#
token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&state=af0ifjsldkj
HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&state=af0ifjsldkj
HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj
</pre></div>
<a name="authz_error"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3.4.2"></a><h3>4.3.4.2.
End-User Denies Authorization or Invalid Request</h3>
<p>If the user denies the authorization or the user authentication
fails, the authorization server MUST return the negative authorization
response as defined in <a class='info' href='#OpenID.Messages'>OpenID Connect
Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]. The authorization server returns the client to
the redirection URI specified in the authorization request
with the appropriate error parameters. No
other parameters SHOULD be returned.
</p>
<p>The error response parameters are the following:
</p>
<blockquote class="text"><dl>
<dt>error</dt>
<dd>REQUIRED. The error code.
</dd>
<dt>error_description</dt>
<dd>OPTIONAL. A human-readable UTF-8
encoded text description of the error.
</dd>
<dt>error_uri</dt>
<dd>OPTIONAL. A URI to a web page that
includes addtional information about the error.
</dd>
<dt>state</dt>
<dd>REQUIRED if the Authorization Request
included the <tt>state</tt> parameter. Set
to the exact value received from the client.
</dd>
</dl></blockquote>
<p>If the <tt>response_type</tt> parameter in the
Authorization Request includes the string value "token" or
"id_token", all error response parameters SHOULD be added to the
fragment component of the redirection URI. Otherwise, the response
parameters are added to the query component of the redirection URI.
</p>
<p>
<p>The following is a non-normative example. Line wraps
after the second line is for the display purpose
only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://client.example.com/cb?
error=invalid_request
&error_description=the%20request%20is%20not%20valid%20or%20malformed
&state=af0ifjsldkj</pre></div>
<a name="token_ep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Token Endpoint</h3>
<p>The Token endpoint handles requests for retrieving and refreshing
access tokens.
</p>
<p>Clients MUST use the HTTP "POST" method to make requests to the Token
endpoint. Request parameters are added to the HTTP request entity-body
using the <tt>application/x-www-form-urlencoded</tt>
format.
</p>
<p>Clients MAY provide authentication parameters in the request to the
Token endpoint as described in section 3.2 of <a class='info' href='#OpenID.Messages'>OpenID Connect Messages<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] and section
3.2.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>Authorization servers MUST support the use of the HTTP "POST"
method defined in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] at the
Token Endpoint.
</p>
<p>Authorization servers MUST require the use of a transport-layer
security mechanism. The authorization server MUST support TLS 1.2 as
described in <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and MAY support
other transport-layer mechanisms with equivalent security.
</p>
<p>All Token endpoint responses that contain tokens, secrets, or other
sensitive information MUST include the following HTTP response header
fields and values:
</p>
<p>
</p><br /><hr class="insert" />
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Header Name</th><th align="left">Header Value</th></tr>
<tr>
<td align="left">Cache-Control</td>
<td align="left">no-store</td>
</tr>
<tr>
<td align="left">Pragma</td>
<td align="left">no-cache</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> HTTP Response Headers and Values </b></font><br /></td></tr></table><hr class="insert" />
<p>
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Requesting an Access Token</h3>
<p>To retrieve an access token, a client MUST have an Authorization
Code obtained via the method as described in <a class='info' href='#code_flow'>Authorization Code Flow<span> (</span><span class='info'>Authorization Code Flow</span><span>)</span></a>.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.1"></a><h3>5.1.1.
Access Token Request</h3>
<p>To obtain an access token assertion, the client MUST send the
following parameters via HTTPS POST to the Token endpoint using
<tt>application/x-www-form-urlencoded</tt> format
in the HTTP request entity-body as specified in Section 4.1.3 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0]:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>grant_type</dt>
<dd>REQUIRED. A string "<tt>authorization_code</tt>".
</dd>
<dt>code</dt>
<dd>REQUIRED. The authorization code received
from the authorization server.
</dd>
<dt>redirect_uri</dt>
<dd>REQUIRED, if the
<tt>redirect_uri</tt>
parameter was included in the authorization request described
in Section 4.1.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0],
and their values MUST be identical.
</dd>
</dl></blockquote><p>
</p>
<p>If the client type is confidential or was issued client credentials
(or assigned other authentication requirements), the client MUST
authenticate with the authorization server as described in
Section 3.2.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>The client MAY authenticate by sending the <tt>client_id</tt> and <tt>client_secret</tt> using the HTTP Basic authentication scheme as
defined in <a class='info' href='#RFC2617'>RFC2617<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> [RFC2617]. Alternatively, the
client MAY send the following client credentials in the HTTP request-entity body:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier of the
client.
</dd>
<dt>secret_type</dt>
<dd>OPTIONAL. Specifies the client
authentication type which determines how the <tt>client_secret</tt> parameter is interpreted. It
can be one of "basic" or "JWT". The defaults value is "<tt>basic</tt>". If the value is "basic", the client
is performing symmetric key authentication as specified in OAuth
2.0. If the value is "JWT", the client is performing asymmetric
key authentication.
</dd>
<dt>client_secret</dt>
<dd>REQUIRED. The client secret. If the
secret_type is "<tt>basic</tt>", the value is
the pre-shared secret that was issued to the client during
client registration. If the "<tt>secret_type</tt>"
is "JWT", the value is the <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS]
signature of a JSON object containing one of the following
claims:
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The authorization code that was
issued by the authorization server.
</dd>
<dt>refresh_token</dt>
<dd>REQUIRED. The refresh token that
was issued.
</dd>
</dl></blockquote>
</dd>
</dl></blockquote><p>
</p>
<p>Authorization servers MUST support both forms of client authentication
at the Token Endpoint.
</p>
<p>The following is a non-normative example. Line wraps
after line 4 are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
</pre></div>
<p>
The authorization server MUST:
</p>
<p>
</p>
<ul class="text">
<li>
require client authentication for confidential clients or for any client issued
client credentials (or with other authentication requirements),
</li>
<li>
authenticate the client if client authentication is included and ensure the
authorization code was issued to the authenticated client,
</li>
<li>
verify that the authorization code is valid, and
</li>
<li>
ensure that the <tt>redirect_uri</tt> parameter is present if
the <tt>redirect_uri</tt> parameter was included in the initial
authorization request and that their
values are identical.
</li>
</ul><p>
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2"></a><h3>5.1.2.
Access Token Response</h3>
<p>Upon receipt of the Token Request, the Authorization Server MUST
return either a Positive or a Negative Assertion that corresponds to
the received Authorization Code.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2.1"></a><h3>5.1.2.1.
Positive Assertion</h3>
<p>A Positive Assertion response returns the "<tt>application/json</tt>"
media type and the response body is the Access Token Response of
the <a class='info' href='#OpenID.Messages'>OpenID Connect Messages
1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The assertion is a JSON structure which contains the
following values:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access Token.
</dd>
<dt>token_type</dt>
<dd>REQUIRED. Specifies the access token type.
This specification only supports the "Bearer" token type.
</dd>
<dt>id_token</dt>
<dd>REQUIRED if
<tt>scope</tt> in the Authorization
Request contains the value "openid". The ID Token associated with
the authentication session.
</dd>
<dt>refresh_token</dt>
<dd>OPTIONAL. The Refresh Token that can
be used to obtain a new Access Token.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The lifetime of the
Access Token in seconds.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the Access Token.
</dd>
</dl></blockquote>
<p>Following is a non-normative example of the Positive
Assertion:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}</pre></div>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2.2"></a><h3>5.1.2.2.
Error Response</h3>
<p>If the Token Request is invalid or unauthorized, the
Authorization Server constructs the response by returning the
Token Error Response defined in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] in the
entity body of the HTTP response using the <tt>application/json</tt>
media type with HTTP response code 400.
</p>
<p>Following is a non-normative example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}</pre></div>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Refreshing an Access Token</h3>
<p>To refresh an Access token that has expired, the client sends a
POST request to the Token endpoint with the following parameters in
the entity-body using the application/x-www-form-urlencoded
format:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>grant_type</dt>
<dd>REQUIRED. A string "refresh_token".
</dd>
<dt>refresh_token</dt>
<dd>
REQUIRED. The refresh token that was
issued in a previous Token endpoint request.
</dd>
<dt>scope</dt>
<dd>
REQUIRED. It MUST include <tt>openid</tt>
as one of the strings. Other values that MAY be included are
<tt>profile</tt>, <tt>email</tt>,
<tt>address</tt>, and <tt>PPID</tt>.
The values specify an additive list of claims that are returned by
the UserInfo endpoint.
</dd>
</dl></blockquote><p>The Authorization Server MUST verify the validity of the refresh
token.
</p>
<p>If the client type is confidential or was issued client credentials
(or assigned other authentication requirements), the client MUST
authenticate with the authorization server as described in
Section 3.2.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>The client MAY authenticate by sending the <tt>client_id</tt> and <tt>client_secret</tt> using the HTTP Basic authentication scheme as
defined in <a class='info' href='#RFC2617'>RFC2617<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> [RFC2617]. Alternatively, the
client MAY send the following client credentials in the HTTP
request-entity body:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier of the
client.
</dd>
<dt>secret_type</dt>
<dd>OPTIONAL. Specifies the client
authentication type which determines how the <tt>client_secret</tt> parameter is interpreted. It
can be one of "basic" or "JWT". The defaults value is "<tt>basic</tt>". If the value is "basic", the client
is performing symmetric key authentication as specified in OAuth
2.0. If the value is "JWT", the client is performing asymmetric
key authentication.
</dd>
<dt>client_secret</dt>
<dd>REQUIRED. The client secret. If the
secret_type is "<tt>basic</tt>", the value is
the pre-shared secret that was issued to the client during
client registration. If the "<tt>secret_type</tt>"
is "JWT", the value is the <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS]
signature of a JSON object containing one of the following
claims:
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The authorization code that was
issued by the authorization server.
</dd>
<dt>refresh_token</dt>
<dd>REQUIRED. The refresh token that
was issued.
</dd>
</dl></blockquote>
</dd>
</dl></blockquote><p>
</p>
<p>Authorization servers MUST support both forms of client authentication
at the Token Endpoint.
</p>
<p>The Authorization Server MUST verify the validity of the refresh
token.
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1.
Positive Assertion</h3>
<p>Upon successful verification of the refresh token, a positive
assertion response returns the "<tt>application/json</tt>"
media type and the response body is the Access Token Response of the
<a class='info' href='#OpenID.Messages'>OpenID Connect Messages
1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The assertion is a JSON structure which contains the
following values:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access token.
</dd>
<dt>token_type</dt>
<dd>REQUIRED. Specifies the access token type.
This specification only supports the "Bearer" token type.
</dd>
<dt>id_token</dt>
<dd>REQUIRED if
<tt>scope</tt> in the Authorization
Request contains the value "openid". The ID Token associated with
the authentication session.
</dd>
<dt>refresh_token</dt>
<dd>OPTIONAL. The Refresh Token that can
be used to obtain a new Access Token.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The lifetime of the
Access Token in seconds.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the Access Token.
</dd>
</dl></blockquote>
<p>Following is a non-normative example of the refresh
token request and response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3
&client_secret=some_secret12345
&grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&scope=openid
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "TlBN45jURg",
"token_type": "Bearer",
"refresh_token": "9yNOxJtZa5",
"expires_in": 3600,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}</pre></div>
<a name="userinfo_ep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
UserInfo Endpoint</h3>
<p>To obtain the additional attributes and tokens/assertions, the client
makes a GET or POST request to the UserInfo Endpoint as in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>Authorization Servers MUST require the use of a transport-layer
security mechanism. The authorization server MUST support TLS 1.2 as
described in <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and MAY support
other transport-layer mechanisms with equivalent security.
</p>
<p>Authorization servers MUST support the use of the HTTP "GET" and HTTP
"POST" methods defined in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] at the
UserInfo Endpoint.
</p>
<p>Authorization servers MUST be able to accept Access Tokens via
<a class='info' href='#OAuth.2.0.Bearer'>Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer]
specification.
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
UserInfo Request</h3>
<p>Client SHOULD send the UserInfo request defined in section 3.3 of
the <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]
either in HTTP GET or POST request.
</p>
<p>The request parameters are the following:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access Token obtained
from an OpenID Connect Authorization Request. This parameter MUST
NOT be sent if the Access Token is sent in the HTTP Authorization
header as described in Section 7.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0]. Access tokens sent in the
authorization header MUST be <a class='info' href='#OAuth.2.0.Bearer'>Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer]. If the client is
using the HTTP GET method, it SHOULD send the Access Token in the
authorization header.
The access_token MAY alternatively be sent in the message
body, as described in the <a class='info' href='#OAuth.2.0'>OAuth
2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> [OAuth.2.0] specification.
</dd>
<dt>schema</dt>
<dd>REQUIRED. The schema in which the data is to
be returned. The only defined value is <tt>openid</tt>.
If the value of this parameter is omitted, or not
<tt>openid</tt>, the response may be a
proprietary schema to support backwards compatibility.
A URL MAY be passed to define custom schemes not specified
by short names. Custom scheme names and responses are out
of scope for this specification.
</dd>
<dt>id</dt>
<dd>This identifier is reserved for backwards
compatibility. It MUST be ignored by the endpoint if the <tt>openid</tt> schema is used.
</dd>
</dl></blockquote>
<p>The following is a non-normative example. Line wraps are
for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /userinfo HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
access_token=SlAV32hkKG</pre></div>
<a name="id_res"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
UserInfo Response</h3>
<p>Upon receipt of the UserInfo request, the UserInfo endpoint MUST
return the JSON Serialization of the UserInfo response as in <a class='info' href='#OpenID.Messages'>OpenID Messages<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] in the HTTP response
body. The content-type of the HTTP response MUST be set to <tt>application/json</tt> if the response body is a text
JSON structure. If the JSON response is <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS]
signed or <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE] encrypted, then the
content-type MUST be set to <tt>application/jwt</tt>.
</p>
<p>Following is a non-normative example of such
response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 200 OK
Content-Type: application/json
{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}</pre></div>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2.1"></a><h3>6.2.1.
UserInfo Error Response</h3>
<p>When some error condition arises, the UserInfo endpoint returns
the JSON serialized Error Response defined in section 3.3.3 of <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] in the
entity body of the HTTP response using the <tt>application/json</tt>
media type with HTTP response code 400.
</p>
<p>
<p>Following is a non-normative example of an error
response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error":"invalid_request"
}
</pre></div>
<a name="check_id_ep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Check ID Endpoint</h3>
<p>The Check ID endpoint validates ID Tokens and returns the claims
of an issued ID Token in JSON text format. This endpoint is used by
clients that are not able to or do not wish to process ID Tokens.
Clients MAY treat ID Tokens as opaque values and use the Check ID
endpoint to validate and retrieve the claims associated with the ID
Token in plain text JSON format.
</p>
<p>Authorization Servers MUST require the use of a transport-layer
security mechanism. The authorization server MUST support TLS 1.2 as
described in <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and MAY support
other transport-layer mechanisms with equivalent security.
</p>
<p>Authorization servers MUST support the use of the HTTP "GET" and HTTP
"POST" methods defined in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] at the
Check ID Endpoint.
</p>
<p>Clients MAY use the HTTP "GET" or "POST" method to send the
Authorization Request to the Authorization Server. If using the HTTP
"GET" method, the request parameters are serialized using URI query
string serialization as defined in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages]. If using the HTTP "POST" method,
the request parameters are added to the HTTP request entity-body using
"application/x-www-form-urlencoded" format.
</p>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.
Check ID Requests</h3>
<p>The client prepares an Check ID Endpoint Request to the Check ID
Endpoint with the request parameters using the HTTP "GET" or "POST"
method. The scheme used in the Authorization URL MUST be HTTPS.
</p>
<p>The request parameters are as follows:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token obtained from an
OpenID Connect authorization request.
</dd>
</dl></blockquote><p>
<p>The Following is a non-normative example of a Check
ID request:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /check_id HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZX
J2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0cD
pcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1G
3liaTNOrfaeWYjuRCEPNXVtaazNQ
</pre></div>
<a name="intro_res"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.
Check ID Response</h3>
<p>The Check ID Endpoint MUST return the JSON serialized claims
associated with the ID Token as described in Check ID Response
section of <a class='info' href='#OpenID.Messages'>OpenID Messages<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] in
the HTTP response body. The content-type of the HTTP response MUST be
set to <tt>application/json</tt> if the response
body is a text JSON structure. If the JSON response is <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS] signed or <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE]
encrypted, then the content-type MUST be set to <tt>application/jwt</tt>.
</p>
<p>The following is a non-normative example of a response
from the Check ID endpoint:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 200 OK
Content-Type: application/json
{
"iss": "http://server.example.com",
"user_id": "248289761001",
"aud": "http://client.example.com",
"exp": 1311281970
}
</pre></div>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2.1"></a><h3>7.2.1.
Check ID Error Response</h3>
<p>When some error condition arises, the UserInfo endpoint returns
the JSON serialized Error Response defined in section 3.4.3 of <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages] in the
entity body of the HTTP response using the <tt>application/json</tt>
media type with HTTP response code 400.
</p>
<p>
<p>Following is a non-normative example of an error
response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error":"invalid_id_token"
}
</pre></div>
<a name="session_eps"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Session Management Endpoints</h3>
<p>The Session Management endpoints are specified in the <a class='info' href='#OpenID.Session'>OpenID Connect Session Management<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” September 2011.</span><span>)</span></a> [OpenID.Session]
specification.
</p>
<a name="disco_reg"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
Discovery and Registration</h3>
<p>Some OpenID Connect installations can use a pre-configured set of
OpenID Providers and/or Relying Parties. In those cases, it may not be
necessary to support dynamic discovery of information about identities
or services or dynamic registration of clients.
</p>
<p>However, if installations choose to support unanticipated
interactions between Relying Parties and OpenID Providers that do not
have pre-configured relationships, they SHOULD accomplish this by
implementing the facilities defined in the <a class='info' href='#OpenID.Discovery'>OpenID Connect Discovery 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” September 2011.</span><span>)</span></a> [OpenID.Discovery] and <a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client Registration
1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Ed., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” September 2011.</span><span>)</span></a> [OpenID.Registration] specifications.
</p>
<a name="security_considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
Security Considerations</h3>
<p>This specification references the security considerations defined in
<a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>In addition, the following list of attack vectors and remedies are
also considered.
</p>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.1"></a><h3>10.1.
Implicit Grant Flow Threats</h3>
<p>In the implicit grant flow, the access token is returned in the
fragment part of the client's redirect_uri through HTTPS, thus it is
protected between the OP and the User-Agent, and User-Agent and the
RP. The only the place it can be captured is the User-Agent where the
TLS session is terminated, and is possible if the User-Agent is
infested by malware.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
IANA Considerations</h3>
<p>This document makes no request of IANA.
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>12. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://self-issued.info/docs/draft-jones-json-web-encryption.html">JSON Web Encryption</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://tools.ietf.org/html/draft-jones-json-web-signature">JSON Web Signatures</a>,” April 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://tools.ietf.org/html/draft-jones-json-web-token">JSON Web Token</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.2.0">[OAuth.2.0]</a></td>
<td class="author-text">Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">OAuth 2.0 Authorization Protocol</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.2.0.Bearer">[OAuth.2.0.Bearer]</a></td>
<td class="author-text">Jones, M., Hardt, D., and D. Recordon, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer">OAuth 2.0 Protocol: Bearer Tokens</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Messages">[OpenID.Messages]</a></td>
<td class="author-text">Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-messages-1_0.html">OpenID Connect Messages 1.0</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Registration">[OpenID.Registration]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Ed., and M. Jones, “<a href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client
Registration 1.0</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Session">[OpenID.Session]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-session-1_0.html">OpenID Connect Session Management
1.0</a>,” September 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td>
<td class="author-text"><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2617.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2617.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2617.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,” RFC 5246, August 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</a>).</td></tr>
</table>
<a name="anchor21"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Footnotes</h3>
<p>
</p>
<a name="anchor22"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A.1"></a><h3>A.1.
Example JWT Values</h3>
<p>The JWT values used in the non-normative examples of this
specification are only place holders for actual JWT values. The
examples use "jwt_header.jwt_part2.jwt_part3" as the place holder
value. For an example of an actual JWT, refer to the <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT] specification.
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Acknowledgements</h3>
<p>The OpenID Community would like to thank the following people for the
work they've done in the drafting and editing of this specification.
</p>
<p></p>
<blockquote class="text">
<p>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
</p>
<p>Breno de Medeiros (breno@gmail.com), Google
</p>
<p>George Fletcher (gffletch@aol.com), AOL
</p>
<p>Hideki Nara (hideki.nara@gmail.com), Takt Communications
</p>
<p>John Bradley (jbradely@mac.com), Protiviti Government
Services
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp)), Nomura Research Institute,
Ltd.
</p>
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan
</p>
</blockquote>
<a name="anchor24"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.
Document History</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>-05</p>
<ul class="text">
<li>Changed check_session to check_id.
</li>
<li>schema=openid now required when requesting UserInfo.
</li>
<li>Removed display values popup, touch, and mobile, since not well defined.
</li>
<li>Resolve issue #135, clarifying that the access_token MAY
be sent in the message body.
</li>
</ul>
<p>-04 </p>
<ul class="text">
<li>Changes associated with renaming "Lite" to "Basic Client"
and replacing "Core" and "Framework" with "Messages" and
"Standard".
</li>
<li>Numerous cleanups, including updating references.
</li>
</ul>
<p>-03 </p>
<ul class="text">
<li>Added secret_type to the Token endpoint.
</li>
<li>Minor edits to the samples.
</li>
</ul>
<p>-02 </p>
<ul class="text">
<li>Incorporates feedback from Nat Sakimura.
</li>
</ul>
<p>-01 </p>
<ul class="text">
<li>First Draft that incorporates the merge of the Core and Framework
specs.
</li>
</ul>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Nat Sakimura (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute,
Ltd.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Protiviti Government
Services</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:jbradley@mac.com">jbradley@mac.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Breno de Medeiros</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Google</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:breno@google.com">breno@google.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft Corporation</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Edmund Jay</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">MGI1</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ejay@mgi1.com">ejay@mgi1.com</a></td></tr>
</table>
</body></html>