<!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 02</title>
<meta http-equiv="Expires" content="Thu, 18 Aug 2011 23:28:02 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect
Standard 1.0 - draft 02">
<meta name="generator" content="xml2rfc v1.34 (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">August 18, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect
Standard 1.0 - draft 02</h1>
<h3>Abstract</h3>
<p>OpenID Connect Standard 1.0 is a HTTP protocol binding of 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="#code_flow">4.1.</a>
Authorization Code Flow<br />
<a href="#rf_prep">4.1.1.</a>
Client prepares an Authorization Request<br />
<a href="#anchor7">4.1.2.</a>
Authorization Server Authenticates the End-User<br />
<a href="#anchor8">4.1.3.</a>
Authorization Server Obtains the End-User Consent/Authorization<br />
<a href="#art_res">4.1.4.</a>
Authorization Server Sends the End-User Back to the Client <br />
<a href="#anchor9">4.1.5.</a>
Client Request Assertion Using the "Code"<br />
<a href="#implicit_flow">4.2.</a>
Implicit Flow<br />
<a href="#implicit_prep">4.2.1.</a>
Client Prepares an Authorization Request URL <br />
<a href="#implicit_req">4.2.2.</a>
Client Sends a Request to the Authorization Server<br />
<a href="#anchor10">4.2.3.</a>
Authorization Server Authenticates the End-User<br />
<a href="#anchor11">4.2.4.</a>
Authorization Server Obtains the End-User Consent/Authorization<br />
<a href="#implicit_res">4.2.5.</a>
Authorization Server Sends the End-User Back to the Client <br />
<a href="#token_ep">5.</a>
Token Endpoint<br />
<a href="#anchor12">5.1.</a>
Requesting an Access Token<br />
<a href="#anchor13">5.1.1.</a>
Access Token Request<br />
<a href="#anchor14">5.1.2.</a>
Access Token Response<br />
<a href="#anchor17">5.2.</a>
Refreshing an Access Token<br />
<a href="#anchor18">5.2.1.</a>
Positive Assertion<br />
<a href="#userinfo_ep">6.</a>
UserInfo Endpoint<br />
<a href="#anchor19">6.1.</a>
UserInfo Request<br />
<a href="#id_res">6.2.</a>
UserInfo Response<br />
<a href="#anchor20">6.2.1.</a>
UserInfo Error Response<br />
<a href="#checksession_ep">7.</a>
Check Session Endpoint<br />
<a href="#anchor21">7.1.</a>
Client Session Requests<br />
<a href="#intro_res">7.2.</a>
Check Session Response<br />
<a href="#anchor22">7.2.1.</a>
Check Session Error Response<br />
<a href="#session_eps">8.</a>
Session Management Endpoints<br />
<a href="#security_considerations">9.</a>
Security Considerations<br />
<a href="#anchor23">9.1.</a>
Implicit Grant Flow Threats<br />
<a href="#IANA">10.</a>
IANA Considerations<br />
<a href="#rfc.references1">11.</a>
Normative References<br />
<a href="#anchor25">Appendix A.</a>
Footnotes<br />
<a href="#anchor26">A.1.</a>
Example JWT Values<br />
<a href="#anchor27">Appendix B.</a>
Acknowledgements<br />
<a href="#anchor28">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.Core'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” July 2011.</span><span>)</span></a> [OpenID.Core] 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,” July 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Artifact</dt>
<dd>A small string that acts as a reference to
the larger body of data.
</dd>
<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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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 so that the Client MAY register
the Request File to obtain the Request URI.
</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 distribute, collaborative, hypermedia
systems. It's ubiquitousness makes it an ideal protocol for use by
OpenID Connect. This specification describes the binding of the HTTP
protocol with the the various endpoints described in <a class='info' href='#OpenID.Messages'>OpenID Connect Messages<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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>Authorization requests follow two paths, the authorization code flow
and the implicit grant flow. The authorization code flow is suitable for
clients that can securely maintain client state between itself and the
authorization server whereas the implicit grant flow is suitable for
clients that cannot.
</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.1"></a><h3>4.1.
Authorization Code Flow</h3>
<p>The authorization code protocol 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
</li>
<li>Client receives Assertion in the response body
</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>
</li>
<li>(OPTIONAL) Client receives UserInfo Response
</li>
</ol><p>Note that in each step, the party that receives 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages].
</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.1.1"></a><h3>4.1.1.
Client prepares an 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>The scheme used in the Authorization URL MUST be HTTPS.
</p>
<p>This binding further constrains the following request
parameters
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>It MUST include <tt>code</tt>.
</dd>
</dl></blockquote>
<p>Other required parameters in the request include the
following:
</p>
<p></p>
<blockquote class="text"><dl>
<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.
</dd>
<dt>redirect_uri</dt>
<dd>A redirection URI where the response
will be sent.
</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-framework-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-framework-1_0.html#OpenIDReq'>OpenID
Request Object</a>.
</dd>
<dt>display</dt>
<dd>A string value that can be <tt>none</tt>, <tt>popup</tt>, or
<tt>mobile</tt>. Refer to <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages] for
more information
</dd>
<dt>nonce</dt>
<dd>A random, unique string value.
</dd>
<dt>audience</dt>
<dd>The identifier of the target audience for
an ID token.
</dd>
</dl></blockquote>
<p>There are three methods to send the request to the authorization
endpoint: a) query parameters method b) request parameter method,
and c) request file method.
</p>
<p>The query parameters 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 enrypted.
</p>
<p>The request file method works similar to the request parameter
method but differs in that it sends an URL as a reference to the
OpendID 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>
<p>Authorization servers MUST support the use of the HTTP "GET"
method as define 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] and MAY
support the "POST" method at the authorization endpoint.
</p>
<p>If using the HTTP "GET" method, the 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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="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.1.1.1"></a><h3>4.1.1.1.
Query Parameters Method</h3>
<p>The Client prepares an Authorization Request to the
Authorization endpoint using the appropriate parameters with <a href='http://openid.net/specs/openid-connect-messages-1_0.html#qss'>HTTP
query string serialization</a>.
</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
&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.1.1.1.1"></a><h3>4.1.1.1.1.
Client sends a request to the Authorization Server</h3>
<p>Having constructed the URL, the client sends the End-User to
the HTTPS End-User Authorization Endpoint using the URL. This
MAY happen via HTTPS redirect, hyperlinking, or any other means
of directing the User-Agent to the URL.
</p>
<p>The Client SHOULD send the request using the HTTPS GET
method, but MAY send it via the HTTPS POST if the authorization
server supports it as defined in <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>
</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
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
</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.1.1.2"></a><h3>4.1.1.2.
Request Parameter Method</h3>
<p>The Client prepares an Authorization Request to the
Authorization endpoint using the appropriate HTTP parameters
serialization. The request parameters 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 <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-framework-1_0.html#OpenIDReq'>OpenID
Request Object</a> which specifies the content and format of
the response returned from the UserInfo endpoint and ID Token
endpoint. 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., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.</span><span>)</span></a> [JWE]
respectively, thereby providing authentication, integrity,
non-repudiation and/or confidentiality.
</p>
<p>Request parameters in the <a href='http://openid.net/specs/openid-connect-framework-1_0.html#OpenIDReq'>OpenID
Request Object</a> takes precedence over query parameters.
</p>
<p>
<p>The following is a non-normative example of an
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>{
"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 = "{"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.eyJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uY
WwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYWwiOnRydWV9fSwiZm9ybWF0Ijoic2lnbmV
kIn0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJpc28yOTExNSI6IjIifX0.DeWt4Quf3OQFB58gYpwNrXhW2L32KLBFbghu7-NZXso</pre></div>
<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/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uY
WwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYWwiOnRydWV9fSwiZm9ybWF0Ijoic2lnbmVkIn0sImlk
X3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJpc28yOTExNSI6IjIifX0.DeWt4Quf3OQFB58gYpwNrXhW2L32KLBFbghu7-NZXso</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.1.1.2.1"></a><h3>4.1.1.2.1.
Client Sends a Request to the Authorization Server</h3>
<p>Having constructed the URL, the client sends the End-User to
the HTTPS End-User Authorization Endpoint using the URL. This
MAY happen via HTTPS redirect, hyperlinking, or any other means
of directing the User-Agent to the URL.
</p>
<p>The Client MAY send the request using the HTTP GET method,
but MUST send it via the HTTP POST if the authorization server
supports it as defined in <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>
</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
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uY
WwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYWwiOnRydWV9fSwiZm9ybWF0Ijoic2lnbmVkIn0sImlk
X3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJpc28yOTExNSI6IjIifX0.DeWt4Quf3OQFB58gYpwNrXhW2L32KLBFbghu7-NZXso
</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.1.1.3"></a><h3>4.1.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 all the authorization
request parameters. It sends the request file URL to the
authorization endpoint instead of the request parameters.
</p>
<p>The Client prepares a file with a JSON serialized Authorization
Request described in <a class='info' href='#OpenID.Messages'>OpenID Connect
Messages 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages] with a globally reachable URL. Optionally, the
request may contain other extension parameters. It 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., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 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>{
"response_type": "code",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb",
"scope": "openid",
"state": "af0ifjsldkj"
}</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.1.1.3.1"></a><h3>4.1.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.1.1.3.2"></a><h3>4.1.1.3.2.
Client Sends a Request to Authorization Server via HTTPS Redirect</h3>
<p>The Client sends the user to the HTTPS End-User Authorization
Endpoint through the HTTP 302 redirect with the following
parameters
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>REQUIRED. <tt>"code".</tt>
</dd>
<dt>client_id</dt>
<dd>REQUIRED. The Client Identifier.
</dd>
<dt>request_uri</dt>
<dd>REQUIRED. The Request URI.
</dd>
<dt>state</dt>
<dd>OPTIONAL. An opaque value used by the
Client to maintain state between the request and callback.
If provided, the Authorization Server MUST include this
value when redirecting the user-agent back to the Client.
Clients are strongly advised to use this variable to relate
the request and response.
</dd>
</dl></blockquote>
<p>The entire URL MUST NOT exceed 512 bytes.
</p>
<p>The Client SHOULD send the request using the HTTP GET method,
but MAY send it via the HTTP POST if the authorization server
supports it as defined in <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>
</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&cliend_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Frf%2Ejs
&state=A02FB8C</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.1.1.3.3"></a><h3>4.1.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="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.1.2"></a><h3>4.1.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.
</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.4.1.3"></a><h3>4.1.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>
<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.1.4"></a><h3>4.1.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.1.4.1"></a><h3>4.1.4.1.
End-User Grants Authorization</h3>
<p>If the resource owner grants the access request, the
authorization server issues an Authorization code and delivers it
to the client by adding the following parameters to the query
component of the redirection URI using the
"application/x-www-form-urlencoded" format:</p>
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The Authorization Code.
</dd>
<dt>state</dt>
<dd>REQUIRED if the <tt>"state"</tt>
parameter in the request. Set to the exact value of the <tt>"state"</tt> parameter received from the
client.
</dd>
</dl></blockquote>
<p>No other parameter SHOULD be returned. The entire URL MUST NOT
exceed 512 bytes.
</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?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&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.1.4.2"></a><h3>4.1.4.2.
End-User Denies Authorization or Invalid Request</h3>
<p>If the user denies the authorization or the user authentication
fails, the 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages]. The authorization server returns the client
the the redirection URI specified in the authorization request
with the appropriate error parameters in the HTTP query string. No
other parameters SHOULD be returned.
</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="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.4.1.5"></a><h3>4.1.5.
Client Request Assertion Using the "Code"</h3>
<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>
<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"></a><h3>4.2.
Implicit Flow</h3>
<p>The implicit grant 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
</li>
</ol>
<a name="implicit_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.2.1"></a><h3>4.2.1.
Client Prepares an Authorization Request URL </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 URL using URI query string
serialization as defined in <a class='info' href='#OpenID.Messages'>OpenID
Connect Messages 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The scheme used in the Authorization URL MUST be HTTPS.
</p>
<p>This binding further constrains the following request
parameters
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>It MUST include <tt>token</tt>.
</dd>
</dl></blockquote>
<p>The request MUST contain the other required parameters and MAY
contain optional parameters as defined in the <a class='info' href='#rf_prep'>preparing an authorization request<span> (</span><span class='info'>Client prepares an Authorization Request</span><span>)</span></a>
section.
</p>
<a name="implicit_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.2.2"></a><h3>4.2.2.
Client Sends a Request to the Authorization Server</h3>
<p>Having constructed the URL, the client sends the End-User to the
HTTPS End-User Authorization Endpoint using the URL. This MAY happen
via HTTPS redirect, hyperlinking, or any other means of directing
the User-Agent to the 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=token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&state=af0ifjsldkj
</pre></div>
<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.4.2.3"></a><h3>4.2.3.
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.
</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.4.2.4"></a><h3>4.2.4.
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>
<a name="implicit_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.2.5"></a><h3>4.2.5.
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="implicit_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.2.5.1"></a><h3>4.2.5.1.
End-User Grants Authorization</h3>
<p>If the resource owner grants the access request, the
authorization server issues an access token and delivers it to the
client by adding the following parameters to the fragment
component of the redirection URI using the
"application/x-www-form-urlencoded" format:</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,” July 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] scheme. As such, this value MUST be set to
"<tt>bearer</tt>".
</dd>
<dt>state</dt>
<dd>REQUIRED if the <tt>"state"</tt>
parameter in the request. Set to the exact value of the <tt>"state"</tt> parameter received from the
client.
</dd>
<dt>id_token</dt>
<dd>REQUIRED if the <tt>response_type</tt>
parameter in the request included the <tt>id_token</tt>
value.
</dd>
</dl></blockquote>
<p>The client can then use the Access Token to access protected
resources at resource servers.
</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#
access_token=SlAV32hkKG&
token_type=JWT&
expires_in=3600&
&state=af0ifjsldkj</pre></div>
<a name="implicit_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.2.5.2"></a><h3>4.2.5.2.
End-User Denies Authorization or Invalid Request</h3>
<p>If the user denies the authorization or the user authentication
fails, the 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages]. No other parameter SHOULD be returned.
</p>
<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.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,” July 2011.</span><span>)</span></a> [OAuth.2.0].
</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="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"></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="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.1.1"></a><h3>5.1.1.
Access Token Request</h3>
<p>To obtain a 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:
</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>
</dl></blockquote>
<p>
</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
grant_type=authorization_code
&code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
</pre></div>
<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.1.2"></a><h3>5.1.2.
Access Token Response</h3>
<p>Upon receipt of the Token Request, the Server MUST return either
Positive or Negative Assertion that corresponds to the received
authorization code.
</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.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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The assertion is a JSON structure which MUST contain the
following values:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>The access token.
</dd>
<dt>id_token</dt>
<dd>The ID Token associated with the
authentication session.
</dd>
<dt>token_type</dt>
<dd>Specifies the access token type. This
specification defines the "JWT" type for a JWT token.
</dd>
</dl></blockquote><p> In addition, it can contain the optional <tt>refresh_token</tt>, <tt>expires_in</tt>,
and <tt>scope</tt> values.
</p>
<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":"OjkdKlsdHV3JdsZmP"
}</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.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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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="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.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 authoriziation MUST verify the validity of the refresh
token
</p>
<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.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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 2011.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The assertion is a JSON structure which MUST contain the
following values:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>The access token.
</dd>
<dt>id_token</dt>
<dd>The ID Token associated with the
authentication session.
</dd>
<dt>token_type</dt>
<dd>Specifies the access token type. This
specification defines the "JWT" type for a JWT token.
</dd>
</dl></blockquote><p> In addition, it can contain the optional <tt>refresh_token</tt>, <tt>expires_in</tt>,
and <tt>scope</tt> values.
</p>
<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
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":"OjkdKlsdHV3JdsZmP"
}</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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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>
<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.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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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,” July 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,” July 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.
</dd>
<dt>schema</dt>
<dd>OPTIONAL. The schema in which the data is to
be returned. The only predefined value is <tt>openid</tt>.
If this parameter is not included, 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 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="anchor20"></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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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="checksession_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 Session Endpoint</h3>
<p>The Check Session 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 Session
endpoint to validate and retrieve the claims associated with the ID
Token in plain text JSON format.
</p>
<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.7.1"></a><h3>7.1.
Client Session Requests</h3>
<p>Clients MUST make a HTTP POST request using transport-layer
security with the following <tt>application/x-www-form-urlencoded</tt>
parameters in the request body:
</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 an Check
Session request:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /check_session HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
id_token=OjkdKlsdHV3JdsZmP
</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 Session Response</h3>
<p>The Check Session endpoint MUST return the JSON serialized claims
associated with the ID Token as described in Check Session Response
section of <a class='info' href='#OpenID.Messages'>OpenID Messages<span> (</span><span class='info'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 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 Session 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="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.7.2.1"></a><h3>7.2.1.
Check Session 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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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 Mangement 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,” July 2011.</span><span>)</span></a> [OpenID.Session]
specification.
</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.9"></a><h3>9.
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'>Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” August 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="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.9.1"></a><h3>9.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.10"></a><h3>10.
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>11. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ISO29115">[ISO29115]</a></td>
<td class="author-text">McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 --
Information technology - Security techniques - Entity authentication
assurance framework,” ISO/IEC 29115.</td></tr>
<tr><td class="author-text" valign="top"><a name="ISO3166-1">[ISO3166-1]</a></td>
<td class="author-text">International Organization for
Standardization, “<a href="http://www.w3.org/WAI/ER/IG/ert/iso639.htm">ISO 3166-1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country codes</a>,” 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="ISO639-1">[ISO639-1]</a></td>
<td class="author-text">International Organization for
Standardization, “ISO 639-1:2002. Codes for the representation of names of
languages -- Part 1: Alpha-2 code,” 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://self-issued.info/docs/draft-jones-json-web-encryption.html">JSON Web Encryption</a>,” March 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>,” July 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>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Core">[OpenID.Core]</a></td>
<td class="author-text">Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</a>,” July 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>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Framework">[OpenID.Framework]</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-framework-1_0.html">OpenID Connect Framework
1.0</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Lite">[OpenID.Lite]</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-lite-1_0.html">OpenID Connect Lite 1.0</a>,” August 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Messages">[OpenID.Messages]</a></td>
<td class="author-text">Recordon, D., Sakimura, N., 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>,” August 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 - draft 02</a>,” July 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>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Standard">[OpenID.Standard]</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-standard-1_0.html">OpenID Connect Standard
1.0</a>,” August 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.UserInfo">[OpenID.UserInfo]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., de Medeiros, B., and M. Jones, “<a href="http://openid.net/specs/openid-connect-userinfo-1_0.html">OpenID Connect UserInfo 1.0</a>,” July 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="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>
<tr><td class="author-text" valign="top"><a name="SP800-63">[SP800-63]</a></td>
<td class="author-text">National Institute of Standards and
Technology, “<a href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf">NIST SP800-63rev.1: Electronic Authentication
Guideline</a>,” NIST SP800-63.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a></td>
<td class="author-text">Hors, A., Jacobs, I., and D. Raggett, “<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="zoneinfo">[zoneinfo]</a></td>
<td class="author-text">Public Domain, “<a href="http://www.twinsun.com/tz/tz-link.htm">The tz database</a>,” June 2011.</td></tr>
</table>
<a name="anchor25"></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="anchor26"></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="anchor27"></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>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan
</p>
</blockquote>
<a name="anchor28"></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>Corrected examples.
</li>
</ul>
<p>-04 </p>
<ul class="text">
<li>Correct issues raised by Pam Dingle and discussed on the mailing
list after the 7-Jul-11 working group call.
</li>
<li>Adopted long_names.
</li>
</ul>
<p>-03 </p>
<ul class="text">
<li>Correct issues raised by Johnny Bufu and discussed on the
7-Jul-11 working group call.
</li>
</ul>
<p>-02 </p>
<ul class="text">
<li>Consistency and cleanup pass, including removing unused
references.
</li>
</ul>
<p>-01 </p>
<ul class="text">
<li>Initial draft
</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>