13569 lines
458 KiB
HTML
13569 lines
458 KiB
HTML
|
<!DOCTYPE HTML>
|
|||
|
|
<html lang="en">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|||
|
|
<title>Final: OpenID Connect Core 1.0 incorporating errata set 1</title>
|
|||
|
|
|
|||
|
|
<meta name="description" content="OpenID Connect Core 1.0 incorporating errata set 1">
|
|||
|
|
<meta name="generator" content="xml2rfc v1.37pre1 (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">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td>
|
|||
|
|
<table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="header">Final</td>
|
|||
|
|
<td class="header">N. Sakimura</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">Ping Identity</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">B. de Medeiros</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="header"> </td>
|
|||
|
|
<td class="header">Google</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="header"> </td>
|
|||
|
|
<td class="header">C. Mortimore</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="header"> </td>
|
|||
|
|
<td class="header">Salesforce</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="header"> </td>
|
|||
|
|
<td class="header">November 8, 2014</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<h1><br>OpenID Connect Core 1.0 incorporating errata set 1</h1>
|
|||
|
|
|
|||
|
|
<h3>Abstract</h3>
|
|||
|
|
|
|||
|
|
<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
|
|||
|
|
protocol. It enables Clients to verify the identity of the End-User based
|
|||
|
|
on the authentication performed by an Authorization Server, as well as to
|
|||
|
|
obtain basic profile information about the End-User in an interoperable and
|
|||
|
|
REST-like manner.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification defines
|
|||
|
|
the core OpenID Connect functionality:
|
|||
|
|
authentication built on top of OAuth 2.0 and
|
|||
|
|
the use of Claims to communicate information about the End-User.
|
|||
|
|
It also describes the security and privacy considerations for using OpenID Connect.
|
|||
|
|
|
|||
|
|
</p><a name="toc"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<h3>Table of Contents</h3>
|
|||
|
|
|
|||
|
|
<p class="toc">
|
|||
|
|
<a href="#Introduction">1.</a>
|
|||
|
|
Introduction<br>
|
|||
|
|
<a href="#rnc">1.1.</a>
|
|||
|
|
Requirements Notation and Conventions<br>
|
|||
|
|
<a href="#Terminology">1.2.</a>
|
|||
|
|
Terminology<br>
|
|||
|
|
<a href="#Overview">1.3.</a>
|
|||
|
|
Overview<br>
|
|||
|
|
<a href="#IDToken">2.</a>
|
|||
|
|
ID Token<br>
|
|||
|
|
<a href="#Authentication">3.</a>
|
|||
|
|
Authentication<br>
|
|||
|
|
<a href="#CodeFlowAuth">3.1.</a>
|
|||
|
|
Authentication using the Authorization Code Flow<br>
|
|||
|
|
<a
|
|||
|
|
href="#CodeFlowSteps">3.1.1.</a>
|
|||
|
|
Authorization Code Flow Steps<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthorizationEndpoint">3.1.2.</a>
|
|||
|
|
Authorization Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthRequest">3.1.2.1.</a>
|
|||
|
|
Authentication Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthRequestValidation">3.1.2.2.</a>
|
|||
|
|
Authentication Request Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#Authenticates">3.1.2.3.</a>
|
|||
|
|
Authorization Server Authenticates End-User<br>
|
|||
|
|
<a
|
|||
|
|
href="#Consent">3.1.2.4.</a>
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthResponse">3.1.2.5.</a>
|
|||
|
|
Successful Authentication Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthError">3.1.2.6.</a>
|
|||
|
|
Authentication Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#AuthResponseValidation">3.1.2.7.</a>
|
|||
|
|
Authentication Response Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenEndpoint">3.1.3.</a>
|
|||
|
|
Token Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenRequest">3.1.3.1.</a>
|
|||
|
|
Token Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenRequestValidation">3.1.3.2.</a>
|
|||
|
|
Token Request Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenResponse">3.1.3.3.</a>
|
|||
|
|
Successful Token Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenErrorResponse">3.1.3.4.</a>
|
|||
|
|
Token Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#TokenResponseValidation">3.1.3.5.</a>
|
|||
|
|
Token Response Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#CodeIDToken">3.1.3.6.</a>
|
|||
|
|
ID Token<br>
|
|||
|
|
<a
|
|||
|
|
href="#IDTokenValidation">3.1.3.7.</a>
|
|||
|
|
ID Token Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#CodeFlowTokenValidation">3.1.3.8.</a>
|
|||
|
|
Access Token Validation<br>
|
|||
|
|
<a href="#ImplicitFlowAuth">3.2.</a>
|
|||
|
|
Authentication using the Implicit Flow<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitFlowSteps">3.2.1.</a>
|
|||
|
|
Implicit Flow Steps<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthorizationEndpoint">3.2.2.</a>
|
|||
|
|
Authorization Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthRequest">3.2.2.1.</a>
|
|||
|
|
Authentication Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitValidation">3.2.2.2.</a>
|
|||
|
|
Authentication Request Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthenticates">3.2.2.3.</a>
|
|||
|
|
Authorization Server Authenticates End-User<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitConsent">3.2.2.4.</a>
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthResponse">3.2.2.5.</a>
|
|||
|
|
Successful Authentication Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthError">3.2.2.6.</a>
|
|||
|
|
Authentication Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitCallback">3.2.2.7.</a>
|
|||
|
|
Redirect URI Fragment Handling<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitAuthResponseValidation">3.2.2.8.</a>
|
|||
|
|
Authentication Response Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitTokenValidation">3.2.2.9.</a>
|
|||
|
|
Access Token Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitIDToken">3.2.2.10.</a>
|
|||
|
|
ID Token<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitIDTValidation">3.2.2.11.</a>
|
|||
|
|
ID Token Validation<br>
|
|||
|
|
<a href="#HybridFlowAuth">3.3.</a>
|
|||
|
|
Authentication using the Hybrid Flow<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridFlowSteps">3.3.1.</a>
|
|||
|
|
Hybrid Flow Steps<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthorizationEndpoint">3.3.2.</a>
|
|||
|
|
Authorization Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthRequest">3.3.2.1.</a>
|
|||
|
|
Authentication Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridValidation">3.3.2.2.</a>
|
|||
|
|
Authentication Request Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthenticates">3.3.2.3.</a>
|
|||
|
|
Authorization Server Authenticates End-User<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridConsent">3.3.2.4.</a>
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthResponse">3.3.2.5.</a>
|
|||
|
|
Successful Authentication Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthError">3.3.2.6.</a>
|
|||
|
|
Authentication Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridCallback">3.3.2.7.</a>
|
|||
|
|
Redirect URI Fragment Handling<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAuthResponseValidation">3.3.2.8.</a>
|
|||
|
|
Authentication Response Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenValidation">3.3.2.9.</a>
|
|||
|
|
Access Token Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#CodeValidation">3.3.2.10.</a>
|
|||
|
|
Authorization Code Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridIDToken">3.3.2.11.</a>
|
|||
|
|
ID Token<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridIDTValidation">3.3.2.12.</a>
|
|||
|
|
ID Token Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenEndpoint">3.3.3.</a>
|
|||
|
|
Token Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenRequest">3.3.3.1.</a>
|
|||
|
|
Token Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenRequestValidation">3.3.3.2.</a>
|
|||
|
|
Token Request Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenResponse">3.3.3.3.</a>
|
|||
|
|
Successful Token Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenErrorResponse">3.3.3.4.</a>
|
|||
|
|
Token Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenResponseValidation">3.3.3.5.</a>
|
|||
|
|
Token Response Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridIDToken2">3.3.3.6.</a>
|
|||
|
|
ID Token<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridIDTValidation2">3.3.3.7.</a>
|
|||
|
|
ID Token Validation<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridAccessToken2">3.3.3.8.</a>
|
|||
|
|
Access Token<br>
|
|||
|
|
<a
|
|||
|
|
href="#HybridTokenValidation2">3.3.3.9.</a>
|
|||
|
|
Access Token Validation<br>
|
|||
|
|
<a href="#ThirdPartyInitiatedLogin">4.</a>
|
|||
|
|
Initiating Login from a Third Party<br>
|
|||
|
|
<a href="#Claims">5.</a>
|
|||
|
|
Claims<br>
|
|||
|
|
<a href="#StandardClaims">5.1.</a>
|
|||
|
|
Standard Claims<br>
|
|||
|
|
<a
|
|||
|
|
href="#AddressClaim">5.1.1.</a>
|
|||
|
|
Address Claim<br>
|
|||
|
|
<a
|
|||
|
|
href="#AdditionalClaims">5.1.2.</a>
|
|||
|
|
Additional Claims<br>
|
|||
|
|
<a href="#ClaimsLanguagesAndScripts">5.2.</a>
|
|||
|
|
Claims Languages and Scripts<br>
|
|||
|
|
<a href="#UserInfo">5.3.</a>
|
|||
|
|
UserInfo Endpoint<br>
|
|||
|
|
<a
|
|||
|
|
href="#UserInfoRequest">5.3.1.</a>
|
|||
|
|
UserInfo Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#UserInfoResponse">5.3.2.</a>
|
|||
|
|
Successful UserInfo Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#UserInfoError">5.3.3.</a>
|
|||
|
|
UserInfo Error Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#UserInfoResponseValidation">5.3.4.</a>
|
|||
|
|
UserInfo Response Validation<br>
|
|||
|
|
<a href="#ScopeClaims">5.4.</a>
|
|||
|
|
Requesting Claims using Scope Values<br>
|
|||
|
|
<a href="#ClaimsParameter">5.5.</a>
|
|||
|
|
Requesting Claims using the "claims" Request Parameter<br>
|
|||
|
|
<a
|
|||
|
|
href="#IndividualClaimsRequests">5.5.1.</a>
|
|||
|
|
Individual Claims Requests<br>
|
|||
|
|
<a
|
|||
|
|
href="#acrSemantics">5.5.1.1.</a>
|
|||
|
|
Requesting the "acr" Claim<br>
|
|||
|
|
<a
|
|||
|
|
href="#IndividualClaimsLanguages">5.5.2.</a>
|
|||
|
|
Languages and Scripts for Individual Claims<br>
|
|||
|
|
<a href="#ClaimTypes">5.6.</a>
|
|||
|
|
Claim Types<br>
|
|||
|
|
<a
|
|||
|
|
href="#NormalClaims">5.6.1.</a>
|
|||
|
|
Normal Claims<br>
|
|||
|
|
<a
|
|||
|
|
href="#AggregatedDistributedClaims">5.6.2.</a>
|
|||
|
|
Aggregated and Distributed Claims<br>
|
|||
|
|
<a
|
|||
|
|
href="#AggregatedExample">5.6.2.1.</a>
|
|||
|
|
Example of Aggregated Claims<br>
|
|||
|
|
<a
|
|||
|
|
href="#DistributedExample">5.6.2.2.</a>
|
|||
|
|
Example of Distributed Claims<br>
|
|||
|
|
<a href="#ClaimStability">5.7.</a>
|
|||
|
|
Claim Stability and Uniqueness<br>
|
|||
|
|
<a href="#JWTRequests">6.</a>
|
|||
|
|
Passing Request Parameters as JWTs<br>
|
|||
|
|
<a href="#RequestObject">6.1.</a>
|
|||
|
|
Passing a Request Object by Value<br>
|
|||
|
|
<a
|
|||
|
|
href="#RequestParameter">6.1.1.</a>
|
|||
|
|
Request using the "request" Request Parameter<br>
|
|||
|
|
<a href="#RequestUriParameter">6.2.</a>
|
|||
|
|
Passing a Request Object by Reference<br>
|
|||
|
|
<a
|
|||
|
|
href="#CreateRequestUri">6.2.1.</a>
|
|||
|
|
URL Referencing the Request Object<br>
|
|||
|
|
<a
|
|||
|
|
href="#UseRequestUri">6.2.2.</a>
|
|||
|
|
Request using the "request_uri" Request Parameter<br>
|
|||
|
|
<a
|
|||
|
|
href="#GetRequestUri">6.2.3.</a>
|
|||
|
|
Authorization Server Fetches Request Object<br>
|
|||
|
|
<a
|
|||
|
|
href="#RequestUriRationale">6.2.4.</a>
|
|||
|
|
"request_uri" Rationale<br>
|
|||
|
|
<a href="#JWTRequestValidation">6.3.</a>
|
|||
|
|
Validating JWT-Based Requests<br>
|
|||
|
|
<a
|
|||
|
|
href="#EncryptedRequestObject">6.3.1.</a>
|
|||
|
|
Encrypted Request Object<br>
|
|||
|
|
<a
|
|||
|
|
href="#SignedRequestObject">6.3.2.</a>
|
|||
|
|
Signed Request Object<br>
|
|||
|
|
<a
|
|||
|
|
href="#RequestParameterValidation">6.3.3.</a>
|
|||
|
|
Request Parameter Assembly and Validation<br>
|
|||
|
|
<a href="#SelfIssued">7.</a>
|
|||
|
|
Self-Issued OpenID Provider<br>
|
|||
|
|
<a href="#SelfIssuedDiscovery">7.1.</a>
|
|||
|
|
Self-Issued OpenID Provider Discovery<br>
|
|||
|
|
<a
|
|||
|
|
href="#SelfIssuedRegistration">7.2.</a>
|
|||
|
|
Self-Issued OpenID Provider Registration<br>
|
|||
|
|
<a
|
|||
|
|
href="#RegistrationParameter">7.2.1.</a>
|
|||
|
|
Providing Information with the "registration" Request Parameter<br>
|
|||
|
|
<a href="#SelfIssuedRequest">7.3.</a>
|
|||
|
|
Self-Issued OpenID Provider Request<br>
|
|||
|
|
<a href="#SelfIssuedResponse">7.4.</a>
|
|||
|
|
Self-Issued OpenID Provider Response<br>
|
|||
|
|
<a href="#SelfIssuedValidation">7.5.</a>
|
|||
|
|
Self-Issued ID Token Validation<br>
|
|||
|
|
<a href="#SubjectIDTypes">8.</a>
|
|||
|
|
Subject Identifier Types<br>
|
|||
|
|
<a href="#PairwiseAlg">8.1.</a>
|
|||
|
|
Pairwise Identifier Algorithm<br>
|
|||
|
|
<a href="#ClientAuthentication">9.</a>
|
|||
|
|
Client Authentication<br>
|
|||
|
|
<a href="#SigEnc">10.</a>
|
|||
|
|
Signatures and Encryption<br>
|
|||
|
|
<a href="#Signing">10.1.</a>
|
|||
|
|
Signing<br>
|
|||
|
|
<a
|
|||
|
|
href="#RotateSigKeys">10.1.1.</a>
|
|||
|
|
Rotation of Asymmetric Signing Keys<br>
|
|||
|
|
<a href="#Encryption">10.2.</a>
|
|||
|
|
Encryption<br>
|
|||
|
|
<a
|
|||
|
|
href="#RotateEncKeys">10.2.1.</a>
|
|||
|
|
Rotation of Asymmetric Encryption Keys<br>
|
|||
|
|
<a href="#OfflineAccess">11.</a>
|
|||
|
|
Offline Access<br>
|
|||
|
|
<a href="#RefreshTokens">12.</a>
|
|||
|
|
Using Refresh Tokens<br>
|
|||
|
|
<a
|
|||
|
|
href="#RefreshingAccessToken">12.1.</a>
|
|||
|
|
Refresh Request<br>
|
|||
|
|
<a
|
|||
|
|
href="#RefreshTokenResponse">12.2.</a>
|
|||
|
|
Successful Refresh Response<br>
|
|||
|
|
<a
|
|||
|
|
href="#RefreshErrorResponse">12.3.</a>
|
|||
|
|
Refresh Error Response<br>
|
|||
|
|
<a href="#Serializations">13.</a>
|
|||
|
|
Serializations<br>
|
|||
|
|
<a href="#QuerySerialization">13.1.</a>
|
|||
|
|
Query String Serialization<br>
|
|||
|
|
<a href="#FormSerialization">13.2.</a>
|
|||
|
|
Form Serialization<br>
|
|||
|
|
<a href="#JSONSerialization">13.3.</a>
|
|||
|
|
JSON Serialization<br>
|
|||
|
|
<a href="#StringOps">14.</a>
|
|||
|
|
String Operations<br>
|
|||
|
|
<a href="#ImplementationConsiderations">15.</a>
|
|||
|
|
Implementation Considerations<br>
|
|||
|
|
<a href="#ServerMTI">15.1.</a>
|
|||
|
|
Mandatory to Implement Features for All OpenID Providers<br>
|
|||
|
|
<a href="#DynamicMTI">15.2.</a>
|
|||
|
|
Mandatory to Implement Features for Dynamic OpenID Providers<br>
|
|||
|
|
<a href="#DiscoReg">15.3.</a>
|
|||
|
|
Discovery and Registration<br>
|
|||
|
|
<a href="#RPMTI">15.4.</a>
|
|||
|
|
Mandatory to Implement Features for Relying Parties<br>
|
|||
|
|
<a href="#ImplementationNotes">15.5.</a>
|
|||
|
|
Implementation Notes<br>
|
|||
|
|
<a
|
|||
|
|
href="#CodeNotes">15.5.1.</a>
|
|||
|
|
Authorization Code Implementation Notes<br>
|
|||
|
|
<a
|
|||
|
|
href="#NonceNotes">15.5.2.</a>
|
|||
|
|
Nonce Implementation Notes<br>
|
|||
|
|
<a
|
|||
|
|
href="#FragmentNotes">15.5.3.</a>
|
|||
|
|
Redirect URI Fragment Handling Implementation Notes<br>
|
|||
|
|
<a href="#CompatibilityNotes">15.6.</a>
|
|||
|
|
Compatibility Notes<br>
|
|||
|
|
<a
|
|||
|
|
href="#PreFinalIETFSpecs">15.6.1.</a>
|
|||
|
|
Pre-Final IETF Specifications<br>
|
|||
|
|
<a
|
|||
|
|
href="#GoogleIss">15.6.2.</a>
|
|||
|
|
Google "iss" Value<br>
|
|||
|
|
<a href="#RelatedSpecs">15.7.</a>
|
|||
|
|
Related Specifications and Implementer's Guides<br>
|
|||
|
|
<a href="#Security">16.</a>
|
|||
|
|
Security Considerations<br>
|
|||
|
|
<a href="#RequestDisclosure">16.1.</a>
|
|||
|
|
Request Disclosure<br>
|
|||
|
|
<a href="#ServerMasquerading">16.2.</a>
|
|||
|
|
Server Masquerading<br>
|
|||
|
|
<a href="#TokenManufacture">16.3.</a>
|
|||
|
|
Token Manufacture/Modification<br>
|
|||
|
|
<a
|
|||
|
|
href="#AccessTokenDisclosure">16.4.</a>
|
|||
|
|
Access Token Disclosure<br>
|
|||
|
|
<a href="#ResponseDisclosure">16.5.</a>
|
|||
|
|
Server Response Disclosure<br>
|
|||
|
|
<a href="#ServerResponseRepudiation">16.6.</a>
|
|||
|
|
Server Response Repudiation<br>
|
|||
|
|
<a href="#RequestRepudation">16.7.</a>
|
|||
|
|
Request Repudiation<br>
|
|||
|
|
<a href="#AccessTokenRedirect">16.8.</a>
|
|||
|
|
Access Token Redirect<br>
|
|||
|
|
<a href="#TokenReuse">16.9.</a>
|
|||
|
|
Token Reuse<br>
|
|||
|
|
<a href="#AuthCodeCapture">16.10.</a>
|
|||
|
|
Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)<br>
|
|||
|
|
<a href="#TokenSubstitution">16.11.</a>
|
|||
|
|
Token Substitution<br>
|
|||
|
|
<a href="#TimingAttack">16.12.</a>
|
|||
|
|
Timing Attack<br>
|
|||
|
|
<a href="#OtherCryptoAttacks">16.13.</a>
|
|||
|
|
Other Crypto Related Attacks<br>
|
|||
|
|
<a href="#SigningOrder">16.14.</a>
|
|||
|
|
Signing and Encryption Order<br>
|
|||
|
|
<a href="#IssuerIdentifier">16.15.</a>
|
|||
|
|
Issuer Identifier<br>
|
|||
|
|
<a
|
|||
|
|
href="#ImplicitFlowThreats">16.16.</a>
|
|||
|
|
Implicit Flow Threats<br>
|
|||
|
|
<a href="#TLSRequirements">16.17.</a>
|
|||
|
|
TLS Requirements<br>
|
|||
|
|
<a href="#TokenLifetime">16.18.</a>
|
|||
|
|
Lifetimes of Access Tokens and Refresh Tokens<br>
|
|||
|
|
<a
|
|||
|
|
href="#SymmetricKeyEntropy">16.19.</a>
|
|||
|
|
Symmetric Key Entropy<br>
|
|||
|
|
<a
|
|||
|
|
href="#NeedForSignedRequests">16.20.</a>
|
|||
|
|
Need for Signed Requests<br>
|
|||
|
|
<a href="#NeedForEncryptedRequests">16.21.</a>
|
|||
|
|
Need for Encrypted Requests<br>
|
|||
|
|
<a href="#Privacy">17.</a>
|
|||
|
|
Privacy Considerations<br>
|
|||
|
|
<a href="#PII">17.1.</a>
|
|||
|
|
Personally Identifiable Information<br>
|
|||
|
|
<a href="#AccessMonitoring">17.2.</a>
|
|||
|
|
Data Access Monitoring<br>
|
|||
|
|
<a href="#Correlation">17.3.</a>
|
|||
|
|
Correlation<br>
|
|||
|
|
<a
|
|||
|
|
href="#OfflineAccessPrivacy">17.4.</a>
|
|||
|
|
Offline Access<br>
|
|||
|
|
<a href="#IANA">18.</a>
|
|||
|
|
IANA Considerations<br>
|
|||
|
|
<a href="#ClaimsRegistry">18.1.</a>
|
|||
|
|
JSON Web Token Claims Registration<br>
|
|||
|
|
<a
|
|||
|
|
href="#ClaimsContents">18.1.1.</a>
|
|||
|
|
Registry Contents<br>
|
|||
|
|
<a
|
|||
|
|
href="#OAuthParametersRegistry">18.2.</a>
|
|||
|
|
OAuth Parameters Registration<br>
|
|||
|
|
<a
|
|||
|
|
href="#ParametersContents">18.2.1.</a>
|
|||
|
|
Registry Contents<br>
|
|||
|
|
<a href="#OAuthErrorRegistry">18.3.</a>
|
|||
|
|
OAuth Extensions Error Registration<br>
|
|||
|
|
<a
|
|||
|
|
href="#ErrorContents">18.3.1.</a>
|
|||
|
|
Registry Contents<br>
|
|||
|
|
<a href="#rfc.references1">19.</a>
|
|||
|
|
References<br>
|
|||
|
|
<a href="#rfc.references1">19.1.</a>
|
|||
|
|
Normative References<br>
|
|||
|
|
<a href="#rfc.references2">19.2.</a>
|
|||
|
|
Informative References<br>
|
|||
|
|
<a href="#AuthorizationExamples">Appendix A.</a>
|
|||
|
|
Authorization Examples<br>
|
|||
|
|
<a href="#codeExample">A.1.</a>
|
|||
|
|
Example using response_type=code<br>
|
|||
|
|
<a href="#id_tokenExample">A.2.</a>
|
|||
|
|
Example using response_type=id_token<br>
|
|||
|
|
<a
|
|||
|
|
href="#id_token-tokenExample">A.3.</a>
|
|||
|
|
Example using response_type=id_token token<br>
|
|||
|
|
<a href="#code-id_tokenExample">A.4.</a>
|
|||
|
|
Example using response_type=code id_token<br>
|
|||
|
|
<a href="#code-tokenExample">A.5.</a>
|
|||
|
|
Example using response_type=code token<br>
|
|||
|
|
<a href="#code-id_token-tokenExample">A.6.</a>
|
|||
|
|
Example using response_type=code id_token token<br>
|
|||
|
|
<a href="#ExampleRSAKey">A.7.</a>
|
|||
|
|
RSA Key Used in Examples<br>
|
|||
|
|
<a href="#Acknowledgements">Appendix B.</a>
|
|||
|
|
Acknowledgements<br>
|
|||
|
|
<a href="#Notices">Appendix C.</a>
|
|||
|
|
Notices<br>
|
|||
|
|
<a href="#rfc.authors">§</a>
|
|||
|
|
Authors' Addresses<br>
|
|||
|
|
</p>
|
|||
|
|
<br clear="all">
|
|||
|
|
|
|||
|
|
<a name="Introduction"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.1"></a>
|
|||
|
|
|
|||
|
|
<h3>1.
|
|||
|
|
Introduction</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
|
|||
|
|
<a class="info" href="#RFC6749">[RFC6749]<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
protocol. It enables Clients to verify the identity of the End-User based
|
|||
|
|
on the authentication performed by an Authorization Server, as well as to
|
|||
|
|
obtain basic profile information about the End-User in an interoperable and
|
|||
|
|
REST-like manner.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OpenID Connect Core 1.0 specification defines
|
|||
|
|
the core OpenID Connect functionality:
|
|||
|
|
authentication built on top of OAuth 2.0 and
|
|||
|
|
the use of Claims to communicate information about the End-User.
|
|||
|
|
It also describes the security and privacy considerations for using OpenID Connect.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
As background,
|
|||
|
|
the <a class="info" href="#RFC6749">OAuth 2.0 Authorization
|
|||
|
|
Framework<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749]
|
|||
|
|
and <a class="info" href="#RFC6750">OAuth 2.0 Bearer Token Usage<span> (</span><span
|
|||
|
|
class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750]
|
|||
|
|
specifications provide a general framework for third-party applications
|
|||
|
|
to obtain and use limited access to HTTP resources. They define
|
|||
|
|
mechanisms to obtain and use Access Tokens to access resources but
|
|||
|
|
do not define standard methods to provide identity information.
|
|||
|
|
Notably, without profiling OAuth 2.0, it is incapable of
|
|||
|
|
providing information about the authentication of an End-User.
|
|||
|
|
Readers are expected to be familiar with these specifications.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect implements authentication as an extension to the
|
|||
|
|
OAuth 2.0 authorization process.
|
|||
|
|
Use of this extension is requested by Clients by including
|
|||
|
|
the <tt>openid</tt> scope value
|
|||
|
|
in the Authorization Request.
|
|||
|
|
Information about the authentication performed is returned
|
|||
|
|
in a <a class="info" href="#JWT">JSON Web Token
|
|||
|
|
(JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT]
|
|||
|
|
called an ID Token (see <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>).
|
|||
|
|
OAuth 2.0 Authentication Servers implementing OpenID Connect
|
|||
|
|
are also referred to as OpenID Providers (OPs).
|
|||
|
|
OAuth 2.0 Clients using OpenID Connect
|
|||
|
|
are also referred to as Relying Parties (RPs).
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification assumes that the Relying Party has already obtained
|
|||
|
|
configuration information about the OpenID Provider, including its
|
|||
|
|
Authorization Endpoint and Token Endpoint locations.
|
|||
|
|
This information is normally obtained via Discovery,
|
|||
|
|
as described in <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,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Discovery],
|
|||
|
|
or may be obtained via other mechanisms.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Likewise, this specification assumes that the Relying Party has already obtained
|
|||
|
|
sufficient credentials and provided information needed to use the OpenID Provider.
|
|||
|
|
This is normally done via Dynamic Registration,
|
|||
|
|
as described in
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID Connect
|
|||
|
|
Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration],
|
|||
|
|
or may be obtained via other mechanisms.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="rnc"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>1.1.
|
|||
|
|
Requirements Notation and Conventions</h3>
|
|||
|
|
|
|||
|
|
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in <a class="info"
|
|||
|
|
href="#RFC2119">RFC
|
|||
|
|
2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>
|
|||
|
|
[RFC2119].
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In the .txt version of 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.
|
|||
|
|
In the HTML version of this document,
|
|||
|
|
values to be taken literally are indicated by
|
|||
|
|
the use of <tt>this fixed-width font</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
All uses of <a class="info" href="#JWS">JSON Web Signature (JWS)<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS]
|
|||
|
|
and <a class="info" href="#JWE">JSON Web Encryption (JWE)<span> (</span><span
|
|||
|
|
class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE]
|
|||
|
|
data structures in this specification utilize
|
|||
|
|
the JWS Compact Serialization or the JWE Compact Serialization;
|
|||
|
|
the JWS JSON Serialization and the JWE JSON Serialization are not used.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Terminology"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.1.2"></a>
|
|||
|
|
|
|||
|
|
<h3>1.2.
|
|||
|
|
Terminology</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification uses the terms "Access Token", "Authorization Code",
|
|||
|
|
"Authorization Endpoint", "Authorization Grant", "Authorization Server",
|
|||
|
|
"Client", "Client Authentication", "Client Identifier", "Client Secret",
|
|||
|
|
"Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",
|
|||
|
|
"Resource Owner", "Resource Server", "Response Type", and "Token Endpoint"
|
|||
|
|
defined by <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
the terms "Claim Name", "Claim Value", "JSON Web Token (JWT)",
|
|||
|
|
"JWT Claims Set", and "Nested JWT"
|
|||
|
|
defined by <a class="info" href="#JWT">JSON Web Token
|
|||
|
|
(JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT],
|
|||
|
|
the terms "Header Parameter" and "JOSE Header"
|
|||
|
|
defined by <a class="info" href="#JWS">JSON Web Signature
|
|||
|
|
(JWS)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS],
|
|||
|
|
the term "User Agent" defined by <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 the term "Response Mode" defined by
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification also defines the following terms:
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Authentication</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Process used to achieve sufficient confidence in the binding
|
|||
|
|
between the Entity and the presented Identity.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Request</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Authorization Request using extension parameters and scopes
|
|||
|
|
defined by OpenID Connect to request that the End-User be authenticated
|
|||
|
|
by the Authorization Server, which is an OpenID Connect Provider,
|
|||
|
|
to the Client, which is an OpenID Connect Relying Party.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Context</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Information that the Relying Party can require before it makes an
|
|||
|
|
entitlement decision with respect to an authentication response.
|
|||
|
|
Such context can include, but is not limited to, the actual
|
|||
|
|
authentication method used or level of assurance such as
|
|||
|
|
<a class="info" href="#ISO29115">ISO/IEC
|
|||
|
|
29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.</span><span>)</span></a>
|
|||
|
|
[ISO29115]
|
|||
|
|
entity authentication assurance level.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Context Class</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Set of authentication methods or procedures that are considered
|
|||
|
|
to be equivalent to each other in a particular context.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Context Class Reference</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Identifier for an Authentication Context Class.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authorization Code Flow</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 flow in which
|
|||
|
|
an Authorization Code is returned from the Authorization Endpoint and
|
|||
|
|
all tokens are returned from the Token Endpoint.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authorization Request</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Authorization Request as defined by <a class="info"
|
|||
|
|
href="#RFC6749">[RFC6749]<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Claim</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Piece of information asserted about an Entity.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Claim Type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Syntax used for representing a Claim Value.
|
|||
|
|
This specification defines Normal, Aggregated, and Distributed Claim Types.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Claims Provider</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Server that can return Claims about an Entity.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Credential</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Data presented as evidence of the right to use an identity
|
|||
|
|
or other resources.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>End-User</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Human participant.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Entity</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Something that has a separate and distinct existence and that can be
|
|||
|
|
identified in a context. An End-User is one example of an Entity.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Essential Claim</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Claim specified by the Client as being necessary to ensure a smooth
|
|||
|
|
authorization experience for the specific task requested by the End-User.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Hybrid Flow</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 flow in which
|
|||
|
|
an Authorization Code is returned from the Authorization Endpoint,
|
|||
|
|
some tokens are returned from the Authorization Endpoint,
|
|||
|
|
and others are returned from the Token Endpoint.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>ID Token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
<a class="info" href="#JWT">JSON Web Token
|
|||
|
|
(JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT] that contains Claims about the Authentication event.
|
|||
|
|
It MAY contain other Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Identifier</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Value that uniquely characterizes an Entity in a specific context.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Identity</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Set of attributes related to an Entity.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Implicit Flow</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint
|
|||
|
|
and neither the Token Endpoint nor an Authorization Code are used.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Issuer</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Entity that issues a set of Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Issuer Identifier</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Verifiable Identifier for an Issuer.
|
|||
|
|
An Issuer Identifier is a case sensitive URL
|
|||
|
|
using the <tt>https</tt> scheme that
|
|||
|
|
contains scheme, host, and optionally, port number and path
|
|||
|
|
components and no query or fragment components.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Message</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Request or a response between an OpenID
|
|||
|
|
Relying Party and an OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>OpenID Provider (OP)</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Authorization Server that is capable of
|
|||
|
|
Authenticating the End-User and
|
|||
|
|
providing Claims to a Relying Party
|
|||
|
|
about the Authentication event and the End-User.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Request Object</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
JWT that contains a set of request parameters as its Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Request URI</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
URL that references a resource containing a Request Object.
|
|||
|
|
The Request URI contents MUST be retrievable by the
|
|||
|
|
Authorization Server.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Pairwise Pseudonymous Identifier (PPID)</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Identifier that identifies the Entity to a Relying Party that cannot be correlated
|
|||
|
|
with the Entity's PPID at another Relying Party.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Personally Identifiable Information (PII)</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Information that (a) can be used to identify the natural person
|
|||
|
|
to whom such information relates, or
|
|||
|
|
(b) is or might be directly or indirectly linked to a
|
|||
|
|
natural person to whom such information relates.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Relying Party (RP)</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Client application requiring End-User Authentication
|
|||
|
|
and Claims from an OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Sector Identifier</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Host component of a URL used by the Relying Party's organization
|
|||
|
|
that is an input to the computation of pairwise Subject Identifiers
|
|||
|
|
for that Relying Party.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Self-Issued OpenID Provider</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Subject Identifier</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Locally unique and never
|
|||
|
|
reassigned identifier within the Issuer for the End-User,
|
|||
|
|
which is intended to be consumed by the Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>UserInfo Endpoint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Protected Resource that, when presented with an Access Token by the Client,
|
|||
|
|
returns authorized information about the End-User represented by the corresponding
|
|||
|
|
Authorization Grant.
|
|||
|
|
The UserInfo Endpoint
|
|||
|
|
URL MUST use the <tt>https</tt> scheme and MAY contain
|
|||
|
|
port, path, and query parameter components.
|
|||
|
|
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Validation</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Process intended to establish the soundness or correctness of a construct.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Verification</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Process intended to test or prove the truth or accuracy of a fact or value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Voluntary Claim</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Claim specified by the Client as being useful but not Essential
|
|||
|
|
for the specific task requested by the End-User.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
IMPORTANT NOTE TO READERS: The terminology definitions in
|
|||
|
|
this section are a normative portion of this specification,
|
|||
|
|
imposing requirements upon implementations. All the
|
|||
|
|
capitalized words in the text of this specification, such as
|
|||
|
|
"Issuer Identifier", reference these defined terms.
|
|||
|
|
Whenever the reader encounters them, their definitions
|
|||
|
|
found in this section must be followed.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
For more background on some of the terminology used,
|
|||
|
|
see <a class="info" href="#RFC4949">Internet Security Glossary,
|
|||
|
|
Version 2<span> (</span><span
|
|||
|
|
class="info">Shirey, R., “Internet Security Glossary, Version 2,” August 2007.</span><span>)</span></a>
|
|||
|
|
[RFC4949],
|
|||
|
|
<a class="info" href="#ISO29115">ISO/IEC 29115 Entity
|
|||
|
|
Authentication Assurance<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.</span><span>)</span></a>
|
|||
|
|
[ISO29115],
|
|||
|
|
and <a class="info" href="#X.1252">ITU-T
|
|||
|
|
X.1252<span> (</span><span class="info">International Telecommunication Union, “ITU-T Recommendation X.1252 -- Cyberspace security -- Identity management -- Baseline identity management terms and definitions,” November 2010.</span><span>)</span></a>
|
|||
|
|
[X.1252].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Overview"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.1.3"></a>
|
|||
|
|
|
|||
|
|
<h3>1.3.
|
|||
|
|
Overview</h3>
|
|||
|
|
|
|||
|
|
<p>The OpenID Connect protocol, in abstract, follows the following
|
|||
|
|
steps.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>The RP (Client) sends a request to the OpenID Provider (OP).
|
|||
|
|
</li>
|
|||
|
|
<li>The OP authenticates the End-User and obtains authorization.
|
|||
|
|
</li>
|
|||
|
|
<li>The OP responds with an ID Token and usually an Access Token.
|
|||
|
|
</li>
|
|||
|
|
<li>The RP can send a request with the Access Token to the UserInfo Endpoint.
|
|||
|
|
</li>
|
|||
|
|
<li>The UserInfo Endpoint returns Claims about the End-User.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
These steps are illustrated in the following diagram:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>+--------+ +--------+
|
|||
|
|
| | | |
|
|||
|
|
| |---------(1) AuthN Request-------->| |
|
|||
|
|
| | | |
|
|||
|
|
| | +--------+ | |
|
|||
|
|
| | | | | |
|
|||
|
|
| | | End- |<--(2) AuthN & AuthZ-->| |
|
|||
|
|
| | | User | | |
|
|||
|
|
| RP | | | | OP |
|
|||
|
|
| | +--------+ | |
|
|||
|
|
| | | |
|
|||
|
|
| |<--------(3) AuthN Response--------| |
|
|||
|
|
| | | |
|
|||
|
|
| |---------(4) UserInfo Request----->| |
|
|||
|
|
| | | |
|
|||
|
|
| |<--------(5) UserInfo Response-----| |
|
|||
|
|
| | | |
|
|||
|
|
+--------+ +--------+
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="IDToken"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.2"></a>
|
|||
|
|
|
|||
|
|
<h3>2.
|
|||
|
|
ID Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The primary extension that OpenID Connect makes to OAuth 2.0
|
|||
|
|
to enable End-Users to be Authenticated
|
|||
|
|
is the ID Token data structure.
|
|||
|
|
The ID Token is a security token that contains Claims about the
|
|||
|
|
Authentication of an End-User by an Authorization Server when using a Client,
|
|||
|
|
and potentially other requested Claims.
|
|||
|
|
The ID Token is represented as a
|
|||
|
|
<a class="info" href="#JWT">JSON Web Token
|
|||
|
|
(JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following Claims are used within the ID Token
|
|||
|
|
for all OAuth 2.0 flows used by OpenID Connect:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>iss</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Issuer Identifier for the Issuer of the response.
|
|||
|
|
The <tt>iss</tt> value is a case sensitive URL
|
|||
|
|
using the <tt>https</tt> scheme that
|
|||
|
|
contains scheme, host, and optionally, port number and path
|
|||
|
|
components and no query or fragment components.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>sub</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Subject Identifier. A locally unique and never
|
|||
|
|
reassigned identifier within the Issuer for the End-User,
|
|||
|
|
which is intended to be consumed by the Client,
|
|||
|
|
e.g., <tt>24400320</tt>
|
|||
|
|
or <tt>AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</tt>.
|
|||
|
|
It MUST NOT exceed 255 ASCII characters in length.
|
|||
|
|
The <tt>sub</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>aud</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Audience(s) that this ID Token is intended for.
|
|||
|
|
It MUST contain the OAuth 2.0 <tt>client_id</tt>
|
|||
|
|
of the Relying Party as an audience value.
|
|||
|
|
It MAY also contain identifiers for other audiences.
|
|||
|
|
In the general case,
|
|||
|
|
the <tt>aud</tt> value is an array of
|
|||
|
|
case sensitive strings.
|
|||
|
|
In the common special case when there is one audience,
|
|||
|
|
the <tt>aud</tt> value MAY be a single
|
|||
|
|
case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>exp</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Expiration time on or after which the ID Token MUST NOT be
|
|||
|
|
accepted for processing. The processing of this parameter
|
|||
|
|
requires that the current date/time MUST be before the
|
|||
|
|
expiration date/time listed in the value. Implementers MAY
|
|||
|
|
provide for some small leeway, usually no more than a few
|
|||
|
|
minutes, to account for clock skew.
|
|||
|
|
Its value is a JSON number representing the number of seconds from
|
|||
|
|
1970-01-01T0:0:0Z as measured in UTC until the date/time.
|
|||
|
|
See <a class="info" href="#RFC3339">RFC
|
|||
|
|
3339<span> (</span><span class="info">Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a>
|
|||
|
|
[RFC3339]
|
|||
|
|
for details regarding date/times in general and UTC in
|
|||
|
|
particular.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>iat</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Time at which the JWT was issued.
|
|||
|
|
Its value is a JSON number representing the number of seconds from
|
|||
|
|
1970-01-01T0:0:0Z as measured in UTC until the date/time.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>auth_time</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Time when the End-User authentication occurred.
|
|||
|
|
Its value is a JSON number representing the number of seconds from
|
|||
|
|
1970-01-01T0:0:0Z as measured in UTC until the date/time.
|
|||
|
|
When a <tt>max_age</tt> request is made
|
|||
|
|
or when <tt>auth_time</tt> is requested
|
|||
|
|
as an Essential Claim,
|
|||
|
|
then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
|
|||
|
|
(The <tt>auth_time</tt> Claim semantically
|
|||
|
|
corresponds to the OpenID 2.0 <a class="info"
|
|||
|
|
href="#OpenID.PAPE">PAPE<span> (</span><span
|
|||
|
|
class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.</span><span>)</span></a>
|
|||
|
|
[OpenID.PAPE]
|
|||
|
|
<tt>auth_time</tt> response parameter.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>nonce</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
String value used to associate a Client session
|
|||
|
|
with an ID Token, and to mitigate replay attacks.
|
|||
|
|
The value is passed through unmodified from the Authentication Request to the ID Token.
|
|||
|
|
If present in the ID Token,
|
|||
|
|
Clients MUST verify that
|
|||
|
|
the <tt>nonce</tt> Claim Value is equal to
|
|||
|
|
the value of the <tt>nonce</tt>
|
|||
|
|
parameter sent in the Authentication Request.
|
|||
|
|
If present in the Authentication Request, Authorization Servers
|
|||
|
|
MUST include a <tt>nonce</tt> Claim in the
|
|||
|
|
ID Token with the Claim Value
|
|||
|
|
being the nonce value sent in the Authentication Request.
|
|||
|
|
Authorization Servers SHOULD perform no other processing
|
|||
|
|
on <tt>nonce</tt> values used.
|
|||
|
|
The <tt>nonce</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>acr</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Authentication Context Class Reference.
|
|||
|
|
String specifying an Authentication Context Class Reference value
|
|||
|
|
that identifies the Authentication Context Class that the
|
|||
|
|
authentication performed satisfied.
|
|||
|
|
The value "0" indicates the End-User authentication
|
|||
|
|
did not meet the requirements of
|
|||
|
|
<a class="info" href="#ISO29115">ISO/IEC
|
|||
|
|
29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.</span><span>)</span></a>
|
|||
|
|
[ISO29115] level 1.
|
|||
|
|
Authentication using a long-lived browser cookie, for instance, is one
|
|||
|
|
example where the use of "level 0" is appropriate. Authentications with
|
|||
|
|
level 0 SHOULD NOT be used to authorize access to any resource of any
|
|||
|
|
monetary value.
|
|||
|
|
(This corresponds to the OpenID 2.0
|
|||
|
|
<a class="info"
|
|||
|
|
href="#OpenID.PAPE">PAPE<span> (</span><span
|
|||
|
|
class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.</span><span>)</span></a>
|
|||
|
|
[OpenID.PAPE]
|
|||
|
|
<tt>nist_auth_level</tt> 0.)
|
|||
|
|
An absolute URI or an <a class="info" href="#RFC6711">RFC
|
|||
|
|
6711<span> (</span><span class="info">Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6711]
|
|||
|
|
registered name
|
|||
|
|
SHOULD be used as the <tt>acr</tt> value;
|
|||
|
|
registered names MUST NOT be used with a different meaning than
|
|||
|
|
that which is registered.
|
|||
|
|
Parties using this claim will need to agree upon the meanings of
|
|||
|
|
the values used, which may be context-specific.
|
|||
|
|
The <tt>acr</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>amr</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Authentication Methods References.
|
|||
|
|
JSON array of strings that are identifiers for authentication methods
|
|||
|
|
used in the authentication.
|
|||
|
|
For instance, values might indicate that both password and OTP
|
|||
|
|
authentication methods were used.
|
|||
|
|
The definition of particular values to be used in the
|
|||
|
|
<tt>amr</tt> Claim
|
|||
|
|
is beyond the scope of this specification.
|
|||
|
|
Parties using this claim will need to agree upon the meanings of
|
|||
|
|
the values used, which may be context-specific.
|
|||
|
|
The <tt>amr</tt> value is an array of
|
|||
|
|
case sensitive strings.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>azp</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Authorized party - the party to which the ID Token was issued.
|
|||
|
|
If present, it MUST contain the OAuth 2.0
|
|||
|
|
Client ID of this party.
|
|||
|
|
This Claim is only needed when
|
|||
|
|
the ID Token has a single audience value
|
|||
|
|
and that audience is different than the authorized party.
|
|||
|
|
It MAY be included even when the authorized party is the same
|
|||
|
|
as the sole audience.
|
|||
|
|
The <tt>azp</tt> value is a case sensitive string
|
|||
|
|
containing a StringOrURI value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
ID Tokens MAY contain other Claims.
|
|||
|
|
Any Claims used that are not understood MUST be ignored.
|
|||
|
|
See Sections
|
|||
|
|
<a class="info" href="#CodeIDToken">3.1.3.6<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#HybridIDToken">3.3.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
<a class="info" href="#StandardClaims">5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a>, and
|
|||
|
|
<a class="info"
|
|||
|
|
href="#SelfIssuedResponse">7.4<span> (</span><span
|
|||
|
|
class="info">Self-Issued OpenID Provider Response</span><span>)</span></a>
|
|||
|
|
for additional Claims defined by this specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
ID Tokens MUST be signed using <a class="info"
|
|||
|
|
href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] and optionally both signed and then
|
|||
|
|
encrypted using <a class="info"
|
|||
|
|
href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] and <a class="info" href="#JWE">JWE<span> (</span><span
|
|||
|
|
class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE] respectively, thereby providing
|
|||
|
|
authentication, integrity,
|
|||
|
|
non-repudiation, and optionally, confidentiality,
|
|||
|
|
per <a class="info"
|
|||
|
|
href="#SigningOrder">Section 16.14<span> (</span><span
|
|||
|
|
class="info">Signing and Encryption Order</span><span>)</span></a>.
|
|||
|
|
If the ID Token is encrypted, it MUST be signed then encrypted,
|
|||
|
|
with the result being a Nested JWT, as defined in <a class="info"
|
|||
|
|
href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
ID Tokens MUST NOT use <tt>none</tt>
|
|||
|
|
as the <tt>alg</tt> value
|
|||
|
|
unless the Response Type used returns no ID Token from the
|
|||
|
|
Authorization Endpoint
|
|||
|
|
(such as when using the Authorization Code Flow)
|
|||
|
|
and the Client explicitly requested the use of
|
|||
|
|
<tt>none</tt> at Registration time.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
ID Tokens SHOULD NOT use the JWS or JWE
|
|||
|
|
<tt>x5u</tt>,
|
|||
|
|
<tt>x5c</tt>,
|
|||
|
|
<tt>jku</tt>, or
|
|||
|
|
<tt>jwk</tt>
|
|||
|
|
Header Parameter fields.
|
|||
|
|
Instead, references to keys used are
|
|||
|
|
communicated in advance using Discovery and Registration parameters,
|
|||
|
|
per <a class="info"
|
|||
|
|
href="#SigEnc">Section 10<span> (</span><span
|
|||
|
|
class="info">Signatures and Encryption</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of
|
|||
|
|
the set of Claims (the JWT Claims Set) in an ID Token:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "https://server.example.com",
|
|||
|
|
"sub": "24400320",
|
|||
|
|
"aud": "s6BhdRkqt3",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"auth_time": 1311280969,
|
|||
|
|
"acr": "urn:mace:incommon:iap:silver"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="Authentication"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.
|
|||
|
|
Authentication</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect performs authentication to log in the End-User
|
|||
|
|
or to determine that the End-User is already logged in.
|
|||
|
|
OpenID Connect returns the result of the Authentication
|
|||
|
|
performed by the Server to the Client in a secure manner
|
|||
|
|
so that the Client can rely on it.
|
|||
|
|
For this reason, the Client is called Relying Party (RP) in this case.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authentication result is returned in an
|
|||
|
|
ID Token, as defined in <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
It has Claims expressing such information as the Issuer,
|
|||
|
|
the Subject Identifier, when the authentication expires, etc.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Authentication can follow one of three paths:
|
|||
|
|
the Authorization Code Flow (<tt>response_type=code</tt>),
|
|||
|
|
the Implicit Flow (<tt>response_type=id_token token</tt>
|
|||
|
|
or <tt>response_type=id_token</tt>), or
|
|||
|
|
the Hybrid Flow (using other Response Type values defined in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses]).
|
|||
|
|
The flows determine how the ID Token and Access Token
|
|||
|
|
are returned to the Client.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The characteristics of the three flows are summarized
|
|||
|
|
in the following non-normative table.
|
|||
|
|
The table is intended to provide some guidance on which flow to choose
|
|||
|
|
in particular contexts.
|
|||
|
|
|
|||
|
|
</p><br>
|
|||
|
|
<hr class="insert">
|
|||
|
|
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
|
|||
|
|
<colgroup>
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
</colgroup>
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<th align="left">Property</th>
|
|||
|
|
<th align="left">Authorization Code Flow</th>
|
|||
|
|
<th align="left">Implicit Flow</th>
|
|||
|
|
<th align="left">Hybrid Flow</th>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">All tokens returned from Authorization Endpoint</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">All tokens returned from Token Endpoint</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">Tokens not revealed to User Agent</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">Client can be authenticated</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">Refresh Token possible</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">Communication in one round trip</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">Most communication server-to-server</td>
|
|||
|
|
<td align="left">yes</td>
|
|||
|
|
<td align="left">no</td>
|
|||
|
|
<td align="left">varies</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<br clear="all">
|
|||
|
|
<table border="0" cellpadding="0" cellspacing="2" align="center">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td align="center"><font face="monaco, MS Sans Serif" size="1"><b> OpenID Connect Authentication Flows </b></font><br>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<hr class="insert">
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The flow used is determined by the <tt>response_type</tt>
|
|||
|
|
value contained in the Authorization Request.
|
|||
|
|
These <tt>response_type</tt> values select
|
|||
|
|
these flows:
|
|||
|
|
|
|||
|
|
</p><br>
|
|||
|
|
<hr class="insert">
|
|||
|
|
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
|
|||
|
|
<colgroup>
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
</colgroup>
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<th align="left">"response_type" value</th>
|
|||
|
|
<th align="left">Flow</th>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>code</tt> </td>
|
|||
|
|
<td align="left">Authorization Code Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>id_token</tt> </td>
|
|||
|
|
<td align="left">Implicit Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>id_token token</tt> </td>
|
|||
|
|
<td align="left">Implicit Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>code id_token</tt> </td>
|
|||
|
|
<td align="left">Hybrid Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>code token</tt> </td>
|
|||
|
|
<td align="left">Hybrid Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left"><tt>code id_token token</tt> </td>
|
|||
|
|
<td align="left">Hybrid Flow</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<br clear="all">
|
|||
|
|
<table border="0" cellpadding="0" cellspacing="2" align="center">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td align="center"><font face="monaco, MS Sans Serif" size="1"><b> OpenID Connect "response_type" Values </b></font><br>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<hr class="insert">
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
All but the <tt>code</tt> Response Type value,
|
|||
|
|
which is defined by <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
are defined in the
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses]
|
|||
|
|
specification.
|
|||
|
|
NOTE: While OAuth 2.0 also defines the
|
|||
|
|
<tt>token</tt> Response Type value
|
|||
|
|
for the Implicit Flow, OpenID Connect does not use this Response Type,
|
|||
|
|
since no ID Token would be returned.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="CodeFlowAuth"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.
|
|||
|
|
Authentication using the Authorization Code Flow</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This section describes how to perform authentication using the Authorization Code Flow.
|
|||
|
|
When using the Authorization Code Flow,
|
|||
|
|
all tokens are returned from the Token Endpoint.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The Authorization Code Flow returns an Authorization Code to the
|
|||
|
|
Client, which can then exchange it for an ID Token and an Access Token directly.
|
|||
|
|
This provides the benefit of not exposing any tokens to the
|
|||
|
|
User Agent and possibly other malicious applications with access
|
|||
|
|
to the 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.
|
|||
|
|
</p>
|
|||
|
|
<a name="CodeFlowSteps"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.1.
|
|||
|
|
Authorization Code Flow Steps</h3>
|
|||
|
|
|
|||
|
|
<p>The Authorization Code Flow goes through the following
|
|||
|
|
steps.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Client prepares an Authentication Request containing the desired
|
|||
|
|
request parameters.
|
|||
|
|
</li>
|
|||
|
|
<li>Client sends the request to the Authorization Server.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server Authenticates the End-User.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server obtains End-User Consent/Authorization.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server sends the End-User back to the Client with
|
|||
|
|
an Authorization Code.
|
|||
|
|
</li>
|
|||
|
|
<li>Client requests a response using the Authorization Code at the
|
|||
|
|
Token Endpoint.
|
|||
|
|
</li>
|
|||
|
|
<li>Client receives a response that contains an ID Token
|
|||
|
|
and Access Token in the response body.
|
|||
|
|
</li>
|
|||
|
|
<li>Client validates the ID token and retrieves the End-User's
|
|||
|
|
Subject Identifier.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AuthorizationEndpoint"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.
|
|||
|
|
Authorization Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Endpoint performs Authentication of the
|
|||
|
|
End-User.
|
|||
|
|
This is done by sending the User Agent to
|
|||
|
|
the Authorization Server's Authorization Endpoint for Authentication and
|
|||
|
|
Authorization, using request parameters defined by OAuth 2.0 and
|
|||
|
|
additional parameters and parameter values defined by OpenID Connect.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Communication with the Authorization Endpoint MUST utilize TLS.
|
|||
|
|
See <a class="info"
|
|||
|
|
href="#TLSRequirements">Section 16.17<span> (</span><span
|
|||
|
|
class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AuthRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.1.
|
|||
|
|
Authentication Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
An Authentication Request is
|
|||
|
|
an OAuth 2.0 Authorization Request that requests that the End-User
|
|||
|
|
be authenticated by the Authorization Server.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Authorization Servers MUST support the use of the HTTP <tt>GET</tt> and
|
|||
|
|
<tt>POST</tt> 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.
|
|||
|
|
Clients MAY use the HTTP <tt>GET</tt> or
|
|||
|
|
<tt>POST</tt> methods to send the
|
|||
|
|
Authorization Request to the Authorization Server. If using the HTTP
|
|||
|
|
<tt>GET</tt> method, the request parameters are serialized using
|
|||
|
|
URI Query String Serialization, per <a class="info"
|
|||
|
|
href="#QuerySerialization">Section 13.1<span> (</span><span
|
|||
|
|
class="info">Query String Serialization</span><span>)</span></a>.
|
|||
|
|
If using the HTTP <tt>POST</tt>
|
|||
|
|
method, the request parameters are serialized using
|
|||
|
|
Form Serialization, per <a class="info"
|
|||
|
|
href="#FormSerialization">Section 13.2<span> (</span><span
|
|||
|
|
class="info">Form Serialization</span><span>)</span></a>.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect uses the following OAuth 2.0 request parameters with
|
|||
|
|
the Authorization Code Flow:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>scope</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OpenID Connect requests MUST contain the <tt>openid</tt> scope value.
|
|||
|
|
If the <tt>openid</tt> scope value is not present,
|
|||
|
|
the behavior is entirely unspecified.
|
|||
|
|
Other scope values MAY be present.
|
|||
|
|
Scope values used that are not understood by an implementation SHOULD be ignored.
|
|||
|
|
See Sections <a class="info"
|
|||
|
|
href="#ScopeClaims">5.4<span> (</span><span
|
|||
|
|
class="info">Requesting Claims using Scope Values</span><span>)</span></a>
|
|||
|
|
and <a class="info"
|
|||
|
|
href="#OfflineAccess">11<span> (</span><span
|
|||
|
|
class="info">Offline Access</span><span>)</span></a>
|
|||
|
|
for additional scope values defined by this specification.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>response_type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OAuth 2.0 Response Type value that determines
|
|||
|
|
the authorization processing flow to be used,
|
|||
|
|
including what parameters are returned from the endpoints used.
|
|||
|
|
When using the Authorization Code Flow, this value is
|
|||
|
|
<tt>code</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>client_id</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OAuth 2.0 Client Identifier
|
|||
|
|
valid at the Authorization Server.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>redirect_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Redirection URI to which the response will be sent.
|
|||
|
|
This URI MUST exactly match one of the Redirection URI values
|
|||
|
|
for the Client pre-registered at the OpenID Provider,
|
|||
|
|
with the matching performed as described in
|
|||
|
|
Section 6.2.1 of <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span
|
|||
|
|
class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a>
|
|||
|
|
(Simple String Comparison).
|
|||
|
|
When using this flow, the Redirection URI
|
|||
|
|
SHOULD use the <tt>https</tt> scheme;
|
|||
|
|
however, it MAY use the <tt>http</tt> scheme,
|
|||
|
|
provided that the Client Type is
|
|||
|
|
<tt>confidential</tt>,
|
|||
|
|
as defined in Section 2.1 of OAuth 2.0, and
|
|||
|
|
provided the OP allows the use of
|
|||
|
|
<tt>http</tt> Redirection URIs in this case.
|
|||
|
|
The Redirection URI MAY use an alternate scheme,
|
|||
|
|
such as one that is intended to identify a callback into a native application.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>state</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
RECOMMENDED.
|
|||
|
|
Opaque value used
|
|||
|
|
to maintain state between the request and the callback.
|
|||
|
|
Typically, Cross-Site Request Forgery (CSRF, XSRF)
|
|||
|
|
mitigation is done by cryptographically binding the value of
|
|||
|
|
this parameter with a browser cookie.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect also uses the following OAuth 2.0 request parameter,
|
|||
|
|
which is defined in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses]:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>response_mode</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Informs the Authorization Server of the mechanism to be used
|
|||
|
|
for returning parameters from the Authorization Endpoint.
|
|||
|
|
This use of this parameter is NOT RECOMMENDED when the Response Mode
|
|||
|
|
that would be requested is the default mode specified for the Response Type.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification also defines the following request parameters:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>nonce</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
String value used to associate a Client session
|
|||
|
|
with an ID Token, and to mitigate replay attacks.
|
|||
|
|
The value is passed through unmodified from the Authentication Request to the ID Token.
|
|||
|
|
Sufficient entropy MUST be present in the
|
|||
|
|
<tt>nonce</tt> values used to prevent
|
|||
|
|
attackers from guessing values.
|
|||
|
|
For implementation notes, see <a class="info"
|
|||
|
|
href="#NonceNotes">Section 15.5.2<span> (</span><span
|
|||
|
|
class="info">Nonce Implementation Notes</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>display</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
ASCII string value that specifies
|
|||
|
|
how the Authorization Server displays the authentication and
|
|||
|
|
consent user interface pages to the End-User.
|
|||
|
|
The defined values are:
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>page</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD display the
|
|||
|
|
authentication and consent UI consistent with a full User Agent page
|
|||
|
|
view. If the display parameter is not specified, this is the
|
|||
|
|
default display mode.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>popup</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD display the
|
|||
|
|
authentication and consent UI consistent with a popup User Agent
|
|||
|
|
window.
|
|||
|
|
The popup User Agent window should be of an appropriate size
|
|||
|
|
for a login-focused dialog and should not obscure
|
|||
|
|
the entire window that it is popping up over.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>touch</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD display the
|
|||
|
|
authentication and consent UI consistent with a device that
|
|||
|
|
leverages a touch interface.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>wap</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD display the
|
|||
|
|
authentication and consent UI consistent with a "feature phone"
|
|||
|
|
type display.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
The Authorization Server MAY also attempt to detect the capabilities
|
|||
|
|
of the User Agent and present an appropriate display.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>prompt</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Space delimited, case sensitive list of ASCII string values
|
|||
|
|
that specifies whether the Authorization Server prompts
|
|||
|
|
the End-User for reauthentication and consent.
|
|||
|
|
The defined values are:
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>none</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server
|
|||
|
|
MUST NOT display any authentication or consent
|
|||
|
|
user interface pages.
|
|||
|
|
An error is returned
|
|||
|
|
if an End-User
|
|||
|
|
is not already authenticated or the Client does not have
|
|||
|
|
pre-configured consent for the requested
|
|||
|
|
Claims or does not fulfill other conditions for processing the request.
|
|||
|
|
The error code will typically be
|
|||
|
|
<tt>login_required</tt>,
|
|||
|
|
<tt>interaction_required</tt>,
|
|||
|
|
or another code defined in <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a>.
|
|||
|
|
This can be used as a
|
|||
|
|
method to check for existing authentication and/or consent.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>login</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD prompt the
|
|||
|
|
End-User for reauthentication.
|
|||
|
|
If it cannot reauthenticate the End-User, it MUST return an error,
|
|||
|
|
typically <tt>login_required</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>consent</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD prompt the End-User for consent
|
|||
|
|
before returning information to the Client.
|
|||
|
|
If it cannot obtain consent, it MUST return an error,
|
|||
|
|
typically <tt>consent_required</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>select_account</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server SHOULD
|
|||
|
|
prompt the End-User to select a user account. This enables
|
|||
|
|
an End-User who has multiple accounts at the Authorization Server
|
|||
|
|
to select amongst the multiple accounts that they might have
|
|||
|
|
current sessions for.
|
|||
|
|
If it cannot obtain an account selection choice made by the End-User,
|
|||
|
|
it MUST return an error,
|
|||
|
|
typically <tt>account_selection_required</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
The <tt>prompt</tt> parameter
|
|||
|
|
can be used by the Client to make sure that the End-User is
|
|||
|
|
still present for the current session or to bring attention to the
|
|||
|
|
request. If this parameter contains <tt>none</tt>
|
|||
|
|
with any other value, an
|
|||
|
|
error is returned.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>max_age</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Maximum Authentication Age.
|
|||
|
|
Specifies the allowable elapsed time in seconds
|
|||
|
|
since the last time the End-User was actively
|
|||
|
|
authenticated by the OP. If the elapsed time is greater than
|
|||
|
|
this value, the OP MUST attempt to actively
|
|||
|
|
re-authenticate the End-User.
|
|||
|
|
(The <tt>max_age</tt> request parameter corresponds to
|
|||
|
|
the OpenID 2.0 <a class="info"
|
|||
|
|
href="#OpenID.PAPE">PAPE<span> (</span><span
|
|||
|
|
class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.</span><span>)</span></a>
|
|||
|
|
[OpenID.PAPE]
|
|||
|
|
<tt>max_auth_age</tt> request parameter.)
|
|||
|
|
When <tt>max_age</tt> is used, the ID Token returned
|
|||
|
|
MUST include an <tt>auth_time</tt> Claim Value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>ui_locales</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
End-User's preferred languages and scripts for the user interface,
|
|||
|
|
represented as a space-separated list of
|
|||
|
|
<a class="info"
|
|||
|
|
href="#RFC5646">BCP47<span> (</span><span
|
|||
|
|
class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a>
|
|||
|
|
[RFC5646] language tag values,
|
|||
|
|
ordered by preference.
|
|||
|
|
For instance, the value "fr-CA fr en" represents a preference
|
|||
|
|
for French as spoken in Canada,
|
|||
|
|
then French (without a region designation),
|
|||
|
|
followed by English (without a region designation).
|
|||
|
|
An error SHOULD NOT result if some or all of the requested locales
|
|||
|
|
are not supported by the OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>id_token_hint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
ID Token previously issued by the Authorization Server
|
|||
|
|
being passed as a hint about the End-User's current or past
|
|||
|
|
authenticated session with the Client.
|
|||
|
|
If the End-User identified by the ID Token is logged in or is logged in by the request,
|
|||
|
|
then the Authorization Server returns a positive response;
|
|||
|
|
otherwise, it SHOULD return
|
|||
|
|
an error, such as <tt>login_required</tt>.
|
|||
|
|
When possible, an <tt>id_token_hint</tt>
|
|||
|
|
SHOULD be present when <tt>prompt=none</tt> is used
|
|||
|
|
and an <tt>invalid_request</tt> error
|
|||
|
|
MAY be returned if it is not;
|
|||
|
|
however, the server SHOULD respond successfully when possible,
|
|||
|
|
even if it is not present.
|
|||
|
|
The Authorization Server need not be listed as an
|
|||
|
|
audience of the ID Token when it is used as an
|
|||
|
|
<tt>id_token_hint</tt> value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
If the ID Token received by the RP from the OP is encrypted,
|
|||
|
|
to use it as an <tt>id_token_hint</tt>, the Client MUST
|
|||
|
|
decrypt the signed ID Token contained within the encrypted ID Token.
|
|||
|
|
The Client MAY re-encrypt the signed ID token to the Authentication Server
|
|||
|
|
using a key that enables the server to decrypt the ID Token,
|
|||
|
|
and use the re-encrypted ID token as the
|
|||
|
|
<tt>id_token_hint</tt> value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>login_hint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Hint to the Authorization Server
|
|||
|
|
about the login identifier the End-User might use to log in (if necessary).
|
|||
|
|
This hint can be used by an RP if it first asks the End-User for their e-mail
|
|||
|
|
address (or other identifier) and then wants to pass that value as a hint
|
|||
|
|
to the discovered authorization service.
|
|||
|
|
It is RECOMMENDED that the hint value match the value used for discovery.
|
|||
|
|
This value MAY also be a phone number in the format specified for the
|
|||
|
|
<tt>phone_number</tt> Claim.
|
|||
|
|
The use of this parameter is left to the OP's discretion.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>acr_values</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Requested Authentication Context Class Reference values.
|
|||
|
|
Space-separated string that specifies the <tt>acr</tt>
|
|||
|
|
values that the Authorization Server is being requested to use
|
|||
|
|
for processing this Authentication Request,
|
|||
|
|
with the values appearing in order of preference.
|
|||
|
|
The Authentication Context Class satisfied by the authentication
|
|||
|
|
performed is returned as the <tt>acr</tt> Claim Value,
|
|||
|
|
as specified in <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
The <tt>acr</tt> Claim is requested as
|
|||
|
|
a Voluntary Claim by this parameter.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Other parameters MAY be sent.
|
|||
|
|
See Sections <a class="info"
|
|||
|
|
href="#ImplicitAuthorizationEndpoint">3.2.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>,
|
|||
|
|
<a class="info" href="#HybridAuthorizationEndpoint">3.3.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ClaimsLanguagesAndScripts">5.2<span> (</span><span
|
|||
|
|
class="info">Claims Languages and Scripts</span><span>)</span></a>,
|
|||
|
|
<a class="info" href="#ClaimsParameter">5.5<span> (</span><span
|
|||
|
|
class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a>,
|
|||
|
|
<a class="info" href="#JWTRequests">6<span> (</span><span
|
|||
|
|
class="info">Passing Request Parameters as JWTs</span><span>)</span></a>, and
|
|||
|
|
<a class="info"
|
|||
|
|
href="#RegistrationParameter">7.2.1<span> (</span><span
|
|||
|
|
class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>
|
|||
|
|
for additional Authorization Request parameters and parameter values
|
|||
|
|
defined by this specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example
|
|||
|
|
HTTP 302 redirect response by the Client, which triggers
|
|||
|
|
the User Agent to make an Authentication Request
|
|||
|
|
to the Authorization Endpoint
|
|||
|
|
(with line wraps within values for display purposes 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
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
The following is the non-normative example request
|
|||
|
|
that would be sent by the User Agent to the Authorization Server
|
|||
|
|
in response to the HTTP 302 redirect response by the Client above
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="AuthRequestValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.2.
|
|||
|
|
Authentication Request Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST validate the request received as follows:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The Authorization Server MUST validate all the
|
|||
|
|
OAuth 2.0 parameters according to the OAuth 2.0 specification.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Verify that a <tt>scope</tt> parameter is present
|
|||
|
|
and contains the <tt>openid</tt> scope value.
|
|||
|
|
(If no <tt>openid</tt> scope value is present,
|
|||
|
|
the request may still be a valid OAuth 2.0 request,
|
|||
|
|
but is not an OpenID Connect request.)
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Authorization Server MUST verify that all the REQUIRED parameters
|
|||
|
|
are present
|
|||
|
|
and their usage conforms to this specification.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If the <tt>sub</tt> (subject) Claim
|
|||
|
|
is requested with a specific value for the ID Token,
|
|||
|
|
the Authorization Server MUST only send a positive response
|
|||
|
|
if the End-User identified by that <tt>sub</tt> value
|
|||
|
|
has an active session with the Authorization Server
|
|||
|
|
or has been Authenticated as a result of the request.
|
|||
|
|
The Authorization Server MUST NOT reply with an ID Token or
|
|||
|
|
Access Token for a different user,
|
|||
|
|
even if they have an active session with the Authorization Server.
|
|||
|
|
Such a request can be made either using an
|
|||
|
|
<tt>id_token_hint</tt> parameter
|
|||
|
|
or by requesting a specific Claim Value
|
|||
|
|
as described in <a class="info"
|
|||
|
|
href="#IndividualClaimsRequests">Section 5.5.1<span> (</span><span
|
|||
|
|
class="info">Individual Claims Requests</span><span>)</span></a>,
|
|||
|
|
if the <tt>claims</tt> parameter
|
|||
|
|
is supported by the implementation.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
As specified in <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
Authorization Servers SHOULD ignore unrecognized request parameters.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the Authorization Server encounters any error,
|
|||
|
|
it MUST return an error response, per <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Authenticates"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.3.
|
|||
|
|
Authorization Server Authenticates End-User</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the request is valid, the Authorization Server attempts
|
|||
|
|
to Authenticate the End-User or determines whether the End-User is Authenticated,
|
|||
|
|
depending upon the request parameter values used.
|
|||
|
|
The methods used by the Authorization Server to Authenticate the End-User
|
|||
|
|
(e.g. username and password, session cookies, etc.)
|
|||
|
|
are beyond the scope of this specification.
|
|||
|
|
An Authentication user interface MAY be displayed by
|
|||
|
|
the Authorization Server, depending upon the request parameter values used
|
|||
|
|
and the authentication methods used.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The Authorization Server MUST attempt to Authenticate the
|
|||
|
|
End-User in the following cases:
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>The End-User is not already Authenticated.
|
|||
|
|
</li>
|
|||
|
|
<li>The Authentication Request contains the <tt>prompt</tt> parameter with the value
|
|||
|
|
<tt>login</tt>. In this case, the
|
|||
|
|
Authorization Server MUST reauthenticate the End-User
|
|||
|
|
even if the End-User is already authenticated.
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The Authorization Server MUST NOT interact with the End-User
|
|||
|
|
in the following case:
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>The Authentication Request contains the <tt>prompt</tt> parameter with the value
|
|||
|
|
<tt>none</tt>. In this case,
|
|||
|
|
the Authorization Server MUST return
|
|||
|
|
an error if an End-User
|
|||
|
|
is not already Authenticated or could not be silently Authenticated.
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When interacting with the End-User,
|
|||
|
|
the Authorization Server MUST employ appropriate measures against
|
|||
|
|
Cross-Site Request Forgery and Clickjacking as, described in
|
|||
|
|
Sections 10.12 and 10.13 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Consent"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.4"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.4.
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Once the End-User is authenticated, the Authorization Server MUST
|
|||
|
|
obtain an authorization decision before releasing information
|
|||
|
|
to the Relying Party.
|
|||
|
|
When permitted by the request parameters used,
|
|||
|
|
this MAY be done through an interactive dialogue with the End-User
|
|||
|
|
that makes it clear what is being consented to
|
|||
|
|
or by establishing consent via conditions for processing the request or
|
|||
|
|
other means (for example, via previous administrative consent).
|
|||
|
|
Sections <a class="info" href="#IDToken">2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> and
|
|||
|
|
<a class="info" href="#UserInfo">5.3<span> (</span><span
|
|||
|
|
class="info">UserInfo Endpoint</span><span>)</span></a> describe
|
|||
|
|
information release mechanisms.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AuthResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.5"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.5.
|
|||
|
|
Successful Authentication Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
An Authentication Response is an OAuth 2.0 Authorization Response
|
|||
|
|
message returned from the
|
|||
|
|
OP's Authorization Endpoint in response to the Authorization Request
|
|||
|
|
message sent by the RP.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Authorization Code Flow, the Authorization Response
|
|||
|
|
MUST return the parameters defined in Section 4.1.2 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749]
|
|||
|
|
by adding them as query parameters to the
|
|||
|
|
<tt>redirect_uri</tt> specified in the Authorization Request
|
|||
|
|
using the <tt>application/x-www-form-urlencoded</tt> format,
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example
|
|||
|
|
successful response using this flow
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb?
|
|||
|
|
code=SplxlOBeZQQYbYS6WxSbIA
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
For implementation notes on the contents of
|
|||
|
|
the Authorization Code, see <a class="info" href="#CodeNotes">Section 15.5.1<span> (</span><span
|
|||
|
|
class="info">Authorization Code Implementation Notes</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AuthError"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.6"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.6.
|
|||
|
|
Authentication Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
An Authentication Error Response is an OAuth 2.0 Authorization Error Response
|
|||
|
|
message returned from the
|
|||
|
|
OP's Authorization Endpoint in response to the Authorization Request
|
|||
|
|
message sent by the RP.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the End-User denies the request or the End-User authentication
|
|||
|
|
fails, the OP (Authorization Server) informs the RP (Client)
|
|||
|
|
by using the Error Response parameters defined in
|
|||
|
|
Section 4.1.2.1 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
(HTTP errors unrelated to RFC 6749 are returned to the User Agent using the
|
|||
|
|
appropriate HTTP status code.)
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Unless the Redirection URI is invalid,
|
|||
|
|
the Authorization Server returns the Client to
|
|||
|
|
the Redirection URI specified in the Authorization Request
|
|||
|
|
with the appropriate error and state parameters.
|
|||
|
|
Other parameters SHOULD NOT be returned.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In addition to the error codes defined in Section 4.1.2.1 of
|
|||
|
|
OAuth 2.0, this specification also defines the following error codes:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>interaction_required</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server
|
|||
|
|
requires End-User interaction of some form to proceed.
|
|||
|
|
This error MAY be returned when the
|
|||
|
|
<tt>prompt</tt> parameter value in the
|
|||
|
|
Authentication Request is <tt>none</tt>,
|
|||
|
|
but the Authentication Request cannot be completed
|
|||
|
|
without displaying a user interface for End-User interaction.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>login_required</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server requires
|
|||
|
|
End-User authentication. This error MAY be returned when the
|
|||
|
|
<tt>prompt</tt> parameter value in the
|
|||
|
|
Authentication Request is <tt>none</tt>,
|
|||
|
|
but the Authentication Request cannot be completed
|
|||
|
|
without displaying a user interface for End-User authentication.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>account_selection_required</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The End-User is REQUIRED
|
|||
|
|
to select a session at the Authorization Server. The End-User MAY
|
|||
|
|
be authenticated at the Authorization Server with different
|
|||
|
|
associated accounts, but the End-User did not select a session.
|
|||
|
|
This error MAY be returned
|
|||
|
|
when the <tt>prompt</tt> parameter value in the
|
|||
|
|
Authentication Request is <tt>none</tt>,
|
|||
|
|
but the Authentication Request cannot be completed
|
|||
|
|
without displaying a user interface to prompt for a session to use.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>consent_required</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Authorization Server
|
|||
|
|
requires End-User consent. This error MAY be returned when the
|
|||
|
|
<tt>prompt</tt> parameter value in the
|
|||
|
|
Authentication Request is <tt>none</tt>,
|
|||
|
|
but the Authentication Request cannot be completed
|
|||
|
|
without displaying a user interface for End-User consent.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>invalid_request_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The
|
|||
|
|
<tt>request_uri</tt> in
|
|||
|
|
the Authorization Request returns an error or contains invalid data.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>invalid_request_object</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The
|
|||
|
|
<tt>request</tt> parameter contains an invalid
|
|||
|
|
Request Object.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>request_not_supported</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The OP does not support use of the
|
|||
|
|
<tt>request</tt> parameter
|
|||
|
|
defined in <a class="info" href="#JWTRequests">Section 6<span> (</span><span
|
|||
|
|
class="info">Passing Request Parameters as JWTs</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>request_uri_not_supported</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The OP does not support use of the
|
|||
|
|
<tt>request_uri</tt> parameter
|
|||
|
|
defined in <a class="info" href="#JWTRequests">Section 6<span> (</span><span
|
|||
|
|
class="info">Passing Request Parameters as JWTs</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>registration_not_supported</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The OP does not support use of the
|
|||
|
|
<tt>registration</tt> parameter
|
|||
|
|
defined in <a class="info"
|
|||
|
|
href="#RegistrationParameter">Section 7.2.1<span> (</span><span
|
|||
|
|
class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The error response parameters are the following:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>error</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED. Error code.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>error_description</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. Human-readable ASCII
|
|||
|
|
encoded text description of the error.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>error_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. URI of a web page that
|
|||
|
|
includes additional information about the error.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>state</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 state value.
|
|||
|
|
REQUIRED if the Authorization Request
|
|||
|
|
included the <tt>state</tt> parameter. Set
|
|||
|
|
to the value received from the Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Authorization Code Flow, the error response
|
|||
|
|
parameters are added to the query component of the Redirection URI,
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example
|
|||
|
|
error response using this flow
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb?
|
|||
|
|
error=invalid_request
|
|||
|
|
&error_description=
|
|||
|
|
Unsupported%20response_type%20value
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="AuthResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.2.7"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.2.7.
|
|||
|
|
Authentication Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Authorization Code Flow,
|
|||
|
|
the Client MUST validate the response according to RFC 6749,
|
|||
|
|
especially Sections 4.1.2 and 10.12.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenEndpoint"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.
|
|||
|
|
Token Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To obtain an Access Token, an ID Token, and optionally a Refresh Token,
|
|||
|
|
the RP (Client) sends a Token Request to the Token Endpoint
|
|||
|
|
to obtain a Token Response, as described in
|
|||
|
|
Section 3.2 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
when using the Authorization Code Flow.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Communication with the Token Endpoint MUST utilize TLS.
|
|||
|
|
See <a class="info"
|
|||
|
|
href="#TLSRequirements">Section 16.17<span> (</span><span
|
|||
|
|
class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.1.
|
|||
|
|
Token Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
A Client makes a Token Request by
|
|||
|
|
presenting its Authorization Grant (in the form of
|
|||
|
|
an Authorization Code) to the Token Endpoint
|
|||
|
|
using the <tt>grant_type</tt> value
|
|||
|
|
<tt>authorization_code</tt>, as described in
|
|||
|
|
Section 4.1.3 of <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
If the Client is a Confidential Client, then it MUST
|
|||
|
|
authenticate to the Token Endpoint using the authentication method
|
|||
|
|
registered for its <tt>client_id</tt>,
|
|||
|
|
as described in <a class="info" href="#ClientAuthentication">Section 9<span> (</span><span
|
|||
|
|
class="info">Client Authentication</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Client sends the parameters to the Token Endpoint
|
|||
|
|
using the HTTP <tt>POST</tt> method and the
|
|||
|
|
Form Serialization, per <a class="info"
|
|||
|
|
href="#FormSerialization">Section 13.2<span> (</span><span
|
|||
|
|
class="info">Form Serialization</span><span>)</span></a>,
|
|||
|
|
as described in Section 4.1.3 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of a Token Request
|
|||
|
|
(with line wraps within values for display purposes 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
|
|||
|
|
|
|||
|
|
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="TokenRequestValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.2.
|
|||
|
|
Token Request Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST validate the Token Request as follows:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Authenticate the Client if it was issued Client Credentials
|
|||
|
|
or if it uses another Client Authentication method,
|
|||
|
|
per <a class="info" href="#ClientAuthentication">Section 9<span> (</span><span
|
|||
|
|
class="info">Client Authentication</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Ensure the
|
|||
|
|
Authorization Code was issued to the authenticated Client.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Verify that the Authorization Code is valid.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If possible,
|
|||
|
|
verify that the Authorization Code has not been previously used.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Ensure that the
|
|||
|
|
<tt>redirect_uri</tt> parameter value
|
|||
|
|
is identical to the <tt>redirect_uri</tt>
|
|||
|
|
parameter value that was included in the initial Authorization Request.
|
|||
|
|
If the <tt>redirect_uri</tt> parameter value
|
|||
|
|
is not present when there is only one registered
|
|||
|
|
<tt>redirect_uri</tt> value,
|
|||
|
|
the Authorization Server MAY return an error
|
|||
|
|
(since the Client should have included the parameter)
|
|||
|
|
or MAY proceed without an error
|
|||
|
|
(since OAuth 2.0 permits the parameter to be omitted in this case).
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Verify that the Authorization Code used was issued
|
|||
|
|
in response to an OpenID Connect Authentication Request
|
|||
|
|
(so that an ID Token will be returned from the Token Endpoint).
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.3.
|
|||
|
|
Successful Token Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
After receiving and validating a valid and authorized Token Request
|
|||
|
|
from the Client, the Authorization Server returns a successful
|
|||
|
|
response that includes an ID Token and an Access Token. The
|
|||
|
|
parameters in the successful response are defined in Section 4.1.4
|
|||
|
|
of <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
The response uses the <tt>application/json</tt>
|
|||
|
|
media type.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OAuth 2.0 <tt>token_type</tt> response parameter
|
|||
|
|
value MUST be <tt>Bearer</tt>,
|
|||
|
|
as specified in <a class="info" href="#RFC6750">OAuth 2.0 Bearer
|
|||
|
|
Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750],
|
|||
|
|
unless another Token Type has been negotiated with the Client.
|
|||
|
|
Servers SHOULD support the <tt>Bearer</tt> Token Type;
|
|||
|
|
use of other Token Types is outside the scope of this specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In addition to the response parameters specified by OAuth 2.0, the following
|
|||
|
|
parameters MUST be included in the response:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>id_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
ID Token value associated with the
|
|||
|
|
authenticated session.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
All Token Responses that contain tokens, secrets, or other
|
|||
|
|
sensitive information MUST include the following HTTP response header
|
|||
|
|
fields and values:
|
|||
|
|
|
|||
|
|
</p><br>
|
|||
|
|
<hr class="insert">
|
|||
|
|
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
|
|||
|
|
<colgroup>
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
</colgroup>
|
|||
|
|
<tbody>
|
|||
|
|
<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>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<br clear="all">
|
|||
|
|
<table border="0" cellpadding="0" cellspacing="2" align="center">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td align="center"><font face="monaco, MS Sans Serif" size="1"><b> HTTP Response Headers and
|
|||
|
|
Values </b></font><br></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<hr class="insert">
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of a successful Token Response.
|
|||
|
|
The ID Token signature in the example can be verified with the key at
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ExampleRSAKey">Appendix A.7<span> (</span><span
|
|||
|
|
class="info">RSA Key Used in Examples</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</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": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
|
|||
|
|
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
|
|||
|
|
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
|
|||
|
|
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
|
|||
|
|
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
|
|||
|
|
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
|
|||
|
|
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
|
|||
|
|
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
|
|||
|
|
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
|
|||
|
|
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>As specified in <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749], Clients
|
|||
|
|
SHOULD ignore unrecognized response parameters.
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenErrorResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.4"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.4.
|
|||
|
|
Token Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the Token Request is invalid or unauthorized, the
|
|||
|
|
Authorization Server constructs the error response. The parameters
|
|||
|
|
of the Token Error Response are defined as in Section 5.2 of <a class="info"
|
|||
|
|
href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
The HTTP response body uses the <tt>application/json</tt>
|
|||
|
|
media type with HTTP response code of 400.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example Token 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
|
|||
|
|
Cache-Control: no-store
|
|||
|
|
Pragma: no-cache
|
|||
|
|
|
|||
|
|
{
|
|||
|
|
"error": "invalid_request"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="TokenResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.5"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.5.
|
|||
|
|
Token Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Client MUST validate the Token Response as follows:
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
Follow the validation rules in RFC 6749,
|
|||
|
|
especially those in Sections 5.1 and 10.12.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the ID Token validation rules in <a class="info"
|
|||
|
|
href="#IDTokenValidation">Section 3.1.3.7<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the Access Token validation rules in <a class="info"
|
|||
|
|
href="#CodeFlowTokenValidation">Section 3.1.3.8<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="CodeIDToken"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.6"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.6.
|
|||
|
|
ID Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The contents of the ID Token are as described in <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
When using the Authorization Code Flow,
|
|||
|
|
these additional requirements for the following ID Token Claims apply:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>at_hash</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Access Token hash value.
|
|||
|
|
Its value is the base64url encoding of the left-most half of the
|
|||
|
|
hash of the octets of the ASCII representation of the
|
|||
|
|
<tt>access_token</tt> value,
|
|||
|
|
where the hash algorithm used is the hash algorithm
|
|||
|
|
used in the <tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>RS256</tt>, hash the
|
|||
|
|
<tt>access_token</tt> value
|
|||
|
|
with SHA-256, then take the left-most 128 bits and base64url encode them.
|
|||
|
|
The <tt>at_hash</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="IDTokenValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.7"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.7.
|
|||
|
|
ID Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Clients MUST validate the ID Token in the Token Response
|
|||
|
|
in the following manner:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
If the ID Token is encrypted, decrypt it using the
|
|||
|
|
keys and algorithms that the Client specified during Registration
|
|||
|
|
that the OP was to use to encrypt the ID Token.
|
|||
|
|
If encryption was negotiated with the OP at Registration time
|
|||
|
|
and the ID Token is not encrypted, the RP SHOULD reject it.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Issuer Identifier for the OpenID Provider
|
|||
|
|
(which is typically obtained during Discovery)
|
|||
|
|
MUST exactly match the value of the
|
|||
|
|
<tt>iss</tt> (issuer) Claim.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate that the
|
|||
|
|
<tt>aud</tt> (audience) Claim
|
|||
|
|
contains its <tt>client_id</tt> value
|
|||
|
|
registered at the Issuer identified by the
|
|||
|
|
<tt>iss</tt> (issuer) Claim
|
|||
|
|
as an audience.
|
|||
|
|
The <tt>aud</tt> (audience) Claim
|
|||
|
|
MAY contain an array with more than one element.
|
|||
|
|
The ID Token MUST be rejected if the ID Token does not list
|
|||
|
|
the Client as a valid audience, or if it contains additional audiences not trusted by the Client.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If the ID Token contains multiple audiences, the Client SHOULD verify
|
|||
|
|
that an <tt>azp</tt> Claim is present.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If an <tt>azp</tt> (authorized party) Claim is present,
|
|||
|
|
the Client SHOULD verify that its <tt>client_id</tt>
|
|||
|
|
is the Claim Value.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If the ID Token is received via direct
|
|||
|
|
communication between the Client and the Token Endpoint
|
|||
|
|
(which it is in this flow), the TLS server
|
|||
|
|
validation MAY be used to validate the issuer in place of
|
|||
|
|
checking the token signature.
|
|||
|
|
The Client MUST validate the signature of all other ID Tokens according to
|
|||
|
|
<a class="info" href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] using the algorithm specified in the
|
|||
|
|
JWT <tt>alg</tt> Header Parameter.
|
|||
|
|
The Client MUST use the keys provided by the Issuer.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>The <tt>alg</tt> value SHOULD be the default of
|
|||
|
|
<tt>RS256</tt>
|
|||
|
|
or the algorithm sent by the Client
|
|||
|
|
in the <tt>id_token_signed_response_alg</tt> parameter
|
|||
|
|
during Registration.
|
|||
|
|
</li>
|
|||
|
|
<li>If the JWT <tt>alg</tt> Header Parameter
|
|||
|
|
uses a MAC based algorithm such as
|
|||
|
|
<tt>HS256</tt>, <tt>HS384</tt>,
|
|||
|
|
or <tt>HS512</tt>,
|
|||
|
|
the octets of the UTF-8 representation of
|
|||
|
|
the <tt>client_secret</tt> corresponding to the
|
|||
|
|
<tt>client_id</tt> contained in the
|
|||
|
|
<tt>aud</tt> (audience) Claim are used as the key
|
|||
|
|
to validate the signature.
|
|||
|
|
For MAC based algorithms, the behavior is unspecified
|
|||
|
|
if the <tt>aud</tt> is multi-valued or
|
|||
|
|
if an <tt>azp</tt> value is present
|
|||
|
|
that is different than the <tt>aud</tt> value.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The current time MUST be before the time represented by the
|
|||
|
|
<tt>exp</tt> Claim.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>The <tt>iat</tt> Claim can be used to reject tokens that
|
|||
|
|
were issued too far away from the current time, limiting the amount of
|
|||
|
|
time that nonces need to be stored to prevent attacks.
|
|||
|
|
The acceptable range is Client specific.
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If a nonce value was sent in the Authentication Request,
|
|||
|
|
a <tt>nonce</tt> Claim MUST be present
|
|||
|
|
and its value checked to verify that
|
|||
|
|
it is the same value as the one that was sent in the Authentication Request.
|
|||
|
|
The Client SHOULD check the <tt>nonce</tt> value
|
|||
|
|
for replay attacks.
|
|||
|
|
The precise method for detecting replay attacks is Client specific.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>If the <tt>acr</tt> Claim was requested, the
|
|||
|
|
Client SHOULD check that the asserted Claim Value is appropriate.
|
|||
|
|
The meaning and processing of
|
|||
|
|
<tt>acr</tt> Claim Values is out of scope for this specification.
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If the <tt>auth_time</tt> Claim was requested,
|
|||
|
|
either through a specific request for this Claim
|
|||
|
|
or by using the <tt>max_age</tt> parameter,
|
|||
|
|
the Client SHOULD check the <tt>auth_time</tt> Claim
|
|||
|
|
value and request re-authentication if it determines too much time
|
|||
|
|
has elapsed since the last End-User authentication.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="CodeFlowTokenValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.1.3.8"></a>
|
|||
|
|
|
|||
|
|
<h3>3.1.3.8.
|
|||
|
|
Access Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Authorization Code Flow,
|
|||
|
|
if the ID Token contains an <tt>at_hash</tt> Claim,
|
|||
|
|
the Client MAY use it to validate the Access Token
|
|||
|
|
in the same manner as for the Implicit Flow,
|
|||
|
|
as defined in <a class="info" href="#ImplicitTokenValidation">Section 3.2.2.9<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>,
|
|||
|
|
but using the ID Token and Access Token returned from the Token Endpoint.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitFlowAuth"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.
|
|||
|
|
Authentication using the Implicit Flow</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This section describes how to perform authentication using the Implicit Flow.
|
|||
|
|
When using the Implicit Flow,
|
|||
|
|
all tokens are returned from the Authorization Endpoint;
|
|||
|
|
the Token Endpoint is not used.
|
|||
|
|
|
|||
|
|
</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 End-User and
|
|||
|
|
applications that have access to the End-User's User Agent.
|
|||
|
|
The Authorization Server does not perform Client Authentication.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitFlowSteps"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.1.
|
|||
|
|
Implicit Flow Steps</h3>
|
|||
|
|
|
|||
|
|
<p>The Implicit Flow follows the following steps:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Client prepares an Authentication Request containing the desired
|
|||
|
|
request parameters.
|
|||
|
|
</li>
|
|||
|
|
<li>Client sends the request to the Authorization Server.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server Authenticates the End-User.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server obtains End-User Consent/Authorization.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server sends the End-User back to the Client with
|
|||
|
|
an ID Token and, if requested, an Access Token.
|
|||
|
|
</li>
|
|||
|
|
<li>Client validates the ID token and retrieves the End-User's
|
|||
|
|
Subject Identifier.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitAuthorizationEndpoint"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.
|
|||
|
|
Authorization Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, the Authorization Endpoint is used
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitAuthRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.1.
|
|||
|
|
Authentication Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Authentication Requests are made
|
|||
|
|
as defined in <a class="info" href="#AuthRequest">Section 3.1.2.1<span> (</span><span
|
|||
|
|
class="info">Authentication Request</span><span>)</span></a>,
|
|||
|
|
except that these Authentication Request parameters
|
|||
|
|
are used as follows:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>response_type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OAuth 2.0 Response Type value that determines
|
|||
|
|
the authorization processing flow to be used,
|
|||
|
|
including what parameters are returned from the endpoints used.
|
|||
|
|
When using the Implicit Flow, this value is
|
|||
|
|
<tt>id_token token</tt> or
|
|||
|
|
<tt>id_token</tt>.
|
|||
|
|
The meanings of both of these values are defined in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0
|
|||
|
|
Multiple Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses].
|
|||
|
|
No Access Token is returned when the value is
|
|||
|
|
<tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
NOTE: While OAuth 2.0 also defines the
|
|||
|
|
<tt>token</tt> Response Type value
|
|||
|
|
for the Implicit Flow, OpenID Connect does not use this Response Type,
|
|||
|
|
since no ID Token would be returned.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>redirect_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Redirection URI to which the response will be sent.
|
|||
|
|
This URI MUST exactly match one of the Redirection URI values
|
|||
|
|
for the Client pre-registered at the OpenID Provider,
|
|||
|
|
with the matching performed as described in
|
|||
|
|
Section 6.2.1 of <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span
|
|||
|
|
class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a>
|
|||
|
|
(Simple String Comparison).
|
|||
|
|
When using this flow, the Redirection URI
|
|||
|
|
MUST NOT use the <tt>http</tt> scheme
|
|||
|
|
unless the Client is a native application, in which case it MAY
|
|||
|
|
use the <tt>http:</tt> scheme with
|
|||
|
|
<tt>localhost</tt> as the hostname.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>nonce</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
String value used to associate a Client session
|
|||
|
|
with an ID Token, and to mitigate replay attacks.
|
|||
|
|
The value is passed through unmodified from the Authentication Request to the ID Token.
|
|||
|
|
Sufficient entropy MUST be present in the
|
|||
|
|
<tt>nonce</tt> values used to prevent
|
|||
|
|
attackers from guessing values.
|
|||
|
|
For implementation notes, see <a class="info"
|
|||
|
|
href="#NonceNotes">Section 15.5.2<span> (</span><span
|
|||
|
|
class="info">Nonce Implementation Notes</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example request using the Implicit Flow
|
|||
|
|
that would be sent by the User Agent to the Authorization Server
|
|||
|
|
in response to a corresponding HTTP 302 redirect response by the Client
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=id_token%20token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
&nonce=n-0S6_WzA2Mj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="ImplicitValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.2.
|
|||
|
|
Authentication Request Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, the Authentication Request is validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthRequestValidation">Section 3.1.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitAuthenticates"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.3.
|
|||
|
|
Authorization Server Authenticates End-User</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, End-User Authentication is performed
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#Authenticates">Section 3.1.2.3<span> (</span><span
|
|||
|
|
class="info">Authorization Server Authenticates End-User</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitConsent"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.4"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.4.
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, End-User Consent is obtained
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#Consent">Section 3.1.2.4<span> (</span><span
|
|||
|
|
class="info">Authorization Server Obtains End-User Consent/Authorization</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitAuthResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.5"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.5.
|
|||
|
|
Successful Authentication Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, Authentication Responses are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthResponse">Section 3.1.2.5<span> (</span><span
|
|||
|
|
class="info">Successful Authentication Response</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow,
|
|||
|
|
all response parameters are added to the fragment component
|
|||
|
|
of the Redirection URI, as specified in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses],
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
These parameters are returned from the Authorization Endpoint:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>access_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Access Token.
|
|||
|
|
This is returned
|
|||
|
|
unless the <tt>response_type</tt> value used is
|
|||
|
|
<tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>token_type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Token Type value.
|
|||
|
|
The value MUST be <tt>Bearer</tt> or
|
|||
|
|
another <tt>token_type</tt> value that the Client
|
|||
|
|
has negotiated with the Authorization Server.
|
|||
|
|
Clients implementing this profile MUST support the <a class="info"
|
|||
|
|
href="#RFC6750">OAuth
|
|||
|
|
2.0 Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750] specification.
|
|||
|
|
This profile only describes the use of bearer tokens.
|
|||
|
|
This is returned in the same cases as
|
|||
|
|
<tt>access_token</tt> is.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>id_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
ID Token.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>state</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 state value.
|
|||
|
|
REQUIRED if the
|
|||
|
|
<tt>state</tt> parameter is present in the
|
|||
|
|
Authorization Request. Clients MUST verify that the
|
|||
|
|
<tt>state</tt> value is equal to the
|
|||
|
|
value of <tt>state</tt> parameter in the
|
|||
|
|
Authorization Request.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>expires_in</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Expiration time of the Access Token in seconds
|
|||
|
|
since the response was generated.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Per Section 4.2.2 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
no <tt>code</tt> result is returned
|
|||
|
|
when using the Implicit Flow.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of a successful response using the Implicit Flow
|
|||
|
|
(with line wraps for the display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
access_token=SlAV32hkKG
|
|||
|
|
&token_type=bearer
|
|||
|
|
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
|
|||
|
|
&expires_in=3600
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="ImplicitAuthError"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.6"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.6.
|
|||
|
|
Authentication Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, Authorization Error Responses are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the End-User denies the request or the End-User authentication
|
|||
|
|
fails, the Authorization Server MUST return the error
|
|||
|
|
Authorization Response in the
|
|||
|
|
fragment component of the Redirection URI,
|
|||
|
|
as defined in 4.2.2.1 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749] and
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses],
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitCallback"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.7"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.7.
|
|||
|
|
Redirect URI Fragment Handling</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Since response parameters are returned in the Redirection URI fragment value,
|
|||
|
|
the Client needs to have the User Agent parse the fragment encoded values
|
|||
|
|
and pass them to on to the Client's processing logic for consumption.
|
|||
|
|
See <a class="info"
|
|||
|
|
href="#FragmentNotes">Section 15.5.3<span> (</span><span
|
|||
|
|
class="info">Redirect URI Fragment Handling Implementation Notes</span><span>)</span></a> for implementation
|
|||
|
|
notes
|
|||
|
|
on URI fragment handling.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitAuthResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.8"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.8.
|
|||
|
|
Authentication Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow,
|
|||
|
|
the Client MUST validate the response as follows:
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
Verify that the response conforms to Section 5 of
|
|||
|
|
<a class="info"
|
|||
|
|
href="#OAuth.Responses">[OAuth.Responses]<span> (</span><span
|
|||
|
|
class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the validation rules in RFC 6749,
|
|||
|
|
especially those in Sections 4.2.2 and 10.12.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the ID Token validation rules in <a class="info"
|
|||
|
|
href="#ImplicitIDTValidation">Section 3.2.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the Access Token validation rules in <a class="info"
|
|||
|
|
href="#ImplicitTokenValidation">Section 3.2.2.9<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>,
|
|||
|
|
unless the <tt>response_type</tt> value used is
|
|||
|
|
<tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitTokenValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.9"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.9.
|
|||
|
|
Access Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>To validate an Access Token issued from the Authorization Endpoint with an ID Token,
|
|||
|
|
the Client SHOULD do the following:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Hash the octets of the ASCII representation of
|
|||
|
|
the <tt>access_token</tt>
|
|||
|
|
with the hash algorithm specified in <a class="info"
|
|||
|
|
href="#JWA">JWA<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a> [JWA] for
|
|||
|
|
the
|
|||
|
|
<tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>RS256</tt>,
|
|||
|
|
the hash algorithm used is SHA-256.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>Take the left-most half of the hash and base64url encode it.
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The value of <tt>at_hash</tt> in the ID Token MUST
|
|||
|
|
match the value produced in the previous step.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitIDToken"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.10"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.10.
|
|||
|
|
ID Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The contents of the ID Token are as described in <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
When using the Implicit Flow,
|
|||
|
|
these additional requirements for the following ID Token Claims apply:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>nonce</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Use of the <tt>nonce</tt> Claim is REQUIRED
|
|||
|
|
for this flow.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>at_hash</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Access Token hash value.
|
|||
|
|
Its value is the base64url encoding of the left-most half of the
|
|||
|
|
hash of the octets of the ASCII representation of the
|
|||
|
|
<tt>access_token</tt> value,
|
|||
|
|
where the hash algorithm used is the hash algorithm
|
|||
|
|
used in the <tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>RS256</tt>, hash the
|
|||
|
|
<tt>access_token</tt> value
|
|||
|
|
with SHA-256, then take the left-most 128 bits and base64url encode them.
|
|||
|
|
The <tt>at_hash</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
If the ID Token is issued from the Authorization Endpoint with an
|
|||
|
|
<tt>access_token</tt> value,
|
|||
|
|
which is the case for the <tt>response_type</tt> value
|
|||
|
|
<tt>id_token token</tt>,
|
|||
|
|
this is REQUIRED;
|
|||
|
|
it MAY NOT be used when no Access Token is issued,
|
|||
|
|
which is the case for the <tt>response_type</tt> value
|
|||
|
|
<tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitIDTValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.2.2.11"></a>
|
|||
|
|
|
|||
|
|
<h3>3.2.2.11.
|
|||
|
|
ID Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Implicit Flow, the contents of the ID Token MUST be validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#IDTokenValidation">Section 3.1.3.7<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate the signature of the ID Token according to
|
|||
|
|
<a class="info" href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] using the algorithm specified in the
|
|||
|
|
<tt>alg</tt> Header Parameter of the JOSE Header.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The value of the <tt>nonce</tt>
|
|||
|
|
Claim MUST be checked to verify that
|
|||
|
|
it is the same value as the one that was sent in the Authentication Request.
|
|||
|
|
The Client SHOULD check the <tt>nonce</tt> value
|
|||
|
|
for replay attacks.
|
|||
|
|
The precise method for detecting replay attacks is Client specific.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridFlowAuth"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.
|
|||
|
|
Authentication using the Hybrid Flow</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This section describes how to perform authentication using the Hybrid Flow.
|
|||
|
|
When using the Hybrid Flow,
|
|||
|
|
some tokens are returned from the Authorization Endpoint
|
|||
|
|
and others are returned from the Token Endpoint.
|
|||
|
|
The mechanisms for returning tokens in the Hybrid Flow are specified in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridFlowSteps"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.1.
|
|||
|
|
Hybrid Flow Steps</h3>
|
|||
|
|
|
|||
|
|
<p>The Hybrid Flow follows the following steps:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Client prepares an Authentication Request containing the desired
|
|||
|
|
request parameters.
|
|||
|
|
</li>
|
|||
|
|
<li>Client sends the request to the Authorization Server.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server Authenticates the End-User.
|
|||
|
|
</li>
|
|||
|
|
<li>Authorization Server obtains End-User Consent/Authorization.
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Authorization Server sends the End-User back to the Client with
|
|||
|
|
an Authorization Code and, depending on the Response Type,
|
|||
|
|
one or more additional parameters.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>Client requests a response using the Authorization Code at the
|
|||
|
|
Token Endpoint.
|
|||
|
|
</li>
|
|||
|
|
<li>Client receives a response that contains an ID Token
|
|||
|
|
and Access Token in the response body.
|
|||
|
|
</li>
|
|||
|
|
<li>Client validates the ID Token and retrieves the End-User's
|
|||
|
|
Subject Identifier.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAuthorizationEndpoint"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.
|
|||
|
|
Authorization Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the Authorization Endpoint is used
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAuthRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.1.
|
|||
|
|
Authentication Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Authentication Requests are made
|
|||
|
|
as defined in <a class="info" href="#AuthRequest">Section 3.1.2.1<span> (</span><span
|
|||
|
|
class="info">Authentication Request</span><span>)</span></a>,
|
|||
|
|
except that these Authentication Request parameters
|
|||
|
|
are used as follows:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>response_type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OAuth 2.0 Response Type value that determines
|
|||
|
|
the authorization processing flow to be used,
|
|||
|
|
including what parameters are returned from the endpoints used.
|
|||
|
|
When using the Hybrid Flow, this value is
|
|||
|
|
<tt>code id_token</tt>,
|
|||
|
|
<tt>code token</tt>, or
|
|||
|
|
<tt>code id_token token</tt>.
|
|||
|
|
The meanings of these values are defined in
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0
|
|||
|
|
Multiple Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses].
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example request using the Hybrid Flow
|
|||
|
|
that would be sent by the User Agent to the Authorization Server
|
|||
|
|
in response to a corresponding HTTP 302 redirect response by the Client
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code%20id_token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="HybridValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.2.
|
|||
|
|
Authentication Request Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the Authentication Request is validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthRequestValidation">Section 3.1.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAuthenticates"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.3.
|
|||
|
|
Authorization Server Authenticates End-User</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, End-User Authentication is performed
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#Authenticates">Section 3.1.2.3<span> (</span><span
|
|||
|
|
class="info">Authorization Server Authenticates End-User</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridConsent"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.4"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.4.
|
|||
|
|
Authorization Server Obtains End-User Consent/Authorization</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, End-User Consent is obtained
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#Consent">Section 3.1.2.4<span> (</span><span
|
|||
|
|
class="info">Authorization Server Obtains End-User Consent/Authorization</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAuthResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.5"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.5.
|
|||
|
|
Successful Authentication Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Authentication Responses are made
|
|||
|
|
in the same manner as for the Implicit Flow,
|
|||
|
|
as defined in <a class="info" href="#ImplicitAuthResponse">Section 3.2.2.5<span> (</span><span
|
|||
|
|
class="info">Successful Authentication Response</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
These Authorization Endpoint results are used in the following manner:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>access_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OAuth 2.0 Access Token.
|
|||
|
|
This is returned
|
|||
|
|
when the <tt>response_type</tt> value used is
|
|||
|
|
<tt>code token</tt>,
|
|||
|
|
or <tt>code id_token token</tt>.
|
|||
|
|
(A <tt>token_type</tt> value is also returned in the same cases.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>id_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
ID Token.
|
|||
|
|
This is returned
|
|||
|
|
when the <tt>response_type</tt> value used is
|
|||
|
|
<tt>code id_token</tt> or
|
|||
|
|
<tt>code id_token token</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>code</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Authorization Code.
|
|||
|
|
This is always returned when using the Hybrid Flow.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of a successful response using the Hybrid Flow
|
|||
|
|
(with line wraps for the display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
code=SplxlOBeZQQYbYS6WxSbIA
|
|||
|
|
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="HybridAuthError"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.6"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.6.
|
|||
|
|
Authentication Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Authorization Error Responses are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the End-User denies the request or the End-User authentication
|
|||
|
|
fails, the Authorization Server MUST return the error
|
|||
|
|
Authorization Response in the
|
|||
|
|
fragment component of the Redirection URI,
|
|||
|
|
as defined in 4.2.2.1 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749] and
|
|||
|
|
<a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
|
|||
|
|
Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Responses],
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridCallback"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.7"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.7.
|
|||
|
|
Redirect URI Fragment Handling</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the same requirements for
|
|||
|
|
Redirection URI fragment parameter handling apply as do for
|
|||
|
|
the Implicit Flow, as defined in <a class="info"
|
|||
|
|
href="#ImplicitCallback">Section 3.2.2.7<span> (</span><span
|
|||
|
|
class="info">Redirect URI Fragment Handling</span><span>)</span></a>.
|
|||
|
|
Also see <a class="info" href="#FragmentNotes">Section 15.5.3<span> (</span><span
|
|||
|
|
class="info">Redirect URI Fragment Handling Implementation Notes</span><span>)</span></a> for implementation
|
|||
|
|
notes
|
|||
|
|
on URI fragment handling.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAuthResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.8"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.8.
|
|||
|
|
Authentication Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow,
|
|||
|
|
the Client MUST validate the response as follows:
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
Verify that the response conforms to Section 5 of
|
|||
|
|
<a class="info"
|
|||
|
|
href="#OAuth.Responses">[OAuth.Responses]<span> (</span><span
|
|||
|
|
class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the validation rules in RFC 6749,
|
|||
|
|
especially those in Sections 4.2.2 and 10.12.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the ID Token validation rules in <a class="info"
|
|||
|
|
href="#HybridIDTValidation">Section 3.3.2.12<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>
|
|||
|
|
when the <tt>response_type</tt> value used is
|
|||
|
|
<tt>code id_token</tt> or
|
|||
|
|
<tt>code id_token token</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the Access Token validation rules in <a class="info"
|
|||
|
|
href="#HybridTokenValidation">Section 3.3.2.9<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>
|
|||
|
|
when the <tt>response_type</tt> value used is
|
|||
|
|
<tt>code token</tt> or
|
|||
|
|
<tt>code id_token token</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Follow the Authorization Code validation rules in <a class="info"
|
|||
|
|
href="#CodeValidation">Section 3.3.2.10<span> (</span><span
|
|||
|
|
class="info">Authorization Code Validation</span><span>)</span></a>
|
|||
|
|
when the <tt>response_type</tt> value used is
|
|||
|
|
<tt>code id_token</tt> or
|
|||
|
|
|
|||
|
|
<tt>code id_token token</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.9"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.9.
|
|||
|
|
Access Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Access Tokens
|
|||
|
|
returned from the Authorization Endpoint are validated
|
|||
|
|
in the same manner as for the Implicit Flow,
|
|||
|
|
as defined in <a class="info" href="#ImplicitTokenValidation">Section 3.2.2.9<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="CodeValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.10"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.10.
|
|||
|
|
Authorization Code Validation</h3>
|
|||
|
|
|
|||
|
|
<p>To validate an Authorization Code issued from the Authorization Endpoint with an ID Token,
|
|||
|
|
the Client SHOULD do the following:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Hash the octets of the ASCII representation of
|
|||
|
|
the <tt>code</tt>
|
|||
|
|
with the hash algorithm specified in <a class="info"
|
|||
|
|
href="#JWA">JWA<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a> [JWA] for
|
|||
|
|
the
|
|||
|
|
<tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>RS256</tt>,
|
|||
|
|
the hash algorithm used is SHA-256.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>Take the left-most half of the hash and base64url encode it.
|
|||
|
|
</li>
|
|||
|
|
<li>The value of <tt>c_hash</tt> in the ID Token MUST
|
|||
|
|
match the value produced in the previous step if <tt>c_hash</tt>
|
|||
|
|
is present in the ID Token.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridIDToken"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.11"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.11.
|
|||
|
|
ID Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The contents of the ID Token are as described in <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
When using the Hybrid Flow,
|
|||
|
|
these additional requirements for the following ID Token Claims apply
|
|||
|
|
to an ID Token returned from the Authorization Endpoint:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>nonce</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Use of the <tt>nonce</tt> Claim is REQUIRED
|
|||
|
|
for this flow.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>at_hash</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Access Token hash value.
|
|||
|
|
Its value is the base64url encoding of the left-most half of the
|
|||
|
|
hash of the octets of the ASCII representation of the
|
|||
|
|
<tt>access_token</tt> value,
|
|||
|
|
where the hash algorithm used is the hash algorithm
|
|||
|
|
used in the <tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>RS256</tt>, hash the
|
|||
|
|
<tt>access_token</tt> value
|
|||
|
|
with SHA-256, then take the left-most 128 bits and base64url encode them.
|
|||
|
|
The <tt>at_hash</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
If the ID Token is issued from the Authorization Endpoint with an
|
|||
|
|
<tt>access_token</tt> value,
|
|||
|
|
which is the case for the <tt>response_type</tt> value
|
|||
|
|
<tt>code id_token token</tt>,
|
|||
|
|
this is REQUIRED; otherwise, its inclusion is OPTIONAL.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>c_hash</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Code hash value.
|
|||
|
|
Its value is the base64url encoding of the left-most half of the
|
|||
|
|
hash of the octets of the ASCII representation of the
|
|||
|
|
<tt>code</tt> value,
|
|||
|
|
where the hash algorithm used is the hash algorithm
|
|||
|
|
used in the <tt>alg</tt> Header Parameter
|
|||
|
|
of the ID Token's JOSE Header.
|
|||
|
|
For instance, if the <tt>alg</tt> is
|
|||
|
|
<tt>HS512</tt>, hash the
|
|||
|
|
<tt>code</tt> value
|
|||
|
|
with SHA-512, then take the left-most 256 bits and base64url encode them.
|
|||
|
|
The <tt>c_hash</tt> value is a case sensitive string.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
If the ID Token is issued from the Authorization Endpoint with a
|
|||
|
|
<tt>code</tt>,
|
|||
|
|
which is the case for the <tt>response_type</tt> values
|
|||
|
|
<tt>code id_token</tt> and
|
|||
|
|
<tt>code id_token token</tt>,
|
|||
|
|
this is REQUIRED; otherwise, its inclusion is OPTIONAL.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridIDTValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.2.12"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.2.12.
|
|||
|
|
ID Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the contents of an ID Token
|
|||
|
|
returned from the Authorization Endpoint MUST be validated
|
|||
|
|
in the same manner as for the Implicit Flow,
|
|||
|
|
as defined in <a class="info" href="#ImplicitIDTValidation">Section 3.2.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenEndpoint"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.
|
|||
|
|
Token Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the Token Endpoint is used
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenEndpoint">Section 3.1.3<span> (</span><span
|
|||
|
|
class="info">Token Endpoint</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.1.
|
|||
|
|
Token Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Token Requests are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenRequest">Section 3.1.3.1<span> (</span><span
|
|||
|
|
class="info">Token Request</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenRequestValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.2.
|
|||
|
|
Token Request Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Token Requests are validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenRequestValidation">Section 3.1.3.2<span> (</span><span
|
|||
|
|
class="info">Token Request Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.3.
|
|||
|
|
Successful Token Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Token Responses are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenResponse">Section 3.1.3.3<span> (</span><span
|
|||
|
|
class="info">Successful Token Response</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenErrorResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.4"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.4.
|
|||
|
|
Token Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Token Error Responses are made
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenErrorResponse">Section 3.1.3.4<span> (</span><span
|
|||
|
|
class="info">Token Error Response</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.5"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.5.
|
|||
|
|
Token Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, Token Responses are validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#TokenResponseValidation">Section 3.1.3.5<span> (</span><span
|
|||
|
|
class="info">Token Response Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridIDToken2"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.6"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.6.
|
|||
|
|
ID Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the contents of an ID Token
|
|||
|
|
returned from the Token Endpoint are
|
|||
|
|
the same as for an ID Token returned from the Authorization Endpoint,
|
|||
|
|
as defined in <a class="info" href="#HybridIDToken">Section 3.3.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
with the exception of the differences specified in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If an ID Token is returned from both the Authorization Endpoint
|
|||
|
|
and from the Token Endpoint,
|
|||
|
|
which is the case for the <tt>response_type</tt> values
|
|||
|
|
<tt>code id_token</tt> and
|
|||
|
|
<tt>code id_token token</tt>,
|
|||
|
|
the <tt>iss</tt> and <tt>sub</tt>
|
|||
|
|
Claim Values MUST be identical in both ID Tokens.
|
|||
|
|
All Claims about the Authentication event present in either
|
|||
|
|
SHOULD be present in both.
|
|||
|
|
If either ID Token contains Claims about the End-User,
|
|||
|
|
any that are present in both SHOULD have the same values in both.
|
|||
|
|
Note that the OP MAY choose to return fewer Claims about the End-User
|
|||
|
|
from the Authorization Endpoint, for instance, for privacy reasons.
|
|||
|
|
The <tt>at_hash</tt>
|
|||
|
|
and <tt>c_hash</tt> Claims
|
|||
|
|
MAY be omitted from the ID Token returned from the Token Endpoint
|
|||
|
|
even when these Claims are
|
|||
|
|
present in the ID Token returned from the Authorization Endpoint,
|
|||
|
|
because the ID Token and Access Token values returned from
|
|||
|
|
the Token Endpoint are already cryptographically bound together
|
|||
|
|
by the TLS encryption performed by the Token Endpoint.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridIDTValidation2"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.7"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.7.
|
|||
|
|
ID Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the contents of an ID Token
|
|||
|
|
returned from the Token Endpoint MUST be validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#IDTokenValidation">Section 3.1.3.7<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridAccessToken2"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.8"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.8.
|
|||
|
|
Access Token</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If an Access Token is returned from both the Authorization Endpoint
|
|||
|
|
and from the Token Endpoint,
|
|||
|
|
which is the case for the <tt>response_type</tt> values
|
|||
|
|
<tt>code token</tt> and
|
|||
|
|
<tt>code id_token token</tt>,
|
|||
|
|
their values MAY be the same
|
|||
|
|
or they MAY be different.
|
|||
|
|
Note that different Access Tokens might be returned
|
|||
|
|
be due to the different security characteristics
|
|||
|
|
of the two endpoints and the lifetimes and
|
|||
|
|
the access to resources granted by them might also be different.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="HybridTokenValidation2"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.3.3.3.9"></a>
|
|||
|
|
|
|||
|
|
<h3>3.3.3.9.
|
|||
|
|
Access Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Hybrid Flow, the Access Token
|
|||
|
|
returned from the Token Endpoint
|
|||
|
|
is validated
|
|||
|
|
in the same manner as for the Authorization Code Flow,
|
|||
|
|
as defined in <a class="info" href="#CodeFlowTokenValidation">Section 3.1.3.8<span> (</span><span
|
|||
|
|
class="info">Access Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ThirdPartyInitiatedLogin"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.4"></a>
|
|||
|
|
|
|||
|
|
<h3>4.
|
|||
|
|
Initiating Login from a Third Party</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In some cases, the login flow is initiated by an OpenID Provider
|
|||
|
|
or another party, rather than the Relying Party.
|
|||
|
|
In this case, the initiator redirects to the RP at its login initiation endpoint,
|
|||
|
|
which requests that the RP send an Authentication Request to a specified OP.
|
|||
|
|
This login initiation endpoint can be a deep link at the RP,
|
|||
|
|
rather than a default landing page.
|
|||
|
|
RPs supporting
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID Connect
|
|||
|
|
Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration]
|
|||
|
|
register this endpoint value using the
|
|||
|
|
<tt>initiate_login_uri</tt> Registration parameter.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The party initiating the login request does so by redirecting
|
|||
|
|
to the login initiation endpoint at the RP, passing the following parameters:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>iss</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Issuer Identifier for the OP that the RP is to send
|
|||
|
|
the Authentication Request to.
|
|||
|
|
Its value MUST be a URL using the <tt>https</tt> scheme.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>login_hint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Hint to the Authorization Server
|
|||
|
|
about the login identifier the End-User might use to log in.
|
|||
|
|
If the client receives a value for this string-valued parameter,
|
|||
|
|
it MUST include it in the Authentication Request
|
|||
|
|
as the <tt>login_hint</tt> parameter value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>target_link_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
URL that the RP is requested to redirect to after authentication.
|
|||
|
|
RPs MUST verify the value of the
|
|||
|
|
<tt>target_link_uri</tt> to prevent being used as
|
|||
|
|
an open redirector to external sites.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The parameters can either be passed as query parameters using
|
|||
|
|
the HTTP <tt>GET</tt> method
|
|||
|
|
or be passed as HTML form values that are auto-submitted in the User Agent,
|
|||
|
|
and thus are transmitted via the HTTP <tt>POST</tt> method.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Other parameters MAY be sent, if defined by extensions.
|
|||
|
|
Any parameters used that are not understood MUST be ignored by the Client.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Clients SHOULD employ frame busting and other techniques to prevent
|
|||
|
|
End-Users from being logged in by third party sites without their knowledge
|
|||
|
|
through attacks such as Clickjacking.
|
|||
|
|
Refer to Section 4.4.1.9 of <a class="info" href="#RFC6819">[RFC6819]<span> (</span><span
|
|||
|
|
class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a>
|
|||
|
|
for more details.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Claims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5"></a>
|
|||
|
|
|
|||
|
|
<h3>5.
|
|||
|
|
Claims</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This section specifies how the Client can obtain Claims about the End-User
|
|||
|
|
and the Authentication event.
|
|||
|
|
It also defines a standard set of basic profile Claims.
|
|||
|
|
Pre-defined sets of Claims can be requested using specific scope values
|
|||
|
|
or individual Claims can be requested using the
|
|||
|
|
<tt>claims</tt> request parameter.
|
|||
|
|
The Claims can come directly from the OpenID Provider
|
|||
|
|
or from distributed sources as well.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="StandardClaims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.1.
|
|||
|
|
Standard Claims</h3>
|
|||
|
|
|
|||
|
|
<p>This specification defines a set of standard Claims.
|
|||
|
|
They can be requested to be returned either in the
|
|||
|
|
UserInfo Response, per <a class="info" href="#UserInfoResponse">Section 5.3.2<span> (</span><span
|
|||
|
|
class="info">Successful UserInfo Response</span><span>)</span></a>,
|
|||
|
|
or in the ID Token, per <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p><br>
|
|||
|
|
<hr class="insert">
|
|||
|
|
<a name="ClaimTable"></a>
|
|||
|
|
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
|
|||
|
|
<colgroup>
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
<col align="left">
|
|||
|
|
</colgroup>
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<th align="left">Member</th>
|
|||
|
|
<th align="left">Type</th>
|
|||
|
|
<th align="left">Description</th>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">sub</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">Subject - Identifier for the End-User at the Issuer.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">name</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
End-User's full name in displayable form including all name parts,
|
|||
|
|
possibly including titles and suffixes,
|
|||
|
|
ordered according to the End-User's locale and preferences.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">given_name</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
Given name(s) or first name(s) of the End-User.
|
|||
|
|
Note that in some cultures, people can have multiple given names;
|
|||
|
|
all can be present, with the names being separated by space characters.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">family_name</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
Surname(s) or last name(s) of the End-User.
|
|||
|
|
Note that in some cultures, people can have multiple family names
|
|||
|
|
or no family name;
|
|||
|
|
all can be present, with the names being separated by space characters.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">middle_name</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
Middle name(s) of the End-User.
|
|||
|
|
Note that in some cultures, people can have multiple middle names;
|
|||
|
|
all can be present, with the names being separated by space characters.
|
|||
|
|
Also note that in some cultures, middle names are not used.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">nickname</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">Casual name of the End-User that may or may not be the same as the
|
|||
|
|
<tt>given_name</tt>. For instance, a <tt>nickname</tt> value of <tt>Mike</tt>
|
|||
|
|
might be returned alongside a <tt>given_name</tt>
|
|||
|
|
value of <tt>Michael</tt>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">preferred_username</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">Shorthand name by which the End-User wishes to be referred to at the RP, such as
|
|||
|
|
<tt>janedoe</tt> or <tt>j.doe</tt>.
|
|||
|
|
This value MAY be any valid JSON string including
|
|||
|
|
special characters such as <tt>@</tt>,
|
|||
|
|
<tt>/</tt>, or whitespace.
|
|||
|
|
The RP MUST NOT rely upon this value being unique,
|
|||
|
|
as discussed in <a class="info" href="#ClaimStability">Section 5.7<span> (</span><span
|
|||
|
|
class="info">Claim Stability and Uniqueness</span><span>)</span></a>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">profile</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
URL of the End-User's profile page.
|
|||
|
|
The contents of this Web page SHOULD be about the End-User.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">picture</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
URL of the End-User's profile picture.
|
|||
|
|
This URL MUST refer to an image file
|
|||
|
|
(for example, a PNG, JPEG, or GIF image file),
|
|||
|
|
rather than to a Web page containing an image.
|
|||
|
|
Note that this URL SHOULD specifically reference
|
|||
|
|
a profile photo of the End-User
|
|||
|
|
suitable for displaying when describing the End-User,
|
|||
|
|
rather than an arbitrary photo taken by the End-User.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">website</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
URL of the End-User's Web page or blog.
|
|||
|
|
This Web page SHOULD contain information published by the End-User
|
|||
|
|
or an organization that the End-User is affiliated with.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">email</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
End-User's preferred e-mail address.
|
|||
|
|
Its value MUST conform to the <a class="info"
|
|||
|
|
href="#RFC5322">RFC
|
|||
|
|
5322<span> (</span><span class="info">Resnick, P., Ed., “Internet Message Format,” October 2008.</span><span>)</span></a>
|
|||
|
|
[RFC5322]
|
|||
|
|
addr-spec syntax.
|
|||
|
|
The RP MUST NOT rely upon this value being unique,
|
|||
|
|
as discussed in <a class="info" href="#ClaimStability">Section 5.7<span> (</span><span
|
|||
|
|
class="info">Claim Stability and Uniqueness</span><span>)</span></a>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">email_verified</td>
|
|||
|
|
<td align="left">boolean</td>
|
|||
|
|
<td align="left">
|
|||
|
|
True if the End-User's e-mail address has been verified; otherwise false.
|
|||
|
|
When this Claim Value is <tt>true</tt>,
|
|||
|
|
this means that the OP took affirmative steps
|
|||
|
|
to ensure that this e-mail address was controlled by the End-User
|
|||
|
|
at the time the verification was performed.
|
|||
|
|
The means by which an e-mail address is verified is context-specific,
|
|||
|
|
and dependent upon the trust framework or contractual agreements
|
|||
|
|
within which the parties are operating.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">gender</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left"> End-User's gender. Values defined by this
|
|||
|
|
specification are <tt>female</tt> and
|
|||
|
|
<tt>male</tt>. Other values MAY be used
|
|||
|
|
when neither of the defined values are applicable.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">birthdate</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">End-User's birthday, represented as an
|
|||
|
|
<a class="info" href="#ISO8601-2004">ISO 8601:2004<span> (</span><span
|
|||
|
|
class="info">International Organization for Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange - Representation of dates and times,” 2004.</span><span>)</span></a>
|
|||
|
|
[ISO8601‑2004] <tt>YYYY-MM-DD</tt>
|
|||
|
|
format. The year MAY be <tt>0000</tt>, indicating that it is omitted.
|
|||
|
|
To represent only the year, <tt>YYYY</tt> format is allowed. Note that
|
|||
|
|
depending on the underlying platform's date related function, providing just year can
|
|||
|
|
result in varying month and day, so the implementers need to take this factor into account
|
|||
|
|
to correctly process the dates.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">zoneinfo</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">String from zoneinfo <a class="info"
|
|||
|
|
href="#zoneinfo">[zoneinfo]<span> (</span><span
|
|||
|
|
class="info">Public Domain, “The tz database,” June 2011.</span><span>)</span></a> time zone
|
|||
|
|
database representing the End-User's time zone.
|
|||
|
|
For example, <tt>Europe/Paris</tt> or
|
|||
|
|
<tt>America/Los_Angeles</tt>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">locale</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">End-User's locale, represented as a
|
|||
|
|
<a class="info"
|
|||
|
|
href="#RFC5646">BCP47<span> (</span><span
|
|||
|
|
class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a>
|
|||
|
|
[RFC5646] language tag.
|
|||
|
|
This is typically an <a class="info" href="#ISO639-1">ISO
|
|||
|
|
639-1 Alpha-2<span> (</span><span class="info">International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,” 2002.</span><span>)</span></a>
|
|||
|
|
[ISO639‑1]
|
|||
|
|
language code in
|
|||
|
|
lowercase and an <a class="info" href="#ISO3166-1">ISO
|
|||
|
|
3166-1 Alpha-2<span> (</span><span class="info">International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997.</span><span>)</span></a>
|
|||
|
|
[ISO3166‑1]
|
|||
|
|
country code in uppercase, separated by a dash. For example,
|
|||
|
|
<tt>en-US</tt> or <tt>fr-CA</tt>.
|
|||
|
|
As a compatibility note, some implementations have used an underscore
|
|||
|
|
as the separator rather than a dash, for example,
|
|||
|
|
<tt>en_US</tt>; Relying Parties MAY choose to
|
|||
|
|
accept this locale syntax as well.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">phone_number</td>
|
|||
|
|
<td align="left">string</td>
|
|||
|
|
<td align="left">
|
|||
|
|
End-User's preferred telephone number. <a class="info"
|
|||
|
|
href="#E.164">E.164<span> (</span><span
|
|||
|
|
class="info">International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.</span><span>)</span></a>
|
|||
|
|
[E.164]
|
|||
|
|
is RECOMMENDED as the format of this Claim,
|
|||
|
|
for example, <tt>+1 (425) 555-1212</tt>
|
|||
|
|
or <tt>+56 (2) 687 2400</tt>.
|
|||
|
|
If the phone number contains an extension, it is RECOMMENDED that
|
|||
|
|
the extension be represented using the
|
|||
|
|
<a class="info" href="#RFC3966">RFC
|
|||
|
|
3966<span> (</span><span class="info">Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.</span><span>)</span></a>
|
|||
|
|
[RFC3966] extension syntax,
|
|||
|
|
for example, <tt>+1 (604) 555-1234;ext=5678</tt>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">phone_number_verified</td>
|
|||
|
|
<td align="left">boolean</td>
|
|||
|
|
<td align="left">
|
|||
|
|
True if the End-User's phone number has been verified; otherwise false.
|
|||
|
|
When this Claim Value is <tt>true</tt>,
|
|||
|
|
this means that the OP took affirmative steps
|
|||
|
|
to ensure that this phone number was controlled by the End-User
|
|||
|
|
at the time the verification was performed.
|
|||
|
|
The means by which a phone number is verified is context-specific,
|
|||
|
|
and dependent upon the trust framework or contractual agreements
|
|||
|
|
within which the parties are operating.
|
|||
|
|
When true, the <tt>phone_number</tt>
|
|||
|
|
Claim MUST be in E.164 format
|
|||
|
|
and any extensions MUST be represented in RFC 3966 format.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">address</td>
|
|||
|
|
<td align="left">JSON object</td>
|
|||
|
|
<td align="left">
|
|||
|
|
End-User's preferred postal address.
|
|||
|
|
The value of the <tt>address</tt> member is
|
|||
|
|
a JSON <a class="info"
|
|||
|
|
href="#RFC4627">[RFC4627]<span> (</span><span
|
|||
|
|
class="info">Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a>
|
|||
|
|
structure containing some or all of
|
|||
|
|
the members defined in <a class="info"
|
|||
|
|
href="#AddressClaim">Section 5.1.1<span> (</span><span
|
|||
|
|
class="info">Address Claim</span><span>)</span></a>.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td align="left">updated_at</td>
|
|||
|
|
<td align="left">number</td>
|
|||
|
|
<td align="left">
|
|||
|
|
Time the End-User's information was last updated.
|
|||
|
|
Its value is a JSON number representing the number of seconds from
|
|||
|
|
1970-01-01T0:0:0Z as measured in UTC until the date/time.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<br clear="all">
|
|||
|
|
<table border="0" cellpadding="0" cellspacing="2" align="center">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Table 1: Registered Member Definitions </b></font><br>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<hr class="insert">
|
|||
|
|
|
|||
|
|
<a name="AddressClaim"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.1.1.
|
|||
|
|
Address Claim</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Address Claim represents a physical mailing address.
|
|||
|
|
Implementations MAY return only a subset of the
|
|||
|
|
fields of an <tt>address</tt>, depending upon
|
|||
|
|
the information available and the End-User's privacy
|
|||
|
|
preferences. For
|
|||
|
|
example, the <tt>country</tt> and <tt>region</tt> might be returned without returning
|
|||
|
|
more fine-grained address information.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Implementations MAY return just the full address
|
|||
|
|
as a single string in the formatted sub-field,
|
|||
|
|
or they MAY return just the individual component
|
|||
|
|
fields using the other sub-fields,
|
|||
|
|
or they MAY return both.
|
|||
|
|
If both variants are returned,
|
|||
|
|
they SHOULD be describing the same address,
|
|||
|
|
with the formatted address indicating how the
|
|||
|
|
component fields are combined.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>formatted</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Full mailing address,
|
|||
|
|
formatted for display or use on a mailing label.
|
|||
|
|
This field MAY contain multiple lines, separated by newlines.
|
|||
|
|
Newlines can be represented either as
|
|||
|
|
a carriage return/line feed pair ("\r\n") or as
|
|||
|
|
a single line feed character ("\n").
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>street_address</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Full street address component,
|
|||
|
|
which MAY include house number, street name,
|
|||
|
|
Post Office Box, and multi-line extended street
|
|||
|
|
address information.
|
|||
|
|
This field MAY contain multiple lines, separated by newlines.
|
|||
|
|
Newlines can be represented either as
|
|||
|
|
a carriage return/line feed pair ("\r\n") or as
|
|||
|
|
a single line feed character ("\n").
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>locality</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
City or locality component.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>region</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
State, province,
|
|||
|
|
prefecture, or region component.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>postal_code</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Zip code or
|
|||
|
|
postal code component.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>country</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Country name component.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AdditionalClaims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.1.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.1.2.
|
|||
|
|
Additional Claims</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
While this specification defines only a small set of Claims as
|
|||
|
|
standard Claims, other Claims MAY be used in conjunction
|
|||
|
|
with the standard Claims.
|
|||
|
|
When using such Claims, it is RECOMMENDED that
|
|||
|
|
collision-resistant names be used for the Claim Names,
|
|||
|
|
as described in the
|
|||
|
|
<a class="info" href="#JWT">JSON Web Token
|
|||
|
|
(JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT] specification.
|
|||
|
|
Alternatively, Private Claim Names can be safely used
|
|||
|
|
when naming conflicts are unlikely to arise,
|
|||
|
|
as described in the JWT specification.
|
|||
|
|
Or, if specific additional Claims will have broad and general applicability,
|
|||
|
|
they can be registered with Registered Claim Names,
|
|||
|
|
per the JWT specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ClaimsLanguagesAndScripts"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.2.
|
|||
|
|
Claims Languages and Scripts</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Human-readable Claim Values and Claim Values that reference human-readable values
|
|||
|
|
MAY be represented in multiple languages and scripts.
|
|||
|
|
To specify the languages and scripts, <a class="info"
|
|||
|
|
href="#RFC5646">BCP47<span> (</span><span
|
|||
|
|
class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a>
|
|||
|
|
[RFC5646] language tags are added to member names,
|
|||
|
|
delimited by a <tt>#</tt> character. For example,
|
|||
|
|
<tt>family_name#ja-Kana-JP</tt> expresses the
|
|||
|
|
Family Name in Katakana in Japanese, which is commonly used to index
|
|||
|
|
and represent the phonetics of the Kanji representation of the same
|
|||
|
|
represented as <tt>family_name#ja-Hani-JP</tt>.
|
|||
|
|
As another example, both <tt>website</tt> and
|
|||
|
|
<tt>website#de</tt> Claim Values might be returned,
|
|||
|
|
referencing a Web site in an unspecified language and a Web site
|
|||
|
|
in German.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Since Claim Names are case sensitive, it is strongly RECOMMENDED
|
|||
|
|
that language tag values used in Claim Names be spelled using the
|
|||
|
|
character case with which they are registered in the
|
|||
|
|
<a class="info" href="#IANA.Language">IANA Language Subtag
|
|||
|
|
Registry<span> (</span><span class="info">Internet Assigned Numbers Authority (IANA), “Language Subtag Registry,” 2005.</span><span>)</span></a>
|
|||
|
|
[IANA.Language].
|
|||
|
|
In particular, normally language names are spelled with lowercase characters,
|
|||
|
|
region names are spelled with uppercase characters, and
|
|||
|
|
scripts are spelled with mixed case characters.
|
|||
|
|
However, since BCP47 language tag values are case insensitive,
|
|||
|
|
implementations SHOULD interpret the language tag values supplied
|
|||
|
|
in a case insensitive manner.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Per the recommendations in BCP47, language tag values for Claims
|
|||
|
|
SHOULD only be as specific as necessary.
|
|||
|
|
For instance, using <tt>fr</tt> might be sufficient
|
|||
|
|
in many contexts, rather than <tt>fr-CA</tt> or
|
|||
|
|
<tt>fr-FR</tt>.
|
|||
|
|
Where possible, OPs SHOULD try to match requested Claim locales with
|
|||
|
|
Claims it has. For instance, if the Client asks for a Claim with
|
|||
|
|
a <tt>de</tt> (German) language tag and the OP
|
|||
|
|
has a value tagged with <tt>de-CH</tt> (Swiss German)
|
|||
|
|
and no generic German value, it would be appropriate for the OP
|
|||
|
|
to return the Swiss German value to the Client.
|
|||
|
|
(This intentionally moves as much of the complexity of language tag
|
|||
|
|
matching to the OP as possible, to simplify Clients.)
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following Authorization Request parameter
|
|||
|
|
to enable specify the preferred languages and scripts to be used
|
|||
|
|
for the returned Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>claims_locales</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
End-User's preferred languages and scripts for Claims being returned,
|
|||
|
|
represented as a space-separated list of
|
|||
|
|
<a class="info"
|
|||
|
|
href="#RFC5646">BCP47<span> (</span><span
|
|||
|
|
class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a>
|
|||
|
|
[RFC5646] language tag values,
|
|||
|
|
ordered by preference.
|
|||
|
|
An error SHOULD NOT result if some or all of the requested locales
|
|||
|
|
are not supported by the OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When the OP determines, either through the
|
|||
|
|
<tt>claims_locales</tt> parameter,
|
|||
|
|
or by other means, that the End-User and Client are
|
|||
|
|
requesting Claims in only one set of languages and scripts,
|
|||
|
|
it is RECOMMENDED that OPs return Claims without language tags
|
|||
|
|
when they employ this language and script.
|
|||
|
|
It is also RECOMMENDED that Clients be written in a manner
|
|||
|
|
that they can handle and utilize Claims using language tags.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="UserInfo"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.3"></a>
|
|||
|
|
|
|||
|
|
<h3>5.3.
|
|||
|
|
UserInfo Endpoint</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that
|
|||
|
|
returns Claims about the authenticated End-User.
|
|||
|
|
To obtain the requested Claims about the End-User, the Client
|
|||
|
|
makes a request to the UserInfo Endpoint
|
|||
|
|
using an Access Token obtained through OpenID Connect Authentication.
|
|||
|
|
These Claims are normally represented by a JSON object that contains
|
|||
|
|
a collection of name and value pairs for the Claims.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Communication with the UserInfo Endpoint MUST utilize TLS.
|
|||
|
|
See <a class="info"
|
|||
|
|
href="#TLSRequirements">Section 16.17<span> (</span><span
|
|||
|
|
class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The UserInfo Endpoint MUST support the use of the
|
|||
|
|
HTTP <tt>GET</tt> and
|
|||
|
|
HTTP <tt>POST</tt> 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].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The UserInfo Endpoint MUST accept Access Tokens as
|
|||
|
|
<a class="info" href="#RFC6750">OAuth 2.0 Bearer Token
|
|||
|
|
Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750].
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The UserInfo Endpoint SHOULD support the use of
|
|||
|
|
<a class="info" href="#CORS">Cross Origin Resource Sharing
|
|||
|
|
(CORS)<span> (</span><span
|
|||
|
|
class="info">Opera Software ASA, “Cross-Origin Resource Sharing,” July 2010.</span><span>)</span></a>
|
|||
|
|
[CORS] and
|
|||
|
|
or other methods as appropriate to enable Java Script Clients to access the endpoint.
|
|||
|
|
</p>
|
|||
|
|
<a name="UserInfoRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.3.1.
|
|||
|
|
UserInfo Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Client sends the UserInfo Request using either
|
|||
|
|
HTTP <tt>GET</tt> or HTTP <tt>POST</tt>.
|
|||
|
|
The Access Token obtained
|
|||
|
|
from an OpenID Connect Authentication Request MUST be sent as a Bearer Token,
|
|||
|
|
per Section 2 of <a class="info" href="#RFC6750">OAuth 2.0
|
|||
|
|
Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
It is RECOMMENDED that the request use the
|
|||
|
|
HTTP <tt>GET</tt> method and
|
|||
|
|
the Access Token be sent using the
|
|||
|
|
<tt>Authorization</tt> header field.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of a UserInfo Request:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /userinfo HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
Authorization: Bearer SlAV32hkKG
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="UserInfoResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.3.2.
|
|||
|
|
Successful UserInfo Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The UserInfo Claims MUST be returned as the members of a JSON object
|
|||
|
|
unless a signed or encrypted response was requested during Client Registration.
|
|||
|
|
The Claims defined in <a class="info" href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> can be returned,
|
|||
|
|
as can additional Claims not specified there.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
For privacy reasons, OpenID Providers MAY elect to not return
|
|||
|
|
values for some requested Claims.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If a Claim is not returned, that Claim Name SHOULD be
|
|||
|
|
omitted from the JSON object representing the Claims; it
|
|||
|
|
SHOULD NOT be present with a null or empty string value.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>sub</tt> (subject) Claim
|
|||
|
|
MUST always be returned in the UserInfo Response.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
NOTE: Due to the possibility of token substitution attacks
|
|||
|
|
(see <a class="info" href="#TokenSubstitution">Section 16.11<span> (</span><span
|
|||
|
|
class="info">Token Substitution</span><span>)</span></a>),
|
|||
|
|
the UserInfo Response is not guaranteed to be about the
|
|||
|
|
End-User identified by the <tt>sub</tt> (subject)
|
|||
|
|
element of the ID Token.
|
|||
|
|
The <tt>sub</tt> Claim in the UserInfo Response
|
|||
|
|
MUST be verified to exactly match the
|
|||
|
|
<tt>sub</tt> Claim in the ID Token;
|
|||
|
|
if they do not match, the UserInfo Response values MUST NOT be used.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<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="#JSONSerialization">Section 13.3<span> (</span><span
|
|||
|
|
class="info">JSON Serialization</span><span>)</span></a> in the HTTP response
|
|||
|
|
body unless a
|
|||
|
|
different format was specified during Registration
|
|||
|
|
<a class="info" href="#OpenID.Registration">[OpenID.Registration]<span> (</span><span
|
|||
|
|
class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>.
|
|||
|
|
The UserInfo Endpoint MUST return a content-type header to indicate
|
|||
|
|
which format is being returned.
|
|||
|
|
The content-type of the HTTP response MUST be <tt>application/json</tt> if the response body is a text
|
|||
|
|
JSON object;
|
|||
|
|
the response body SHOULD be encoded using UTF-8.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the UserInfo Response is
|
|||
|
|
signed and/or encrypted, then the Claims are returned in a JWT and the
|
|||
|
|
content-type MUST be <tt>application/jwt</tt>.
|
|||
|
|
The response MAY be encrypted without also being signed.
|
|||
|
|
If both signing and encryption are requested,
|
|||
|
|
the response MUST be signed then encrypted,
|
|||
|
|
with the result being a Nested JWT, as defined in <a class="info"
|
|||
|
|
href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If signed, the UserInfo Response
|
|||
|
|
SHOULD contain the Claims
|
|||
|
|
<tt>iss</tt> (issuer)
|
|||
|
|
and <tt>aud</tt> (audience) as members.
|
|||
|
|
The <tt>iss</tt> value SHOULD be the OP's Issuer Identifier URL.
|
|||
|
|
The <tt>aud</tt> value SHOULD be or include the RP's Client ID value.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of a UserInfo Response:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 200 OK
|
|||
|
|
Content-Type: application/json
|
|||
|
|
|
|||
|
|
{
|
|||
|
|
"sub": "248289761001",
|
|||
|
|
"name": "Jane Doe",
|
|||
|
|
"given_name": "Jane",
|
|||
|
|
"family_name": "Doe",
|
|||
|
|
"preferred_username": "j.doe",
|
|||
|
|
"email": "janedoe@example.com",
|
|||
|
|
"picture": "http://example.com/janedoe/me.jpg"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="UserInfoError"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>5.3.3.
|
|||
|
|
UserInfo Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When an error condition occurs, the UserInfo Endpoint returns
|
|||
|
|
an Error Response as defined in Section 3 of
|
|||
|
|
<a class="info" href="#RFC6750">OAuth 2.0 Bearer Token
|
|||
|
|
Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750].
|
|||
|
|
(HTTP errors unrelated to RFC 6750 are returned to the User Agent using the
|
|||
|
|
appropriate HTTP status code.)
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of a UserInfo Error Response:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 401 Unauthorized
|
|||
|
|
WWW-Authenticate: error="invalid_token",
|
|||
|
|
error_description="The Access Token expired"
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="UserInfoResponseValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.3.4"></a>
|
|||
|
|
|
|||
|
|
<h3>5.3.4.
|
|||
|
|
UserInfo Response Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Client MUST validate the UserInfo Response as follows:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Verify that the OP that responded was the intended OP
|
|||
|
|
through a TLS server certificate check, per
|
|||
|
|
<a class="info" href="#RFC6125">RFC 6125<span> (</span><span
|
|||
|
|
class="info">Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.</span><span>)</span></a>
|
|||
|
|
[RFC6125].
|
|||
|
|
</li>
|
|||
|
|
<li>If the Client has provided a
|
|||
|
|
<tt>userinfo_encrypted_response_alg</tt>
|
|||
|
|
parameter during Registration, decrypt the UserInfo Response
|
|||
|
|
using the keys specified during Registration.
|
|||
|
|
</li>
|
|||
|
|
<li>If the response was signed, the Client SHOULD validate the
|
|||
|
|
signature according to <a class="info" href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS].
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ScopeClaims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.4"></a>
|
|||
|
|
|
|||
|
|
<h3>5.4.
|
|||
|
|
Requesting Claims using Scope Values</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect Clients use <tt>scope</tt> values,
|
|||
|
|
as defined in Section 3.3 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749],
|
|||
|
|
to specify what
|
|||
|
|
access privileges are being requested for Access Tokens. The scopes associated
|
|||
|
|
with Access Tokens determine what resources will be available when they are
|
|||
|
|
used to access OAuth 2.0 protected endpoints.
|
|||
|
|
Protected Resource endpoints MAY perform different actions and
|
|||
|
|
return different information based on the scope values and other parameters
|
|||
|
|
used when requesting the presented Access Token.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
For OpenID Connect, scopes
|
|||
|
|
can be used to request that specific sets of information
|
|||
|
|
be made available as Claim Values.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Claims requested by the following scopes are treated by Authorization Servers
|
|||
|
|
as Voluntary Claims.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following <tt>scope</tt> values
|
|||
|
|
that are used to request Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>profile</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. This scope value
|
|||
|
|
requests access to the End-User's default profile Claims,
|
|||
|
|
which are:
|
|||
|
|
|
|||
|
|
<tt>name</tt>,
|
|||
|
|
<tt>family_name</tt>,
|
|||
|
|
<tt>given_name</tt>,
|
|||
|
|
<tt>middle_name</tt>,
|
|||
|
|
<tt>nickname</tt>,
|
|||
|
|
<tt>preferred_username</tt>,
|
|||
|
|
<tt>profile</tt>,
|
|||
|
|
<tt>picture</tt>,
|
|||
|
|
<tt>website</tt>,
|
|||
|
|
<tt>gender</tt>,
|
|||
|
|
<tt>birthdate</tt>,
|
|||
|
|
<tt>zoneinfo</tt>,
|
|||
|
|
<tt>locale</tt>, and
|
|||
|
|
<tt>updated_at</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>email</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. This scope value requests access to
|
|||
|
|
the <tt>email</tt> and
|
|||
|
|
<tt>email_verified</tt> Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>address</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. This scope value requests access to
|
|||
|
|
the <tt>address</tt> Claim.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>phone</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. This scope value requests access to
|
|||
|
|
the <tt>phone_number</tt> and
|
|||
|
|
<tt>phone_number_verified</tt> Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Multiple scope values MAY be used by creating a space delimited, case
|
|||
|
|
sensitive list of ASCII scope values.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Claims requested by the
|
|||
|
|
<tt>profile</tt>,
|
|||
|
|
<tt>email</tt>,
|
|||
|
|
<tt>address</tt>, and
|
|||
|
|
<tt>phone</tt> scope values
|
|||
|
|
are returned from the UserInfo Endpoint,
|
|||
|
|
as described in <a class="info" href="#UserInfoResponse">Section 5.3.2<span> (</span><span
|
|||
|
|
class="info">Successful UserInfo Response</span><span>)</span></a>,
|
|||
|
|
when a <tt>response_type</tt> value is used
|
|||
|
|
that results in an Access Token being issued.
|
|||
|
|
However, when no Access Token is issued
|
|||
|
|
(which is the case for the <tt>response_type</tt>
|
|||
|
|
value <tt>id_token</tt>),
|
|||
|
|
the resulting Claims are returned in the ID Token.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>In some cases, the End-User will be given the option to
|
|||
|
|
have the OpenID Provider decline to provide some or all
|
|||
|
|
information requested by RPs.
|
|||
|
|
To minimize the amount of information that the End-User is being asked
|
|||
|
|
to disclose, an RP can elect to
|
|||
|
|
only request a subset of the information available from the
|
|||
|
|
UserInfo Endpoint.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of an unencoded
|
|||
|
|
<tt>scope</tt> request:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> scope=openid profile email phone
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="ClaimsParameter"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.5"></a>
|
|||
|
|
|
|||
|
|
<h3>5.5.
|
|||
|
|
Requesting Claims using the "claims" Request Parameter</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following Authorization Request parameter
|
|||
|
|
to enable requesting individual Claims
|
|||
|
|
and specifying parameters that apply to the requested Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
This parameter is used to request that specific Claims be returned.
|
|||
|
|
The value is a JSON object listing the requested Claims.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>claims</tt> Authentication Request
|
|||
|
|
parameter requests that specific Claims
|
|||
|
|
be returned from the UserInfo Endpoint and/or in the ID Token.
|
|||
|
|
It is represented as a JSON object containing lists of Claims being requested
|
|||
|
|
from these locations.
|
|||
|
|
Properties of the Claims being requested MAY also be specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Support for the <tt>claims</tt> parameter is OPTIONAL.
|
|||
|
|
Should an OP not support this parameter and an RP uses it,
|
|||
|
|
the OP SHOULD return a set of Claims to the RP that it believes would
|
|||
|
|
be useful to the RP and the End-User using whatever heuristics it
|
|||
|
|
believes are appropriate.
|
|||
|
|
The <tt>claims_parameter_supported</tt>
|
|||
|
|
Discovery result indicates whether the OP supports this parameter.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>claims</tt> parameter value is represented
|
|||
|
|
in an OAuth 2.0 request as UTF-8 encoded JSON
|
|||
|
|
(which ends up being form-urlencoded when passed as an OAuth parameter).
|
|||
|
|
When used in a Request Object value, per <a class="info"
|
|||
|
|
href="#RequestObject">Section 6.1<span> (</span><span
|
|||
|
|
class="info">Passing a Request Object by Value</span><span>)</span></a>,
|
|||
|
|
the JSON is used as the value of the
|
|||
|
|
<tt>claims</tt> member.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The top-level members of the Claims request JSON object are:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>userinfo</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Requests that the listed individual Claims be returned
|
|||
|
|
from the UserInfo Endpoint.
|
|||
|
|
If present, the listed Claims are being requested to be added to
|
|||
|
|
any Claims that are being requested using
|
|||
|
|
<tt>scope</tt> values.
|
|||
|
|
If not present, the Claims being requested from the UserInfo Endpoint
|
|||
|
|
are only those requested using <tt>scope</tt> values.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
When the <tt>userinfo</tt> member is used,
|
|||
|
|
the request MUST also use a <tt>response_type</tt>
|
|||
|
|
value that results in an Access Token being issued to the Client
|
|||
|
|
for use at the UserInfo Endpoint.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>id_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Requests that the listed individual Claims be returned
|
|||
|
|
in the ID Token.
|
|||
|
|
If present, the listed Claims are being requested to be added to
|
|||
|
|
the default Claims in the ID Token.
|
|||
|
|
If not present, the default ID Token Claims are requested,
|
|||
|
|
as per the ID Token definition in <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>
|
|||
|
|
and per the additional per-flow ID Token requirements in Sections
|
|||
|
|
<a class="info"
|
|||
|
|
href="#CodeIDToken">3.1.3.6<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ImplicitIDToken">3.2.2.10<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#HybridIDToken">3.3.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>,
|
|||
|
|
and <a class="info" href="#HybridIDToken2">3.3.3.6<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
Other members MAY be present.
|
|||
|
|
Any members used that are not understood MUST be ignored.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>An example Claims request is as follows:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"userinfo":
|
|||
|
|
{
|
|||
|
|
"given_name": {"essential": true},
|
|||
|
|
"nickname": null,
|
|||
|
|
"email": {"essential": true},
|
|||
|
|
"email_verified": {"essential": true},
|
|||
|
|
"picture": null,
|
|||
|
|
"http://example.info/claims/groups": null
|
|||
|
|
},
|
|||
|
|
"id_token":
|
|||
|
|
{
|
|||
|
|
"auth_time": {"essential": true},
|
|||
|
|
"acr": {"values": ["urn:mace:incommon:iap:silver"] }
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
Note that a Claim that is not in the standard set defined in
|
|||
|
|
<a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a>, the (example)
|
|||
|
|
<tt>http://example.info/claims/groups</tt> Claim,
|
|||
|
|
is being requested.
|
|||
|
|
Using the <tt>claims</tt> parameter is the only
|
|||
|
|
way to request Claims outside the standard set.
|
|||
|
|
It is also the only way to request specific combinations of the
|
|||
|
|
standard Claims that cannot be specified using scope values.
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="IndividualClaimsRequests"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.5.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.5.1.
|
|||
|
|
Individual Claims Requests</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>userinfo</tt> and
|
|||
|
|
<tt>id_token</tt> members of the
|
|||
|
|
<tt>claims</tt> request both are JSON objects
|
|||
|
|
with the names of the individual Claims being requested as the member names.
|
|||
|
|
The member values MUST be one of the following:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>null</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Indicates that this Claim is being requested in the default manner.
|
|||
|
|
In particular, this is a Voluntary Claim.
|
|||
|
|
For instance, the Claim request:
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> "given_name": null
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
requests the <tt>given_name</tt> Claim
|
|||
|
|
in the default manner.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>JSON Object</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Used to provide additional information about the Claim being
|
|||
|
|
requested. This specification defines the following members:
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>essential</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Indicates whether the Claim being requested is an Essential Claim.
|
|||
|
|
If the value is <tt>true</tt>,
|
|||
|
|
this indicates that the Claim is an Essential Claim.
|
|||
|
|
For instance, the Claim request:
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> "auth_time": {"essential": true}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
can be used to specify that it is Essential to return an
|
|||
|
|
<tt>auth_time</tt> Claim Value.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
If the value is <tt>false</tt>,
|
|||
|
|
it indicates that it is a Voluntary Claim.
|
|||
|
|
The default is <tt>false</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
By requesting Claims as Essential Claims,
|
|||
|
|
the RP indicates to the End-User
|
|||
|
|
that releasing these Claims will ensure a smooth authorization
|
|||
|
|
for the specific task requested by the End-User.
|
|||
|
|
Note that even if the Claims are not available because
|
|||
|
|
the End-User did not authorize their release or they are not present,
|
|||
|
|
the Authorization Server MUST NOT generate an error when
|
|||
|
|
Claims are not returned, whether they are Essential or Voluntary,
|
|||
|
|
unless otherwise specified in the description of the specific claim.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>value</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Requests that the Claim be returned with a particular value.
|
|||
|
|
For instance the Claim request:
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> "sub": {"value": "248289761001"}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
can be used to specify that the request apply to the End-User
|
|||
|
|
with Subject Identifier <tt>248289761001</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The value of the <tt>value</tt> member
|
|||
|
|
MUST be a valid value for the Claim being requested.
|
|||
|
|
Definitions of individual Claims can include requirements on
|
|||
|
|
how and whether the <tt>value</tt>
|
|||
|
|
qualifier is to be used when requesting that Claim.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>values</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Requests that the Claim be returned with one of a set of values,
|
|||
|
|
with the values appearing in order of preference.
|
|||
|
|
For instance the Claim request:
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> "acr": {"essential": true,
|
|||
|
|
"values": ["urn:mace:incommon:iap:silver",
|
|||
|
|
"urn:mace:incommon:iap:bronze"]}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
specifies that it is Essential that the <tt>acr</tt>
|
|||
|
|
Claim be returned with either the value
|
|||
|
|
<tt>urn:mace:incommon:iap:silver</tt> or
|
|||
|
|
<tt>urn:mace:incommon:iap:bronze</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The values in the <tt>values</tt> member array
|
|||
|
|
MUST be valid values for the Claim being requested.
|
|||
|
|
Definitions of individual Claims can include requirements on
|
|||
|
|
how and whether the <tt>values</tt>
|
|||
|
|
qualifier is to be used when requesting that Claim.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
Other members MAY be defined to provide additional
|
|||
|
|
information about the requested Claims.
|
|||
|
|
Any members used that are not understood MUST be ignored.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Note that when the <tt>claims</tt> request parameter
|
|||
|
|
is supported, the scope values that request Claims, as defined in
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ScopeClaims">Section 5.4<span> (</span><span
|
|||
|
|
class="info">Requesting Claims using Scope Values</span><span>)</span></a>, are effectively shorthand
|
|||
|
|
methods for
|
|||
|
|
requesting sets of individual Claims.
|
|||
|
|
For example, using the scope value <tt>openid email</tt>
|
|||
|
|
and a <tt>response_type</tt> that returns an Access Token
|
|||
|
|
is equivalent to using the scope value <tt>openid</tt>
|
|||
|
|
and the following request for individual Claims.
|
|||
|
|
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Equivalent of using the <tt>email</tt> scope value:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"userinfo":
|
|||
|
|
{
|
|||
|
|
"email": null,
|
|||
|
|
"email_verified": null
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="acrSemantics"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.5.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.5.1.1.
|
|||
|
|
Requesting the "acr" Claim</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the <tt>acr</tt> Claim is requested
|
|||
|
|
as an Essential Claim for the ID Token
|
|||
|
|
with a <tt>values</tt> parameter requesting
|
|||
|
|
specific Authentication Context Class Reference values and
|
|||
|
|
the implementation supports the <tt>claims</tt> parameter,
|
|||
|
|
the Authorization Server MUST return an <tt>acr</tt>
|
|||
|
|
Claim Value that matches one of the requested values.
|
|||
|
|
The Authorization Server MAY ask the End-User to re-authenticate
|
|||
|
|
with additional factors
|
|||
|
|
to meet this requirement. If this is an Essential Claim and the
|
|||
|
|
requirement cannot be met, then the Authorization Server MUST
|
|||
|
|
treat that outcome as a failed authentication attempt.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Note that the RP MAY request the <tt>acr</tt>
|
|||
|
|
Claim as a Voluntary Claim
|
|||
|
|
by using the <tt>acr_values</tt> request parameter
|
|||
|
|
or by not including "essential": true in an individual
|
|||
|
|
<tt>acr</tt> Claim request.
|
|||
|
|
If the Claim is not Essential and a requested value
|
|||
|
|
cannot be provided, the Authorization Server SHOULD return
|
|||
|
|
the session's current <tt>acr</tt> as
|
|||
|
|
the value of the <tt>acr</tt> Claim.
|
|||
|
|
If the Claim is not Essential, the Authorization Server is not required to
|
|||
|
|
provide this Claim in its response.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the client requests the <tt>acr</tt> Claim using
|
|||
|
|
both the <tt>acr_values</tt> request parameter and
|
|||
|
|
an individual <tt>acr</tt> Claim request for the ID Token
|
|||
|
|
listing specific requested values,
|
|||
|
|
the resulting behavior is unspecified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="IndividualClaimsLanguages"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.5.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.5.2.
|
|||
|
|
Languages and Scripts for Individual Claims</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
As described in <a class="info"
|
|||
|
|
href="#ClaimsLanguagesAndScripts">Section 5.2<span> (</span><span
|
|||
|
|
class="info">Claims Languages and Scripts</span><span>)</span></a>,
|
|||
|
|
human-readable Claim Values and Claim Values that reference human-readable values
|
|||
|
|
MAY be represented in multiple languages and scripts.
|
|||
|
|
Within a request for individual Claims, requested languages and scripts
|
|||
|
|
for particular Claims MAY be requested by including Claim Names
|
|||
|
|
that contain <tt>#</tt>-separated
|
|||
|
|
<a class="info" href="#RFC5646">BCP47<span> (</span><span
|
|||
|
|
class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a>
|
|||
|
|
[RFC5646] language tags
|
|||
|
|
in the Claims request, using the Claim Name syntax specified in
|
|||
|
|
<a class="info" href="#ClaimsLanguagesAndScripts">Section 5.2<span> (</span><span
|
|||
|
|
class="info">Claims Languages and Scripts</span><span>)</span></a>.
|
|||
|
|
For example, a Family Name in Katakana in Japanese
|
|||
|
|
can be requested using the Claim Name
|
|||
|
|
<tt>family_name#ja-Kana-JP</tt>
|
|||
|
|
and a Kanji representation of the Family Name in Japanese
|
|||
|
|
can be requested using the Claim Name
|
|||
|
|
<tt>family_name#ja-Hani-JP</tt>.
|
|||
|
|
A German-language Web site can be requested with the Claim Name
|
|||
|
|
<tt>website#de</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If an OP receives a request for human-readable Claims in a language and script
|
|||
|
|
that it doesn't have, any versions of those Claims returned that don't use
|
|||
|
|
the requested language and script SHOULD use a language tag in the Claim Name.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ClaimTypes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.6"></a>
|
|||
|
|
|
|||
|
|
<h3>5.6.
|
|||
|
|
Claim Types</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Three representations of Claim Values are defined by this specification:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Normal Claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Claims that are directly asserted by
|
|||
|
|
the OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Aggregated Claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Claims that are asserted by a
|
|||
|
|
Claims Provider other than the OpenID Provider but are returned
|
|||
|
|
by OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Distributed Claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Claims that are asserted by a
|
|||
|
|
Claims Provider other than the OpenID Provider but are returned
|
|||
|
|
as references by the OpenID Provider.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Normal Claims MUST be supported.
|
|||
|
|
Support for Aggregated Claims and Distributed Claims is OPTIONAL.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="NormalClaims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.6.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.6.1.
|
|||
|
|
Normal Claims</h3>
|
|||
|
|
|
|||
|
|
<p>Normal Claims are represented as members in a JSON object. The
|
|||
|
|
Claim Name is the member name and the Claim Value is the member
|
|||
|
|
value.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative response containing Normal Claims:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"name": "Jane Doe",
|
|||
|
|
"given_name": "Jane",
|
|||
|
|
"family_name": "Doe",
|
|||
|
|
"email": "janedoe@example.com",
|
|||
|
|
"picture": "http://example.com/janedoe/me.jpg"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="AggregatedDistributedClaims"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.6.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.6.2.
|
|||
|
|
Aggregated and Distributed Claims</h3>
|
|||
|
|
|
|||
|
|
<p>Aggregated and distributed Claims are represented by
|
|||
|
|
using special <tt>_claim_names</tt> and
|
|||
|
|
<tt>_claim_sources</tt> members
|
|||
|
|
of the JSON object containing the Claims.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>_claim_names</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
JSON object whose member
|
|||
|
|
names are the Claim Names for the Aggregated and Distributed
|
|||
|
|
Claims. The member values are references to the member names
|
|||
|
|
in the <tt>_claim_sources</tt> member from which
|
|||
|
|
the actual Claim Values can be retrieved.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>_claim_sources</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
JSON object whose
|
|||
|
|
member names are referenced by the member values of the
|
|||
|
|
<tt>_claim_names</tt> member. The member values
|
|||
|
|
contain sets of Aggregated Claims or reference locations for
|
|||
|
|
Distributed Claims. The member values can have one of the
|
|||
|
|
following formats depending on whether it is providing
|
|||
|
|
Aggregated or Distributed Claims:
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Aggregated Claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
JSON object that MUST
|
|||
|
|
contain the <tt>JWT</tt> member whose value is a <a class="info"
|
|||
|
|
href="#JWT">JWT<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT] that MUST contain all the Claims
|
|||
|
|
in the <tt>_claim_names</tt> object that references the
|
|||
|
|
corresponding <tt>_claim_sources</tt> member.
|
|||
|
|
Other members MAY be present.
|
|||
|
|
Any members used that are not understood MUST be ignored.
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>JWT</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
JWT containing Claim Values.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The JWT SHOULD NOT contain a <tt>sub</tt> (subject)
|
|||
|
|
Claim unless its value is an identifier for the End-User at
|
|||
|
|
the Claims Provider (and not for the OpenID Provider or another party);
|
|||
|
|
this typically means that a <tt>sub</tt> Claim
|
|||
|
|
SHOULD NOT be provided.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Distributed Claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
JSON object that
|
|||
|
|
contains the following members and values:
|
|||
|
|
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>endpoint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
OAuth 2.0 resource endpoint from which the associated
|
|||
|
|
Claim can be retrieved. The endpoint URL MUST return
|
|||
|
|
the Claim as a JWT.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>access_token</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Access Token
|
|||
|
|
enabling retrieval of the Claims from the endpoint URL
|
|||
|
|
by using the <a class="info"
|
|||
|
|
href="#RFC6750">OAuth
|
|||
|
|
2.0 Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750]
|
|||
|
|
protocol. Claims SHOULD be requested using
|
|||
|
|
the Authorization Request header field and Claims Providers
|
|||
|
|
MUST support this method. If the Access Token
|
|||
|
|
is not available, RPs MAY need to retrieve the
|
|||
|
|
Access Token out of band or use an Access Token
|
|||
|
|
that was pre-negotiated between the Claims Provider and
|
|||
|
|
RP, or the Claims Provider MAY reauthenticate the
|
|||
|
|
End-User and/or reauthorize the RP.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
A <tt>sub</tt> (subject) Claim SHOULD NOT
|
|||
|
|
be returned from the Claims Provider
|
|||
|
|
unless its value is an identifier for the End-User at
|
|||
|
|
the Claims Provider (and not for the OpenID Provider or another party);
|
|||
|
|
this typically means that a <tt>sub</tt> Claim
|
|||
|
|
SHOULD NOT be provided.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In general, it is up to the OP when it is appropriate to use
|
|||
|
|
Aggregated Claims and Distributed Claims.
|
|||
|
|
In some cases, information about when to use what Claim Types
|
|||
|
|
might be negotiated out of band between RPs and OPs.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AggregatedExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.6.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>5.6.2.1.
|
|||
|
|
Example of Aggregated Claims</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In this non-normative example, Claims from Claims Provider A
|
|||
|
|
are combined with other Claims held by the OpenID provider, with the
|
|||
|
|
Claims from Claims Provider A being returned as Aggregated Claims.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In this example, these Claims about Jane Doe have been issued by
|
|||
|
|
Claims Provider A:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"address": {
|
|||
|
|
"street_address": "1234 Hollywood Blvd.",
|
|||
|
|
"locality": "Los Angeles",
|
|||
|
|
"region": "CA",
|
|||
|
|
"postal_code": "90210",
|
|||
|
|
"country": "US"},
|
|||
|
|
"phone_number": "+1 (310) 123-4567"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Claims Provider A signs the JSON Claims, representing them in a signed JWT:
|
|||
|
|
jwt_header.jwt_part2.jwt_part3.
|
|||
|
|
It is this JWT that is used by the OpenID Provider.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In this example, this JWT containing Jane Doe's Aggregated Claims
|
|||
|
|
from Claims Provider A is combined with other Normal Claims,
|
|||
|
|
and returned as the following set of Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"name": "Jane Doe",
|
|||
|
|
"given_name": "Jane",
|
|||
|
|
"family_name": "Doe",
|
|||
|
|
"birthdate": "0000-03-22",
|
|||
|
|
"eye_color": "blue",
|
|||
|
|
"email": "janedoe@example.com",
|
|||
|
|
"_claim_names": {
|
|||
|
|
"address": "src1",
|
|||
|
|
"phone_number": "src1"
|
|||
|
|
},
|
|||
|
|
"_claim_sources": {
|
|||
|
|
"src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="DistributedExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.6.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>5.6.2.2.
|
|||
|
|
Example of Distributed Claims</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In this non-normative example, the OpenID Provider combines
|
|||
|
|
Normal Claims that it holds with references to Claims held by
|
|||
|
|
two different Claims Providers, B and C, incorporating references
|
|||
|
|
to some of the Claims held by B and C as Distributed Claims.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In this example, these Claims about Jane Doe are held by
|
|||
|
|
Claims Provider B (Jane Doe's bank):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"shipping_address": {
|
|||
|
|
"street_address": "1234 Hollywood Blvd.",
|
|||
|
|
"locality": "Los Angeles",
|
|||
|
|
"region": "CA",
|
|||
|
|
"postal_code": "90210",
|
|||
|
|
"country": "US"},
|
|||
|
|
"payment_info": "Some_Card 1234 5678 9012 3456",
|
|||
|
|
"phone_number": "+1 (310) 123-4567"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Also in this example, this Claim about Jane Doe is held by
|
|||
|
|
Claims Provider C (a credit agency):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"credit_score": 650
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OpenID Provider returns Jane Doe's Claims along with references
|
|||
|
|
to the Distributed Claims from Claims Provider B and Claims Provider C
|
|||
|
|
by sending the Access Tokens and URLs of locations from which the
|
|||
|
|
Distributed Claims can be retrieved:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"name": "Jane Doe",
|
|||
|
|
"given_name": "Jane",
|
|||
|
|
"family_name": "Doe",
|
|||
|
|
"email": "janedoe@example.com",
|
|||
|
|
"birthdate": "0000-03-22",
|
|||
|
|
"eye_color": "blue",
|
|||
|
|
"_claim_names": {
|
|||
|
|
"payment_info": "src1",
|
|||
|
|
"shipping_address": "src1",
|
|||
|
|
"credit_score": "src2"
|
|||
|
|
},
|
|||
|
|
"_claim_sources": {
|
|||
|
|
"src1": {"endpoint":
|
|||
|
|
"https://bank.example.com/claim_source"},
|
|||
|
|
"src2": {"endpoint":
|
|||
|
|
"https://creditagency.example.com/claims_here",
|
|||
|
|
"access_token": "ksj3n283dke"}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="ClaimStability"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.5.7"></a>
|
|||
|
|
|
|||
|
|
<h3>5.7.
|
|||
|
|
Claim Stability and Uniqueness</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>sub</tt> (subject) and
|
|||
|
|
<tt>iss</tt> (issuer) Claims, used together,
|
|||
|
|
are the only Claims that an RP
|
|||
|
|
can rely upon as a stable identifier for the End-User,
|
|||
|
|
since the <tt>sub</tt>
|
|||
|
|
Claim MUST be locally unique and never reassigned within the Issuer
|
|||
|
|
for a particular End-User, as described in <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
Therefore, the only guaranteed unique identifier for a given End-User is the
|
|||
|
|
combination of the <tt>iss</tt> Claim
|
|||
|
|
and the <tt>sub</tt> Claim.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
All other Claims carry no such guarantees across different issuers in terms of
|
|||
|
|
stability over time or uniqueness across users, and Issuers are permitted to
|
|||
|
|
apply local restrictions and policies. For instance, an Issuer MAY re-use an
|
|||
|
|
<tt>email</tt> Claim Value across different
|
|||
|
|
End-Users at different points in time, and the claimed
|
|||
|
|
<tt>email</tt> address for a given End-User MAY change
|
|||
|
|
over time.
|
|||
|
|
Therefore, other Claims such as <tt>email</tt>,
|
|||
|
|
<tt>phone_number</tt>, and
|
|||
|
|
<tt>preferred_username</tt>
|
|||
|
|
and MUST NOT be used as unique identifiers for the End-User.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="JWTRequests"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6"></a>
|
|||
|
|
|
|||
|
|
<h3>6.
|
|||
|
|
Passing Request Parameters as JWTs</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following Authorization Request parameters
|
|||
|
|
to enable Authentication Requests to be signed and optionally encrypted:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>request</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
This parameter enables
|
|||
|
|
OpenID Connect requests to be passed in a single,
|
|||
|
|
self-contained parameter and to be optionally signed and/or encrypted.
|
|||
|
|
The parameter value is a Request Object value,
|
|||
|
|
as specified in <a class="info" href="#RequestObject">Section 6.1<span> (</span><span
|
|||
|
|
class="info">Passing a Request Object by Value</span><span>)</span></a>.
|
|||
|
|
It represents the request as a JWT whose Claims
|
|||
|
|
are the request parameters.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>request_uri</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
This parameter enables
|
|||
|
|
OpenID Connect requests to be passed by reference, rather than by value.
|
|||
|
|
The <tt>request_uri</tt> value is a URL
|
|||
|
|
using the <tt>https</tt> scheme
|
|||
|
|
referencing a resource containing a Request Object value,
|
|||
|
|
which is a JWT containing the request parameters.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Requests using these parameters are represented as JWTs, which are respectively
|
|||
|
|
passed by value or by reference.
|
|||
|
|
The ability to pass requests by reference is particularly useful for large requests.
|
|||
|
|
If one of these parameters is used,
|
|||
|
|
the other MUST NOT be used in the same request.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RequestObject"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.1"></a>
|
|||
|
|
|
|||
|
|
<h3>6.1.
|
|||
|
|
Passing a Request Object by Value</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>request</tt> Authorization Request parameter
|
|||
|
|
enables OpenID Connect requests to be passed in a single,
|
|||
|
|
self-contained parameter and to be optionally signed and/or encrypted.
|
|||
|
|
It represents the request as a JWT whose Claims are the request parameters
|
|||
|
|
specified in <a class="info" href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
This JWT is called a Request Object.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Support for the <tt>request</tt> parameter is OPTIONAL.
|
|||
|
|
The <tt>request_parameter_supported</tt>
|
|||
|
|
Discovery result indicates whether the OP supports this parameter.
|
|||
|
|
Should an OP not support this parameter and an RP uses it,
|
|||
|
|
the OP MUST return the <tt>request_not_supported</tt>
|
|||
|
|
error.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When the <tt>request</tt> parameter is used,
|
|||
|
|
the OpenID Connect request parameter values contained in the JWT
|
|||
|
|
supersede those passed using the OAuth 2.0 request syntax.
|
|||
|
|
However, parameters MAY also be passed using the OAuth 2.0 request syntax
|
|||
|
|
even when a Request Object is used;
|
|||
|
|
this would typically be done to enable a cached,
|
|||
|
|
pre-signed (and possibly pre-encrypted) Request Object value
|
|||
|
|
to be used containing the fixed request parameters, while parameters that
|
|||
|
|
can vary with each request, such as <tt>state</tt> and
|
|||
|
|
<tt>nonce</tt>, are passed as OAuth 2.0 parameters.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
So that the request is a valid OAuth 2.0 Authorization Request,
|
|||
|
|
values for the <tt>response_type</tt> and
|
|||
|
|
<tt>client_id</tt> parameters MUST be included
|
|||
|
|
using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
|
|||
|
|
The values for these parameters MUST match those in the Request Object,
|
|||
|
|
if present.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Even if a <tt>scope</tt> parameter
|
|||
|
|
is present in the Request Object value,
|
|||
|
|
a <tt>scope</tt> parameter MUST always be passed using
|
|||
|
|
the OAuth 2.0 request syntax containing the
|
|||
|
|
<tt>openid</tt> scope value to indicate to the
|
|||
|
|
underlying OAuth 2.0 logic that this is an OpenID Connect request.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Request Object MAY be signed or unsigned (plaintext).
|
|||
|
|
When it is plaintext, this is indicated by use of the
|
|||
|
|
<tt>none</tt> algorithm <a class="info" href="#JWA">[JWA]<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a>
|
|||
|
|
in the JOSE Header. If signed, the Request Object
|
|||
|
|
SHOULD contain the Claims
|
|||
|
|
<tt>iss</tt> (issuer)
|
|||
|
|
and <tt>aud</tt> (audience) as members.
|
|||
|
|
The <tt>iss</tt> value SHOULD be the Client ID of the RP,
|
|||
|
|
unless it was signed by a different party than the RP.
|
|||
|
|
The <tt>aud</tt> value SHOULD be or include
|
|||
|
|
the OP's Issuer Identifier URL.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Request Object MAY also be encrypted using <a class="info"
|
|||
|
|
href="#JWE">JWE<span> (</span><span
|
|||
|
|
class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE]
|
|||
|
|
and MAY be encrypted without also being signed.
|
|||
|
|
If both signing and encryption are performed, it MUST be signed then encrypted,
|
|||
|
|
with the result being a Nested JWT, as defined in <a class="info"
|
|||
|
|
href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
<tt>request</tt> and
|
|||
|
|
<tt>request_uri</tt> parameters
|
|||
|
|
MUST NOT be included in Request Objects.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of the Claims in
|
|||
|
|
a Request Object before base64url encoding and signing:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "s6BhdRkqt3",
|
|||
|
|
"aud": "https://server.example.com",
|
|||
|
|
"response_type": "code id_token",
|
|||
|
|
"client_id": "s6BhdRkqt3",
|
|||
|
|
"redirect_uri": "https://client.example.org/cb",
|
|||
|
|
"scope": "openid",
|
|||
|
|
"state": "af0ifjsldkj",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"max_age": 86400,
|
|||
|
|
"claims":
|
|||
|
|
{
|
|||
|
|
"userinfo":
|
|||
|
|
{
|
|||
|
|
"given_name": {"essential": true},
|
|||
|
|
"nickname": null,
|
|||
|
|
"email": {"essential": true},
|
|||
|
|
"email_verified": {"essential": true},
|
|||
|
|
"picture": null
|
|||
|
|
},
|
|||
|
|
"id_token":
|
|||
|
|
{
|
|||
|
|
"gender": null,
|
|||
|
|
"birthdate": {"essential": true},
|
|||
|
|
"acr": {"values": ["urn:mace:incommon:iap:silver"]}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Signing it with the <tt>RS256</tt> algorithm
|
|||
|
|
results in this Request Object value
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
|
|||
|
|
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
|
|||
|
|
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
|
|||
|
|
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
|
|||
|
|
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
|
|||
|
|
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
|
|||
|
|
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
|
|||
|
|
ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
|
|||
|
|
Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
|
|||
|
|
wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
|
|||
|
|
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
|
|||
|
|
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
|
|||
|
|
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
|
|||
|
|
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
|
|||
|
|
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
|
|||
|
|
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
|
|||
|
|
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
|
|||
|
|
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
|
|||
|
|
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following RSA public key, represented in JWK format, can be used to
|
|||
|
|
validate the Request Object signature in this
|
|||
|
|
and subsequent Request Object examples
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"kty":"RSA",
|
|||
|
|
"kid":"k2bdc",
|
|||
|
|
"n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P
|
|||
|
|
7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
|
|||
|
|
I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
|
|||
|
|
ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
|
|||
|
|
adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
|
|||
|
|
W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
|
|||
|
|
"e":"AQAB"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="RequestParameter"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>6.1.1.
|
|||
|
|
Request using the "request" Request Parameter</h3>
|
|||
|
|
|
|||
|
|
<p>The Client sends the Authorization Request to the
|
|||
|
|
Authorization Endpoint.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example of an
|
|||
|
|
Authorization Request using the <tt>request</tt>
|
|||
|
|
parameter
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> https://server.example.com/authorize?
|
|||
|
|
response_type=code%20id_token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
|
|||
|
|
iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN
|
|||
|
|
vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV
|
|||
|
|
udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8
|
|||
|
|
vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA
|
|||
|
|
ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo
|
|||
|
|
iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN
|
|||
|
|
lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw
|
|||
|
|
iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo
|
|||
|
|
geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ
|
|||
|
|
lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw
|
|||
|
|
NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo
|
|||
|
|
gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN
|
|||
|
|
yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
|
|||
|
|
NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
|
|||
|
|
h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
|
|||
|
|
GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
|
|||
|
|
UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
|
|||
|
|
jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
|
|||
|
|
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="RequestUriParameter"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.2"></a>
|
|||
|
|
|
|||
|
|
<h3>6.2.
|
|||
|
|
Passing a Request Object by Reference</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>request_uri</tt> Authorization Request parameter enables
|
|||
|
|
OpenID Connect requests to be passed by reference, rather than by value.
|
|||
|
|
This parameter is used identically to the
|
|||
|
|
<tt>request</tt> parameter, other than that
|
|||
|
|
the Request Object value is retrieved from the resource at the specified URL,
|
|||
|
|
rather than passed by value.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>request_uri_parameter_supported</tt>
|
|||
|
|
Discovery result indicates whether the OP supports this parameter.
|
|||
|
|
Should an OP not support this parameter and an RP uses it,
|
|||
|
|
the OP MUST return the <tt>request_uri_not_supported</tt>
|
|||
|
|
error.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When the <tt>request_uri</tt> parameter is used,
|
|||
|
|
the OpenID Connect request parameter values contained in the referenced JWT
|
|||
|
|
supersede those passed using the OAuth 2.0 request syntax.
|
|||
|
|
However, parameters MAY also be passed using the OAuth 2.0 request syntax
|
|||
|
|
even when a <tt>request_uri</tt> is used;
|
|||
|
|
this would typically be done to enable a cached,
|
|||
|
|
pre-signed (and possibly pre-encrypted) Request Object value
|
|||
|
|
to be used containing the fixed request parameters, while parameters that
|
|||
|
|
can vary with each request, such as <tt>state</tt> and
|
|||
|
|
<tt>nonce</tt>, are passed as OAuth 2.0 parameters.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
So that the request is a valid OAuth 2.0 Authorization Request,
|
|||
|
|
values for the <tt>response_type</tt> and
|
|||
|
|
<tt>client_id</tt> parameters MUST be included
|
|||
|
|
using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
|
|||
|
|
The values for these parameters MUST match those in the Request Object,
|
|||
|
|
if present.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Even if a <tt>scope</tt> parameter
|
|||
|
|
is present in the referenced Request Object,
|
|||
|
|
a <tt>scope</tt> parameter MUST always be passed using
|
|||
|
|
the OAuth 2.0 request syntax containing the
|
|||
|
|
<tt>openid</tt> scope value to indicate to the
|
|||
|
|
underlying OAuth 2.0 logic that this is an OpenID Connect request.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Servers MAY cache the contents of the resources referenced by Request URIs.
|
|||
|
|
If the contents of the referenced resource could ever change,
|
|||
|
|
the URI SHOULD include the base64url encoded SHA-256 hash of the
|
|||
|
|
referenced resource contents as the fragment component of the URI.
|
|||
|
|
If the fragment value used for a URI changes, that signals the server
|
|||
|
|
that any cached value for that URI with the old fragment value
|
|||
|
|
is no longer valid.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Note that Clients MAY pre-register
|
|||
|
|
<tt>request_uri</tt> values using the
|
|||
|
|
<tt>request_uris</tt> parameter defined in
|
|||
|
|
Section 2.1 of the
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID Connect
|
|||
|
|
Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration]
|
|||
|
|
specification.
|
|||
|
|
OPs can require that <tt>request_uri</tt> values used
|
|||
|
|
be pre-registered with the <tt>require_request_uri_registration</tt>
|
|||
|
|
discovery parameter.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The entire Request URI MUST NOT exceed 512 ASCII characters.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The contents of the resource referenced by the URL MUST be a Request Object.
|
|||
|
|
The scheme used in the
|
|||
|
|
<tt>request_uri</tt> value MUST be <tt>https</tt>,
|
|||
|
|
unless the target Request Object is signed in a way that is verifiable by the
|
|||
|
|
Authorization Server.
|
|||
|
|
The <tt>request_uri</tt> value MUST be reachable by the
|
|||
|
|
Authorization Server, and SHOULD be reachable by the Client.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example of
|
|||
|
|
the contents of a Request Object resource that can be
|
|||
|
|
referenced by a <tt>request_uri</tt>
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
|
|||
|
|
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
|
|||
|
|
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
|
|||
|
|
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
|
|||
|
|
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
|
|||
|
|
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
|
|||
|
|
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
|
|||
|
|
ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
|
|||
|
|
Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
|
|||
|
|
wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
|
|||
|
|
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
|
|||
|
|
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
|
|||
|
|
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
|
|||
|
|
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
|
|||
|
|
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
|
|||
|
|
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
|
|||
|
|
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
|
|||
|
|
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
|
|||
|
|
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<a name="CreateRequestUri"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>6.2.1.
|
|||
|
|
URL Referencing the Request Object</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Client stores the Request Object resource either
|
|||
|
|
locally or remotely at a URL the Server can access.
|
|||
|
|
This URL is the Request URI, <tt>request_uri</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the Request Object includes requested values for Claims,
|
|||
|
|
it MUST NOT be revealed to anybody but the Authorization Server.
|
|||
|
|
As such, the <tt>request_uri</tt> MUST have
|
|||
|
|
appropriate entropy for its lifetime.
|
|||
|
|
It is RECOMMENDED that it be removed
|
|||
|
|
if it is known that it will not be used again
|
|||
|
|
or after a reasonable timeout
|
|||
|
|
unless access control measures are taken.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of a Request URI value
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> https://client.example.org/request.jwt#
|
|||
|
|
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="UseRequestUri"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.2.2"></a>
|
|||
|
|
|
|||
|
|
<h3>6.2.2.
|
|||
|
|
Request using the "request_uri" Request Parameter</h3>
|
|||
|
|
|
|||
|
|
<p>The Client sends the Authorization Request to the
|
|||
|
|
Authorization Endpoint.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example
|
|||
|
|
of an Authorization Request using the <tt>request_uri</tt> parameter
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> https://server.example.com/authorize?
|
|||
|
|
response_type=code%20id_token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt
|
|||
|
|
%23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
|
|||
|
|
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
|
|||
|
|
&scope=openid
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="GetRequestUri"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.2.3"></a>
|
|||
|
|
|
|||
|
|
<h3>6.2.3.
|
|||
|
|
Authorization Server Fetches Request Object</h3>
|
|||
|
|
|
|||
|
|
<p>Upon receipt of the Request, the Authorization Server MUST
|
|||
|
|
send an HTTP <tt>GET</tt> request to the <tt>request_uri</tt>
|
|||
|
|
to retrieve the referenced Request Object, unless it is already cached, and parse it
|
|||
|
|
to recreate the Authorization Request parameters.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Note that the RP SHOULD use a unique URI for each
|
|||
|
|
request utilizing distinct parameters, or otherwise
|
|||
|
|
prevent the Authorization Server from caching the <tt>request_uri</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example of this fetch
|
|||
|
|
process:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /request.jwt HTTP/1.1
|
|||
|
|
Host: client.example.org
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="RequestUriRationale"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.2.4"></a>
|
|||
|
|
|
|||
|
|
<h3>6.2.4.
|
|||
|
|
"request_uri" Rationale</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
There are several reasons that one might choose to use the
|
|||
|
|
<tt>request_uri</tt> parameter:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The set of request parameters can become large, and can exceed browser
|
|||
|
|
URI size limitations. Passing the request parameters by reference
|
|||
|
|
can solve this problem.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Passing a <tt>request_uri</tt> value, rather than
|
|||
|
|
a complete request by value, can reduce request latency.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Most requests for Claims from an RP are constant.
|
|||
|
|
The <tt>request_uri</tt> is a way of creating
|
|||
|
|
and sometimes also signing and encrypting a constant set of
|
|||
|
|
request parameters in advance.
|
|||
|
|
(The <tt>request_uri</tt> value becomes an "artifact"
|
|||
|
|
representing a particular fixed set of request parameters.)
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Pre-registering a fixed set of request parameters at Registration time
|
|||
|
|
enables OPs to cache and pre-validate the request parameters at
|
|||
|
|
Registration time, meaning they need not be retrieved at request time.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Pre-registering a fixed set of request parameters at
|
|||
|
|
Registration time enables OPs to vet the contents of
|
|||
|
|
the request from consumer protection and other points
|
|||
|
|
of views, either itself or by utilizing a third party.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="JWTRequestValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.3"></a>
|
|||
|
|
|
|||
|
|
<h3>6.3.
|
|||
|
|
Validating JWT-Based Requests</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When the <tt>request</tt> or
|
|||
|
|
<tt>request_uri</tt> Authorization Request parameters
|
|||
|
|
are used, additional steps must be performed to validate the
|
|||
|
|
Authentication Request beyond those specified in
|
|||
|
|
Sections <a class="info"
|
|||
|
|
href="#AuthRequestValidation">3.1.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ImplicitValidation">3.2.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>, or
|
|||
|
|
<a class="info"
|
|||
|
|
href="#HybridValidation">3.3.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>.
|
|||
|
|
These steps are to validate the JWT containing the Request Object
|
|||
|
|
and to validate the Request Object itself.
|
|||
|
|
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="EncryptedRequestObject"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>6.3.1.
|
|||
|
|
Encrypted Request Object</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the Authorization Server has advertised JWE encryption algorithms
|
|||
|
|
in the <tt>request_object_encryption_alg_values_supported</tt> and
|
|||
|
|
<tt>request_object_encryption_enc_values_supported</tt> elements of its
|
|||
|
|
Discovery document <a class="info" href="#OpenID.Discovery">[OpenID.Discovery]<span> (</span><span
|
|||
|
|
class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.</span><span>)</span></a>,
|
|||
|
|
or has supplied encryption algorithms by other means,
|
|||
|
|
these are used by the Client to encrypt the JWT.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST decrypt the JWT in accordance with
|
|||
|
|
the <a class="info" href="#JWE">JSON Web
|
|||
|
|
Encryption<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE] specification.
|
|||
|
|
The result MAY be either a signed or unsigned (plaintext) Request Object.
|
|||
|
|
In the former case, signature validation MUST be performed
|
|||
|
|
as defined in <a class="info" href="#SignedRequestObject">Section 6.3.2<span> (</span><span
|
|||
|
|
class="info">Signed Request Object</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST return an error if decryption fails.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SignedRequestObject"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.3.2"></a>
|
|||
|
|
|
|||
|
|
<h3>6.3.2.
|
|||
|
|
Signed Request Object</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To perform Signature Validation,
|
|||
|
|
the <tt>alg</tt> Header Parameter in the JOSE Header MUST match the value
|
|||
|
|
of the <tt>request_object_signing_alg</tt> set during
|
|||
|
|
Client Registration <a class="info" href="#OpenID.Registration">[OpenID.Registration]<span> (</span><span
|
|||
|
|
class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
or a value that was
|
|||
|
|
pre-registered by other means.
|
|||
|
|
The signature MUST be validated against the appropriate key
|
|||
|
|
for that <tt>client_id</tt>
|
|||
|
|
and algorithm.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST return an error if signature validation fails.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RequestParameterValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.6.3.3"></a>
|
|||
|
|
|
|||
|
|
<h3>6.3.3.
|
|||
|
|
Request Parameter Assembly and Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST assemble
|
|||
|
|
the set of Authorization Request parameters to be used
|
|||
|
|
from the Request Object value
|
|||
|
|
and the OAuth 2.0 Authorization Request parameters
|
|||
|
|
(minus the <tt>request</tt> or
|
|||
|
|
<tt>request_uri</tt> parameters).
|
|||
|
|
If the same parameter exists both in
|
|||
|
|
the Request Object and the OAuth Authorization Request parameters,
|
|||
|
|
the parameter in the Request Object is used.
|
|||
|
|
Using the assembled set of Authorization Request parameters,
|
|||
|
|
the Authorization Server then validates the request
|
|||
|
|
the normal manner for the flow being used, as specified in
|
|||
|
|
Sections <a class="info"
|
|||
|
|
href="#AuthRequestValidation">3.1.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>,
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ImplicitValidation">3.2.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>, or
|
|||
|
|
<a class="info"
|
|||
|
|
href="#HybridValidation">3.3.2.2<span> (</span><span
|
|||
|
|
class="info">Authentication Request Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SelfIssued"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7"></a>
|
|||
|
|
|
|||
|
|
<h3>7.
|
|||
|
|
Self-Issued OpenID Provider</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect supports Self-Issued OpenID Providers -
|
|||
|
|
personal, self-hosted OPs that issue self-signed ID Tokens.
|
|||
|
|
Self-Issued OPs use the special Issuer Identifier
|
|||
|
|
<tt>https://self-issued.me</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The messages used to communicate with Self-Issued OPs are
|
|||
|
|
mostly the same as those used to communicate with other OPs.
|
|||
|
|
Specifications for the few additional parameters used and
|
|||
|
|
for the values of some parameters in the Self-Issued case
|
|||
|
|
are defined in this section.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SelfIssuedDiscovery"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.1"></a>
|
|||
|
|
|
|||
|
|
<h3>7.1.
|
|||
|
|
Self-Issued OpenID Provider Discovery</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If the input identifier for the discovery process
|
|||
|
|
contains the domain self-issued.me, dynamic discovery is not performed.
|
|||
|
|
Instead, then the following static configuration values are used:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"authorization_endpoint":
|
|||
|
|
"openid:",
|
|||
|
|
"issuer":
|
|||
|
|
"https://self-issued.me",
|
|||
|
|
"scopes_supported":
|
|||
|
|
["openid", "profile", "email", "address", "phone"],
|
|||
|
|
"response_types_supported":
|
|||
|
|
["id_token"],
|
|||
|
|
"subject_types_supported":
|
|||
|
|
["pairwise"],
|
|||
|
|
"id_token_signing_alg_values_supported":
|
|||
|
|
["RS256"],
|
|||
|
|
"request_object_signing_alg_values_supported":
|
|||
|
|
["none", "RS256"]
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
NOTE: The OpenID Foundation plans to host the OpenID Provider site
|
|||
|
|
<tt>https://self-issued.me/</tt>,
|
|||
|
|
including its WebFinger service, so that performing discovery on it
|
|||
|
|
returns the above static discovery information, enabling RPs
|
|||
|
|
to not need any special processing for discovery of the Self-Issued OP.
|
|||
|
|
This site will be hosted on an experimental basis.
|
|||
|
|
Production implementations should not take a dependency upon it
|
|||
|
|
without a subsequent commitment by the OpenID Foundation
|
|||
|
|
to host the site in a manner intended for production use.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SelfIssuedRegistration"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.2"></a>
|
|||
|
|
|
|||
|
|
<h3>7.2.
|
|||
|
|
Self-Issued OpenID Provider Registration</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using a Self-Issued OP, registration is not required.
|
|||
|
|
The Client can proceed without registration as if it had
|
|||
|
|
registered with the OP and obtained the following
|
|||
|
|
Client Registration Response:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>client_id</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
<tt>redirect_uri</tt> value of the Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>client_secret_expires_at</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
0
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
NOTE: The OpenID Foundation plans to host the (stateless) endpoint
|
|||
|
|
<tt>https://self-issued.me/registration/1.0/</tt>
|
|||
|
|
that returns the response above, enabling RPs to not need
|
|||
|
|
any special processing for registration with the Self-Issued OP.
|
|||
|
|
This site will be hosted on an experimental basis.
|
|||
|
|
Production implementations should not take a dependency upon it
|
|||
|
|
without a subsequent commitment by the OpenID Foundation
|
|||
|
|
to host the site in a manner intended for production use.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RegistrationParameter"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>7.2.1.
|
|||
|
|
Providing Information with the "registration" Request Parameter</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following Authorization Request parameter
|
|||
|
|
to enable Clients to provide additional registration information to
|
|||
|
|
Self-Issued OpenID Providers:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>registration</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
This parameter is used by the Client to provide information about itself
|
|||
|
|
to a Self-Issued OP that would normally be provided to an OP during
|
|||
|
|
Dynamic Client Registration.
|
|||
|
|
The value is a JSON object containing Client metadata values,
|
|||
|
|
as defined in Section 2.1 of the
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID
|
|||
|
|
Connect Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration]
|
|||
|
|
specification.
|
|||
|
|
The <tt>registration</tt> parameter SHOULD NOT be used
|
|||
|
|
when the OP is not a Self-Issued OP.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
None of this information is REQUIRED by Self-Issued OPs,
|
|||
|
|
so the use of this parameter is OPTIONAL.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>registration</tt> parameter value is represented
|
|||
|
|
in an OAuth 2.0 request as a UTF-8 encoded JSON object
|
|||
|
|
(which ends up being form-urlencoded when passed as an OAuth parameter).
|
|||
|
|
When used in a Request Object value, per <a class="info"
|
|||
|
|
href="#RequestObject">Section 6.1<span> (</span><span
|
|||
|
|
class="info">Passing a Request Object by Value</span><span>)</span></a>,
|
|||
|
|
the JSON object is used as the value of the
|
|||
|
|
<tt>registration</tt> member.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Registration parameters that would typically be used in requests
|
|||
|
|
to Self-Issued OPs are
|
|||
|
|
<tt>policy_uri</tt>,
|
|||
|
|
<tt>tos_uri</tt>, and
|
|||
|
|
<tt>logo_uri</tt>.
|
|||
|
|
If the Client uses more than one Redirection URI, the
|
|||
|
|
<tt>redirect_uris</tt>
|
|||
|
|
parameter would be used to register them.
|
|||
|
|
Finally, if the Client is requesting encrypted responses, it would typically use the
|
|||
|
|
<tt>jwks_uri</tt>,
|
|||
|
|
<tt>id_token_encrypted_response_alg</tt> and
|
|||
|
|
<tt>id_token_encrypted_response_enc</tt> parameters.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SelfIssuedRequest"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.3"></a>
|
|||
|
|
|
|||
|
|
<h3>7.3.
|
|||
|
|
Self-Issued OpenID Provider Request</h3>
|
|||
|
|
|
|||
|
|
<p>The Client sends the Authentication Request to the Authorization Endpoint
|
|||
|
|
with the following parameters:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>scope</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
<tt>scope</tt> parameter value,
|
|||
|
|
as specified in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>response_type</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED. Constant string value <tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>client_id</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Client ID value for the Client, which in this case contains the
|
|||
|
|
<tt>redirect_uri</tt> value of the Client.
|
|||
|
|
Since the Client's
|
|||
|
|
<tt>redirect_uri</tt> URI value is communicated
|
|||
|
|
as the Client ID,
|
|||
|
|
a <tt>redirect_uri</tt> parameter
|
|||
|
|
is NOT REQUIRED to also be included in the request.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>id_token_hint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
<tt>id_token_hint</tt> parameter value,
|
|||
|
|
as specified in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
If the ID Token is encrypted to the Self-Issued OP,
|
|||
|
|
the <tt>sub</tt> (subject)
|
|||
|
|
of the signed ID Token MUST be sent as the
|
|||
|
|
<tt>kid</tt> (Key ID) of the JWE.
|
|||
|
|
Encrypting content to Self-Issued OPs is currently only supported when
|
|||
|
|
the OP's JWK key type is <tt>RSA</tt> and the encryption
|
|||
|
|
algorithm used is <tt>RSA1_5</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>claims</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
<tt>claims</tt> parameter value,
|
|||
|
|
as specified in <a class="info" href="#ClaimsParameter">Section 5.5<span> (</span><span
|
|||
|
|
class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>registration</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
This parameter is used by the Client to provide information about itself
|
|||
|
|
to a Self-Issued OP that would normally be provided to an OP during
|
|||
|
|
Dynamic Client Registration,
|
|||
|
|
as specified in <a class="info"
|
|||
|
|
href="#RegistrationParameter">Section 7.2.1<span> (</span><span
|
|||
|
|
class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>request</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Request Object value, as specified in <a class="info"
|
|||
|
|
href="#RequestObject">Section 6.1<span> (</span><span
|
|||
|
|
class="info">Passing a Request Object by Value</span><span>)</span></a>.
|
|||
|
|
The Request Object MAY be encrypted to the Self-Issued OP by the Client.
|
|||
|
|
In this case, the <tt>sub</tt> (subject) of
|
|||
|
|
a previously issued ID Token for this Client
|
|||
|
|
MUST be sent as the <tt>kid</tt> (Key ID) of the JWE.
|
|||
|
|
Encrypting content to Self-Issued OPs is currently only supported when
|
|||
|
|
the OP's JWK key type is <tt>RSA</tt> and the encryption
|
|||
|
|
algorithm used is <tt>RSA1_5</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Other parameters MAY be sent.
|
|||
|
|
Note that all Claims are returned in the ID Token.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The entire URL MUST NOT exceed 2048 ASCII characters.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example
|
|||
|
|
HTTP 302 redirect response by the Client, which triggers
|
|||
|
|
the User Agent to make an Authentication Request
|
|||
|
|
to the Self-Issued OpenID Provider
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> HTTP/1.1 302 Found
|
|||
|
|
Location: openid://?
|
|||
|
|
response_type=id_token
|
|||
|
|
&client_id=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
|
|||
|
|
client.example.org%2Flogo.png%22%7D
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="SelfIssuedResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.4"></a>
|
|||
|
|
|
|||
|
|
<h3>7.4.
|
|||
|
|
Self-Issued OpenID Provider Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following Claim
|
|||
|
|
for use in Self-Issued OpenID Provider Responses:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>sub_jwk</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Public key used to check the signature of an ID Token
|
|||
|
|
issued by a Self-Issued OpenID Provider,
|
|||
|
|
as specified in <a class="info" href="#SelfIssued">Section 7<span> (</span><span
|
|||
|
|
class="info">Self-Issued OpenID Provider</span><span>)</span></a>.
|
|||
|
|
The key is a bare key in JWK <a class="info"
|
|||
|
|
href="#JWK">[JWK]<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Key (JWK),” July 2014.</span><span>)</span></a> format
|
|||
|
|
(not an X.509 certificate value).
|
|||
|
|
The <tt>sub_jwk</tt> value is a JSON object.
|
|||
|
|
Use of the <tt>sub_jwk</tt> Claim
|
|||
|
|
is NOT RECOMMENDED when the OP is not Self-Issued.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Self-Issued OpenID Provider response is the same as the normal Implicit Flow
|
|||
|
|
response with the following refinements. Since it is an Implicit Flow
|
|||
|
|
response, the response parameters will be returned in the URL fragment component,
|
|||
|
|
unless a different Response Mode was specified.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The <tt>iss</tt> (issuer) Claim Value is
|
|||
|
|
<tt>https://self-issued.me</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
A <tt>sub_jwk</tt> Claim is present, with its value being
|
|||
|
|
the public key used to check the signature of the ID Token.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The <tt>sub</tt> (subject) Claim
|
|||
|
|
value is the base64url encoded representation of
|
|||
|
|
the thumbprint of
|
|||
|
|
the key in the <tt>sub_jwk</tt> Claim.
|
|||
|
|
This thumbprint value is computed as
|
|||
|
|
the SHA-256 hash of
|
|||
|
|
the octets of the UTF-8 representation of
|
|||
|
|
a JWK constructed containing only the REQUIRED members to represent the key,
|
|||
|
|
with the member names sorted into lexicographic order,
|
|||
|
|
and with no white space or line breaks.
|
|||
|
|
For instance,
|
|||
|
|
when the <tt>kty</tt> value is
|
|||
|
|
<tt>RSA</tt>, the member names
|
|||
|
|
<tt>e</tt>,
|
|||
|
|
<tt>kty</tt>, and
|
|||
|
|
<tt>n</tt>
|
|||
|
|
are the ones present in the constructed JWK used
|
|||
|
|
in the thumbprint computation and appear in that order;
|
|||
|
|
when the <tt>kty</tt> value is
|
|||
|
|
<tt>EC</tt>, the member names
|
|||
|
|
<tt>crv</tt>,
|
|||
|
|
<tt>kty</tt>,
|
|||
|
|
<tt>x</tt>, and
|
|||
|
|
<tt>y</tt>
|
|||
|
|
are present in that order.
|
|||
|
|
Note that this thumbprint calculation is the same as that defined in
|
|||
|
|
the JWK Thumbprint <a class="info" href="#JWK.Thumbprint">[JWK.Thumbprint]<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Key (JWK) Thumbprint,” July 2014.</span><span>)</span></a>
|
|||
|
|
specification.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
No Access Token is returned for accessing a UserInfo Endpoint,
|
|||
|
|
so all Claims returned MUST be in the ID Token.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SelfIssuedValidation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.7.5"></a>
|
|||
|
|
|
|||
|
|
<h3>7.5.
|
|||
|
|
Self-Issued ID Token Validation</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To validate the ID Token received, the Client MUST do the following:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate that the value of the <tt>iss</tt> (issuer) Claim is <tt>https://self-isued.me</tt>.
|
|||
|
|
If <tt>iss</tt> contains a different value,
|
|||
|
|
the ID Token is not Self-Issued, and instead
|
|||
|
|
it MUST be validated according to
|
|||
|
|
<a class="info" href="#IDTokenValidation">Section 3.1.3.7<span> (</span><span
|
|||
|
|
class="info">ID Token Validation</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate that the
|
|||
|
|
<tt>aud</tt> (audience) Claim
|
|||
|
|
contains the value of the <tt>redirect_uri</tt>
|
|||
|
|
that the Client sent in the Authentication Request as an audience.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate the signature of the ID Token according to
|
|||
|
|
<a class="info" href="#JWS">JWS<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] using the algorithm specified in the
|
|||
|
|
<tt>alg</tt> Header Parameter of the JOSE Header,
|
|||
|
|
using the key in the <tt>sub_jwk</tt> Claim;
|
|||
|
|
the key is a bare key in JWK format
|
|||
|
|
(not an X.509 certificate value).
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The <tt>alg</tt> value SHOULD be the default of
|
|||
|
|
<tt>RS256</tt>.
|
|||
|
|
It MAY also be <tt>ES256</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Client MUST validate that the <tt>sub</tt> Claim
|
|||
|
|
value is the base64url encoded representation of
|
|||
|
|
the thumbprint of
|
|||
|
|
the key in the <tt>sub_jwk</tt> Claim,
|
|||
|
|
as specified in <a class="info" href="#SelfIssuedResponse">Section 7.4<span> (</span><span
|
|||
|
|
class="info">Self-Issued OpenID Provider Response</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The current time MUST be before the time represented by the
|
|||
|
|
<tt>exp</tt> Claim
|
|||
|
|
(possibly allowing for some small leeway to account for clock skew).
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The <tt>iat</tt> Claim can be used to reject tokens that
|
|||
|
|
were issued too far away from the current time, limiting the amount of
|
|||
|
|
time that nonces need to be stored to prevent attacks.
|
|||
|
|
The acceptable range is Client specific.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If a nonce value was sent in the Authentication Request,
|
|||
|
|
a <tt>nonce</tt> Claim MUST be present
|
|||
|
|
and its value checked to verify that
|
|||
|
|
it is the same value as the one that was sent in the Authentication Request.
|
|||
|
|
The Client SHOULD check the <tt>nonce</tt> value
|
|||
|
|
for replay attacks.
|
|||
|
|
The precise method for detecting replay attacks is Client specific.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is a non-normative example of a base64url decoded
|
|||
|
|
Self-Issued ID Token
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "https://self-issued.me",
|
|||
|
|
"sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
|
|||
|
|
"aud": "https://client.example.org/cb",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"sub_jwk": {
|
|||
|
|
"kty":"RSA",
|
|||
|
|
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
|
|||
|
|
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
|
|||
|
|
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
|
|||
|
|
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
|
|||
|
|
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
|
|||
|
|
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
|
|||
|
|
"e":"AQAB"
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="SubjectIDTypes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.8"></a>
|
|||
|
|
|
|||
|
|
<h3>8.
|
|||
|
|
Subject Identifier Types</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
A Subject Identifier is a locally unique and never
|
|||
|
|
reassigned identifier within the Issuer for the End-User,
|
|||
|
|
which is intended to be consumed by the Client.
|
|||
|
|
Two Subject Identifier types are defined by this specification:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>public</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
This provides the same <tt>sub</tt> (subject) value to all Clients.
|
|||
|
|
It is the default if the provider has no <tt>subject_types_supported</tt>
|
|||
|
|
element in its discovery document.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>pairwise</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
This provides a different <tt>sub</tt>
|
|||
|
|
value to each Client, so as not to enable Clients to correlate
|
|||
|
|
the End-User's activities without permission.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OpenID Provider's Discovery document SHOULD list
|
|||
|
|
its supported Subject Identifier types in the
|
|||
|
|
<tt>subject_types_supported</tt> element.
|
|||
|
|
If there is more than one type listed in the array, the Client MAY elect to
|
|||
|
|
provide its preferred identifier type using the
|
|||
|
|
<tt>subject_type</tt> parameter during Registration.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="PairwiseAlg"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.8.1"></a>
|
|||
|
|
|
|||
|
|
<h3>8.1.
|
|||
|
|
Pairwise Identifier Algorithm</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When pairwise Subject Identifiers are used,
|
|||
|
|
the OpenID Provider MUST calculate a unique
|
|||
|
|
<tt>sub</tt> (subject) value for each
|
|||
|
|
Sector Identifier. The Subject Identifier value MUST NOT be reversible
|
|||
|
|
by any party other than the OpenID Provider.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Providers that use pairwise <tt>sub</tt> values
|
|||
|
|
and support
|
|||
|
|
<a class="info" href="#OpenID.Registration">Dynamic Client
|
|||
|
|
Registration<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration]
|
|||
|
|
SHOULD use the <tt>sector_identifier_uri</tt> parameter.
|
|||
|
|
It provides a way for a group of websites under common administrative
|
|||
|
|
control to have consistent pairwise <tt>sub</tt>
|
|||
|
|
values independent of the individual domain names.
|
|||
|
|
It also provides a way for Clients to change
|
|||
|
|
<tt>redirect_uri</tt> domains without having to
|
|||
|
|
reregister all of their users.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>If the Client has not provided a value for
|
|||
|
|
<tt>sector_identifier_uri</tt> in
|
|||
|
|
<a class="info" href="#OpenID.Registration">Dynamic Client
|
|||
|
|
Registration<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration],
|
|||
|
|
the Sector Identifier
|
|||
|
|
used for pairwise identifier calculation is the host component
|
|||
|
|
of the registered <tt>redirect_uri</tt>.
|
|||
|
|
If there are multiple hostnames in the registered
|
|||
|
|
<tt>redirect_uris</tt>, the Client MUST register a
|
|||
|
|
<tt>sector_identifier_uri</tt>.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>When a <tt>sector_identifier_uri</tt>
|
|||
|
|
is provided, the host component of that URL is used as
|
|||
|
|
the Sector Identifier for the pairwise identifier calculation.
|
|||
|
|
The value of the <tt>sector_identifier_uri</tt>
|
|||
|
|
MUST be a URL using the <tt>https</tt> scheme that points to
|
|||
|
|
a JSON file containing an array of
|
|||
|
|
<tt>redirect_uri</tt> values.
|
|||
|
|
The values of the registered <tt>redirect_uris</tt>
|
|||
|
|
MUST be included in the elements of the array.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Any algorithm with the following properties
|
|||
|
|
can be used by OpenID Providers to
|
|||
|
|
calculate pairwise Subject Identifiers:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
The Subject Identifier value MUST NOT be reversible
|
|||
|
|
by any party other than the OpenID Provider.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Distinct Sector Identifier values MUST result in
|
|||
|
|
distinct Subject Identifier values.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The algorithm MUST be deterministic.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Three example methods are:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
The Sector Identifier can be concatenated with a local account ID and a salt
|
|||
|
|
value that is kept secret by the Provider. The concatenated string is then
|
|||
|
|
hashed using an appropriate algorithm.
|
|||
|
|
<br>
|
|||
|
|
<br>
|
|||
|
|
|
|||
|
|
Calculate <tt>sub</tt> = SHA-256 ( sector_identifier || local_account_id || salt ).
|
|||
|
|
<br>
|
|||
|
|
<br>
|
|||
|
|
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Sector Identifier can be concatenated with a local account ID and a salt
|
|||
|
|
value that is kept secret by the Provider. The concatenated string is then
|
|||
|
|
encrypted using an appropriate algorithm.
|
|||
|
|
<br>
|
|||
|
|
<br>
|
|||
|
|
|
|||
|
|
Calculate <tt>sub</tt> = AES-128 ( sector_identifier || local_account_id || salt ).
|
|||
|
|
<br>
|
|||
|
|
<br>
|
|||
|
|
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
The Issuer creates a Globally Unique Identifier (GUID) for the pair of
|
|||
|
|
Sector Identifier and local account ID and stores this value.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ClientAuthentication"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.9"></a>
|
|||
|
|
|
|||
|
|
<h3>9.
|
|||
|
|
Client Authentication</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This section defines a set of Client Authentication methods
|
|||
|
|
that are used by Clients to authenticate to the Authorization Server
|
|||
|
|
when using the Token Endpoint.
|
|||
|
|
During Client Registration, the RP (Client) MAY register a Client Authentication method.
|
|||
|
|
If no method is registered, the default method is <tt>client_secret_basic</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>These Client Authentication methods are:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>client_secret_basic</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Clients that have received a <tt>client_secret</tt> value
|
|||
|
|
from the Authorization Server authenticate with the Authorization Server
|
|||
|
|
in accordance with Section 2.3.1 of <a class="info"
|
|||
|
|
href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749] using the HTTP Basic authentication scheme.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>client_secret_post</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Clients that have received a <tt>client_secret</tt> value
|
|||
|
|
from the Authorization Server, authenticate with the Authorization Server
|
|||
|
|
in accordance with Section 2.3.1 of <a class="info"
|
|||
|
|
href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749] by including the Client Credentials in the request body.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>client_secret_jwt</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Clients that have received a <tt>client_secret</tt> value
|
|||
|
|
from the Authorization Server create a JWT using an
|
|||
|
|
HMAC SHA algorithm, such as HMAC SHA-256.
|
|||
|
|
The HMAC (Hash-based Message Authentication Code) is calculated using
|
|||
|
|
the octets of the UTF-8 representation of
|
|||
|
|
the <tt>client_secret</tt> as the shared key.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The Client authenticates in accordance with <a class="info"
|
|||
|
|
href="#OAuth.JWT">JSON
|
|||
|
|
Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span
|
|||
|
|
class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.JWT] and
|
|||
|
|
<a class="info" href="#OAuth.Assertions">Assertion
|
|||
|
|
Framework for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Assertions].
|
|||
|
|
The JWT MUST contain the following REQUIRED Claim Values and
|
|||
|
|
MAY contain the following OPTIONAL Claim Values:
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>iss</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Issuer.
|
|||
|
|
This MUST contain the <tt>client_id</tt> of the OAuth Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>sub</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Subject.
|
|||
|
|
This MUST contain the <tt>client_id</tt> of the OAuth Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>aud</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Audience.
|
|||
|
|
The <tt>aud</tt> (audience) Claim.
|
|||
|
|
Value that identifies the Authorization Server as an intended audience.
|
|||
|
|
The Authorization Server MUST verify that it is an intended audience
|
|||
|
|
for the token.
|
|||
|
|
The Audience SHOULD be the URL of the
|
|||
|
|
Authorization Server's Token Endpoint.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>jti</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
JWT ID.
|
|||
|
|
A unique identifier for the token,
|
|||
|
|
which can be used to prevent reuse of the token.
|
|||
|
|
These tokens MUST only be used once,
|
|||
|
|
unless conditions for reuse were negotiated between the parties;
|
|||
|
|
any such negotiation is beyond the scope of this specification.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>exp</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Expiration time on or after which the ID Token MUST NOT be
|
|||
|
|
accepted for processing.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>iat</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Time at which the JWT was issued.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The JWT MAY contain other Claims.
|
|||
|
|
Any Claims used that are not understood MUST be ignored.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>The authentication token MUST be sent as the value of the
|
|||
|
|
<a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
|
|||
|
|
class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
<tt>client_assertion</tt> parameter.
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>The value of the
|
|||
|
|
<a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
|
|||
|
|
class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
<tt>client_assertion_type</tt> parameter
|
|||
|
|
MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
|
|||
|
|
per <a class="info" href="#OAuth.JWT">[OAuth.JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>.
|
|||
|
|
</dd>
|
|||
|
|
<dt>private_key_jwt</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Clients that have registered a public key sign a JWT using
|
|||
|
|
that key.
|
|||
|
|
The Client authenticates in accordance with <a class="info"
|
|||
|
|
href="#OAuth.JWT">JSON
|
|||
|
|
Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span
|
|||
|
|
class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.JWT] and
|
|||
|
|
<a class="info" href="#OAuth.Assertions">Assertion
|
|||
|
|
Framework for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Assertions].
|
|||
|
|
The JWT MUST contain the following REQUIRED Claim Values and
|
|||
|
|
MAY contain the following OPTIONAL Claim Values:
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>iss</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Issuer.
|
|||
|
|
This MUST contain the <tt>client_id</tt> of the OAuth Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>sub</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Subject.
|
|||
|
|
This MUST contain the <tt>client_id</tt> of the OAuth Client.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>aud</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Audience.
|
|||
|
|
The <tt>aud</tt> (audience) Claim.
|
|||
|
|
Value that identifies the Authorization Server as an intended audience.
|
|||
|
|
The Authorization Server MUST verify that it is an intended audience
|
|||
|
|
for the token.
|
|||
|
|
The Audience SHOULD be the URL of the
|
|||
|
|
Authorization Server's Token Endpoint.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>jti</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
JWT ID.
|
|||
|
|
A unique identifier for the token,
|
|||
|
|
which can be used to prevent reuse of the token.
|
|||
|
|
These tokens MUST only be used once,
|
|||
|
|
unless conditions for reuse were negotiated between the parties;
|
|||
|
|
any such negotiation is beyond the scope of this specification.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>exp</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
REQUIRED.
|
|||
|
|
Expiration time on or after which the ID Token MUST NOT be
|
|||
|
|
accepted for processing.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>iat</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL.
|
|||
|
|
Time at which the JWT was issued.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
The JWT MAY contain other Claims.
|
|||
|
|
Any Claims used that are not understood MUST be ignored.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>The authentication token MUST be sent as the value of the
|
|||
|
|
<a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
|
|||
|
|
class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
<tt>client_assertion</tt> parameter.
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>The value of the
|
|||
|
|
<a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
|
|||
|
|
class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
<tt>client_assertion_type</tt> parameter
|
|||
|
|
MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
|
|||
|
|
per <a class="info" href="#OAuth.JWT">[OAuth.JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>.
|
|||
|
|
</dd>
|
|||
|
|
<dt></dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
For example
|
|||
|
|
(with line wraps within values for display purposes 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=i1WsRn1uB1&
|
|||
|
|
client_id=s6BhdRkqt3&
|
|||
|
|
client_assertion_type=
|
|||
|
|
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
|
|||
|
|
client_assertion=PHNhbWxwOl ... ZT
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>none</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The Client does not authenticate itself at the Token Endpoint,
|
|||
|
|
either because it uses only the Implicit Flow (and so does not use the Token Endpoint)
|
|||
|
|
or because it is a Public Client with no Client Secret or other authentication mechanism.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SigEnc"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.10"></a>
|
|||
|
|
|
|||
|
|
<h3>10.
|
|||
|
|
Signatures and Encryption</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Depending on the transport through which the messages are sent, the
|
|||
|
|
integrity of the message might not be guaranteed and the originator of the
|
|||
|
|
message might not be authenticated. To mitigate these risks,
|
|||
|
|
ID Token, UserInfo Response, Request Object,
|
|||
|
|
and Client Authentication JWT values can utilize
|
|||
|
|
<a class="info" href="#JWS">JSON Web Signature
|
|||
|
|
(JWS)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS] to sign their contents.
|
|||
|
|
To achieve message confidentiality, these values can also use
|
|||
|
|
<a class="info" href="#JWE">JSON Web Encryption
|
|||
|
|
(JWE)<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE] to encrypt their contents.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When the message is both signed and encrypted, it MUST be
|
|||
|
|
signed first and then encrypted, per <a class="info"
|
|||
|
|
href="#SigningOrder">Section 16.14<span> (</span><span
|
|||
|
|
class="info">Signing and Encryption Order</span><span>)</span></a>,
|
|||
|
|
with the result being a Nested JWT, as specified in <a class="info"
|
|||
|
|
href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
Note that all JWE encryption methods perform integrity checking.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OP advertises its supported signing and encryption algorithms
|
|||
|
|
in its Discovery document,
|
|||
|
|
or may supply this information by other means.
|
|||
|
|
The RP declares its required signing and encryption algorithms
|
|||
|
|
in its Dynamic Registration request,
|
|||
|
|
or may communicate this information by other means.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OP advertises its public keys
|
|||
|
|
via its Discovery document,
|
|||
|
|
or may supply this information by other means.
|
|||
|
|
The RP declares its public keys
|
|||
|
|
via its Dynamic Registration request,
|
|||
|
|
or may communicate this information by other means.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Signing"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.10.1"></a>
|
|||
|
|
|
|||
|
|
<h3>10.1.
|
|||
|
|
Signing</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The signing party MUST select a signature algorithm
|
|||
|
|
based on the algorithms supported by the recipient.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Asymmetric Signatures</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
When using RSA or ECDSA Signatures,
|
|||
|
|
the <tt>alg</tt> Header Parameter value
|
|||
|
|
of the JOSE Header MUST be set to an appropriate algorithm
|
|||
|
|
as defined in <a class="info" href="#JWA">JSON Web
|
|||
|
|
Algorithms<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a> [JWA].
|
|||
|
|
The private key used to sign the content MUST be associated with
|
|||
|
|
a public key used for signature verification published by the sender
|
|||
|
|
in its JWK Set document.
|
|||
|
|
If there are multiple keys in the referenced JWK Set document, a
|
|||
|
|
<tt>kid</tt> value MUST be provided in the JOSE Header.
|
|||
|
|
The key usage of the respective keys MUST support signing.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Symmetric Signatures</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
When using MAC-based signatures,
|
|||
|
|
the <tt>alg</tt> Header Parameter value
|
|||
|
|
of the JOSE Header MUST be set to a MAC algorithm,
|
|||
|
|
as defined in <a class="info" href="#JWA">JSON Web
|
|||
|
|
Algorithms<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a> [JWA].
|
|||
|
|
The MAC key used is
|
|||
|
|
the octets of the UTF-8 representation of
|
|||
|
|
the <tt>client_secret</tt> value.
|
|||
|
|
See <a class="info" href="#SymmetricKeyEntropy">Section 16.19<span> (</span><span
|
|||
|
|
class="info">Symmetric Key Entropy</span><span>)</span></a> for a discussion of
|
|||
|
|
entropy requirements for <tt>client_secret</tt> values.
|
|||
|
|
Symmetric signatures MUST NOT be used by public (non-confidential) Clients
|
|||
|
|
because of their inability to keep secrets.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
See <a class="info" href="#NeedForSignedRequests">Section 16.20<span> (</span><span
|
|||
|
|
class="info">Need for Signed Requests</span><span>)</span></a> for Security Considerations
|
|||
|
|
about the need for signed requests.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RotateSigKeys"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.10.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>10.1.1.
|
|||
|
|
Rotation of Asymmetric Signing Keys</h3>
|
|||
|
|
|
|||
|
|
<p>Rotation of signing keys can be accomplished with the following approach. The signer publishes
|
|||
|
|
its keys in a JWK Set at its <tt>jwks_uri</tt> location
|
|||
|
|
and includes the <tt>kid</tt> of the
|
|||
|
|
signing key in the JOSE Header of each message
|
|||
|
|
to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over
|
|||
|
|
by periodically adding new keys to the JWK Set at the <tt>jwks_uri</tt> location.
|
|||
|
|
The signer can begin using a new key at its
|
|||
|
|
discretion and signals the change to the verifier using the <tt>kid</tt> value.
|
|||
|
|
The verifier knows to go back to the <tt>jwks_uri</tt> location
|
|||
|
|
to re-retrieve the keys when it sees an unfamiliar
|
|||
|
|
<tt>kid</tt> value. The JWK Set document at the <tt>jwks_uri</tt>
|
|||
|
|
SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a
|
|||
|
|
smooth transition.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Encryption"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.10.2"></a>
|
|||
|
|
|
|||
|
|
<h3>10.2.
|
|||
|
|
Encryption</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The encrypting party MUST select an encryption algorithm
|
|||
|
|
based on the algorithms supported by the recipient.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Asymmetric Encryption: RSA</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The public key to which the content was encrypted MUST be
|
|||
|
|
a public key used for encryption published by the recipient
|
|||
|
|
in its JWK Set document.
|
|||
|
|
If there are multiple keys in the referenced JWK Set document, a
|
|||
|
|
<tt>kid</tt> value MUST be provided in the JOSE Header.
|
|||
|
|
Use the supported RSA encryption algorithm to encrypt a random
|
|||
|
|
Content Encryption Key to be used for encrypting
|
|||
|
|
the signed JWT.
|
|||
|
|
The key usage of the respective keys MUST include encryption.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Asymmetric Encryption: Elliptic Curve</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
Create an ephemeral Elliptic Curve public key for the <tt>epk</tt>
|
|||
|
|
element of the JOSE Header.
|
|||
|
|
The other public key used for the key agreement computation MUST be
|
|||
|
|
a public key published by the recipient
|
|||
|
|
in its JWK Set document.
|
|||
|
|
If there are multiple keys in the referenced JWK Set document, a
|
|||
|
|
<tt>kid</tt> value MUST be provided in the JOSE Header.
|
|||
|
|
Use the ECDH-ES algorithm to agree upon a
|
|||
|
|
Content Encryption Key to be used for encrypting
|
|||
|
|
the signed JWT.
|
|||
|
|
The key usage of the respective keys MUST support encryption.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Symmetric Encryption</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
The symmetric encryption key is derived from the
|
|||
|
|
<tt>client_secret</tt> value by
|
|||
|
|
using a left truncated SHA-2 hash of
|
|||
|
|
the octets of the UTF-8 representation of
|
|||
|
|
the <tt>client_secret</tt>.
|
|||
|
|
For keys of 256 or fewer bits, SHA-256 is used;
|
|||
|
|
for keys of 257-384 bits, SHA-384 is used;
|
|||
|
|
for keys of 385-512 bits, SHA-512 is used.
|
|||
|
|
The hash value MUST be left truncated to the appropriate bit length
|
|||
|
|
for the AES key wrapping or direct encryption algorithm used,
|
|||
|
|
for instance, truncating the SHA-256 hash
|
|||
|
|
to 128 bits for <tt>A128KW</tt>.
|
|||
|
|
If a symmetric key with greater than 512 bits is needed, a different method
|
|||
|
|
of deriving the key from the <tt>client_secret</tt>
|
|||
|
|
would have to be defined by an extension.
|
|||
|
|
Symmetric encryption MUST NOT be used by public (non-confidential) Clients
|
|||
|
|
because of their inability to keep secrets.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
See <a class="info" href="#NeedForEncryptedRequests">Section 16.21<span> (</span><span
|
|||
|
|
class="info">Need for Encrypted Requests</span><span>)</span></a> for Security Considerations
|
|||
|
|
about the need for encrypted requests.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RotateEncKeys"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.10.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>10.2.1.
|
|||
|
|
Rotation of Asymmetric Encryption Keys</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Rotating encryption keys necessarily uses a different process than the one for signing keys because
|
|||
|
|
the encrypting party starts the process and thus cannot rely on
|
|||
|
|
a change in <tt>kid</tt> as a signal
|
|||
|
|
that keys need to change. The encrypting party
|
|||
|
|
still uses the <tt>kid</tt> Header Parameter in the JWE
|
|||
|
|
to tell the decrypting party which private key to use to decrypt, however, the encrypting party
|
|||
|
|
needs to first select the most appropriate key from those provided in the JWK Set at
|
|||
|
|
the recipient's <tt>jwks_uri</tt> location.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To rotate keys, the decrypting party can publish new keys
|
|||
|
|
at its <tt>jwks_uri</tt> location
|
|||
|
|
and remove from the JWK Set those that are being decommissioned.
|
|||
|
|
The <tt>jwks_uri</tt> SHOULD include a <tt>Cache-Control</tt>
|
|||
|
|
header in the response that contains a <tt>max-age</tt> directive,
|
|||
|
|
as 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],
|
|||
|
|
which enables the encrypting party to safely cache the JWK Set and not have to re-retrieve
|
|||
|
|
the document for every encryption event. The decrypting party SHOULD remove decommissioned keys
|
|||
|
|
from the JWK Set referenced by <tt>jwks_uri</tt>
|
|||
|
|
but retain them internally for some reasonable
|
|||
|
|
period of time, coordinated with the cache duration, to facilitate a smooth transition between keys
|
|||
|
|
by allowing the encrypting party some time to obtain the new keys. The cache duration SHOULD also
|
|||
|
|
be coordinated with the issuance of new signing keys, as described in <a class="info"
|
|||
|
|
href="#RotateSigKeys">Section 10.1.1<span> (</span><span
|
|||
|
|
class="info">Rotation of Asymmetric Signing Keys</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="OfflineAccess"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.11"></a>
|
|||
|
|
|
|||
|
|
<h3>11.
|
|||
|
|
Offline Access</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect defines the following <tt>scope</tt> value
|
|||
|
|
to request offline access:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>offline_access</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPTIONAL. This scope value requests
|
|||
|
|
that an OAuth 2.0 Refresh Token be issued that can be used to
|
|||
|
|
obtain an Access Token that grants access to the End-User's
|
|||
|
|
UserInfo Endpoint even when the End-User is not present (not logged in).
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When offline access is requested, a <tt>prompt</tt>
|
|||
|
|
parameter value of <tt>consent</tt> MUST be used
|
|||
|
|
unless other conditions for processing the request permitting offline access
|
|||
|
|
to the requested resources are in place.
|
|||
|
|
The OP MUST always obtain consent to returning a Refresh Token
|
|||
|
|
that enables offline access to the requested resources.
|
|||
|
|
A previously saved user consent is not always sufficient to grant offline access.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Upon receipt of a scope parameter containing the
|
|||
|
|
<tt>offline_access</tt> value, the Authorization Server:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
MUST ensure that the prompt parameter contains
|
|||
|
|
<tt>consent</tt>
|
|||
|
|
unless other conditions for processing the request permitting offline access
|
|||
|
|
to the requested resources are in place;
|
|||
|
|
unless one or both of these conditions are fulfilled, then
|
|||
|
|
it MUST ignore the <tt>offline_access</tt> request,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
MUST ignore the <tt>offline_access</tt> request
|
|||
|
|
unless the Client is using a <tt>response_type</tt>
|
|||
|
|
value that would result in an Authorization Code being returned,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
MUST explicitly receive or have consent for all Clients when
|
|||
|
|
the registered <tt>application_type</tt>
|
|||
|
|
is <tt>web</tt>,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
SHOULD explicitly receive or have consent for all Clients when
|
|||
|
|
the registered <tt>application_type</tt>
|
|||
|
|
is <tt>native</tt>.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
The use of Refresh Tokens is not exclusive to the
|
|||
|
|
<tt>offline_access</tt> use case.
|
|||
|
|
The Authorization Server MAY grant Refresh Tokens
|
|||
|
|
in other contexts that are beyond the scope of this specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RefreshTokens"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.12"></a>
|
|||
|
|
|
|||
|
|
<h3>12.
|
|||
|
|
Using Refresh Tokens</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
A request to the Token Endpoint can also use a Refresh Token
|
|||
|
|
by using the <tt>grant_type</tt> value
|
|||
|
|
<tt>refresh_token</tt>,
|
|||
|
|
as described in Section 6 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
This section defines the behaviors for OpenID Connect
|
|||
|
|
Authorization Servers when Refresh Tokens are used.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RefreshingAccessToken"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.12.1"></a>
|
|||
|
|
|
|||
|
|
<h3>12.1.
|
|||
|
|
Refresh Request</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To refresh an Access Token, the Client MUST
|
|||
|
|
authenticate to the Token Endpoint using the authentication method registered
|
|||
|
|
for its <tt>client_id</tt>, as documented in
|
|||
|
|
<a class="info"
|
|||
|
|
href="#ClientAuthentication">Section 9<span> (</span><span
|
|||
|
|
class="info">Client Authentication</span><span>)</span></a>.
|
|||
|
|
The Client sends the parameters via HTTP <tt>POST</tt>
|
|||
|
|
to the Token Endpoint using
|
|||
|
|
Form Serialization, per <a class="info"
|
|||
|
|
href="#FormSerialization">Section 13.2<span> (</span><span
|
|||
|
|
class="info">Form Serialization</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of a
|
|||
|
|
Refresh Request
|
|||
|
|
(with line wraps within values for display purposes 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
|
|||
|
|
|
|||
|
|
client_id=s6BhdRkqt3
|
|||
|
|
&client_secret=some_secret12345
|
|||
|
|
&grant_type=refresh_token
|
|||
|
|
&refresh_token=8xLOxBtZp8
|
|||
|
|
&scope=openid%20profile
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server MUST validate the Refresh Token,
|
|||
|
|
MUST verify that it was issued to the Client,
|
|||
|
|
and must verify that the Client successfully authenticated
|
|||
|
|
it has a Client Authentication method.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RefreshTokenResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.12.2"></a>
|
|||
|
|
|
|||
|
|
<h3>12.2.
|
|||
|
|
Successful Refresh Response</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Upon successful validation of the Refresh Token,
|
|||
|
|
the response body is the Token Response of <a class="info"
|
|||
|
|
href="#TokenResponse">Section 3.1.3.3<span> (</span><span
|
|||
|
|
class="info">Successful Token Response</span><span>)</span></a>
|
|||
|
|
except that it might not contain an <tt>id_token</tt>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If an ID Token is returned as a result of a token refresh request,
|
|||
|
|
the following requirements apply:
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
its <tt>iss</tt> Claim Value MUST be the same as
|
|||
|
|
in the ID Token issued when the original authentication occurred,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
its <tt>sub</tt> Claim Value MUST be the same as
|
|||
|
|
in the ID Token issued when the original authentication occurred,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
its <tt>iat</tt> Claim MUST represent
|
|||
|
|
the time that the new ID Token is issued,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
its <tt>aud</tt> Claim Value MUST be the same as
|
|||
|
|
in the ID Token issued when the original authentication occurred,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
if the ID Token contains an <tt>auth_time</tt> Claim,
|
|||
|
|
its value MUST represent the time of the original authentication - not
|
|||
|
|
the time that the new ID token is issued,
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
its <tt>azp</tt> Claim Value MUST be the same as
|
|||
|
|
in the ID Token issued when the original authentication occurred;
|
|||
|
|
if no <tt>azp</tt> Claim was present in the original
|
|||
|
|
ID Token, one MUST NOT be present in the new ID Token, and
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
otherwise, the same rules apply as apply when issuing an ID Token
|
|||
|
|
at the time of the original authentication.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of a
|
|||
|
|
Refresh Response:
|
|||
|
|
|
|||
|
|
</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": "TlBN45jURg",
|
|||
|
|
"token_type": "Bearer",
|
|||
|
|
"refresh_token": "9yNOxJtZa5",
|
|||
|
|
"expires_in": 3600
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="RefreshErrorResponse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.12.3"></a>
|
|||
|
|
|
|||
|
|
<h3>12.3.
|
|||
|
|
Refresh Error Response</h3>
|
|||
|
|
|
|||
|
|
<p>If the Refresh Request is invalid or unauthorized, the
|
|||
|
|
Authorization Server returns the
|
|||
|
|
Token Error Response as defined in Section 5.2 of <a class="info"
|
|||
|
|
href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
</p>
|
|||
|
|
<a name="Serializations"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.13"></a>
|
|||
|
|
|
|||
|
|
<h3>13.
|
|||
|
|
Serializations</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Messages are serialized using one of the following methods:
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Query String Serialization
|
|||
|
|
</li>
|
|||
|
|
<li>Form Serialization
|
|||
|
|
</li>
|
|||
|
|
<li>JSON Serialization
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
This section describes the syntax of these serialization methods;
|
|||
|
|
other sections describe when they can and must be used.
|
|||
|
|
Note that not all methods can be used for all messages.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="QuerySerialization"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.13.1"></a>
|
|||
|
|
|
|||
|
|
<h3>13.1.
|
|||
|
|
Query String Serialization</h3>
|
|||
|
|
|
|||
|
|
<p>In order to serialize the parameters using the Query String
|
|||
|
|
Serialization, the Client constructs the string by adding the
|
|||
|
|
parameters and values to the query component of a URL using the <tt>application/x-www-form-urlencoded</tt> format as
|
|||
|
|
defined by <a class="info" href="#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<span> (</span><span
|
|||
|
|
class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
|
|||
|
|
Query String Serialization is typically used in
|
|||
|
|
HTTP <tt>GET</tt> requests.
|
|||
|
|
The same serialization method is also used when adding
|
|||
|
|
parameters to the fragment component of a URL.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of this serialization
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code
|
|||
|
|
&scope=openid
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="FormSerialization"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.13.2"></a>
|
|||
|
|
|
|||
|
|
<h3>13.2.
|
|||
|
|
Form Serialization</h3>
|
|||
|
|
|
|||
|
|
<p>Parameters and their values are Form Serialized by adding the
|
|||
|
|
parameter names and values to the entity body of the HTTP request using
|
|||
|
|
the <tt>application/x-www-form-urlencoded</tt> format
|
|||
|
|
as defined by <a class="info" href="#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<span> (</span><span
|
|||
|
|
class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
|
|||
|
|
Form Serialization is typically used in HTTP <tt>POST</tt> requests.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of this serialization
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> POST /authorize HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
Content-Type: application/x-www-form-urlencoded
|
|||
|
|
|
|||
|
|
response_type=code
|
|||
|
|
&scope=openid
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="JSONSerialization"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.13.3"></a>
|
|||
|
|
|
|||
|
|
<h3>13.3.
|
|||
|
|
JSON Serialization</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The parameters are serialized into a JSON object structure by adding each
|
|||
|
|
parameter at the highest structure level. Parameter names and string
|
|||
|
|
values are represented as JSON strings.
|
|||
|
|
Numerical values are represented as JSON numbers.
|
|||
|
|
Boolean values are represented as JSON booleans.
|
|||
|
|
Omitted parameters and parameters with no value SHOULD be omitted
|
|||
|
|
from the object and not represented by
|
|||
|
|
a JSON <tt>null</tt> value, unless otherwise specified.
|
|||
|
|
A parameter MAY have a JSON object or a JSON array as its value.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following is a non-normative example of this serialization:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"access_token": "SlAV32hkKG",
|
|||
|
|
"token_type": "Bearer",
|
|||
|
|
"expires_in": 3600,
|
|||
|
|
"refresh_token": "8xLOxBtZp8"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="StringOps"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.14"></a>
|
|||
|
|
|
|||
|
|
<h3>14.
|
|||
|
|
String Operations</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Processing some OpenID Connect messages requires comparing
|
|||
|
|
values in the messages to known values. For example, the Claim
|
|||
|
|
Names returned by the UserInfo Endpoint might be compared to
|
|||
|
|
specific Claim Names such as <tt>sub</tt>. Comparing Unicode strings,
|
|||
|
|
however, has significant security implications.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Therefore, comparisons between JSON strings and other Unicode
|
|||
|
|
strings MUST be performed as specified below:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>
|
|||
|
|
Remove any JSON applied escaping to produce an array of
|
|||
|
|
Unicode code points.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Unicode Normalization <a class="info"
|
|||
|
|
href="#USA15">[USA15]<span> (</span><span
|
|||
|
|
class="info">Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.</span><span>)</span></a>
|
|||
|
|
MUST NOT
|
|||
|
|
be applied at any point to either the JSON string or to
|
|||
|
|
the string it is to be compared against.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Comparisons between the two strings MUST be performed as a
|
|||
|
|
Unicode code point to code point equality comparison.
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In several places, this specification uses space delimited
|
|||
|
|
lists of strings. In all such cases, a single ASCII space
|
|||
|
|
character (0x20) MUST be used as the delimiter.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplementationConsiderations"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15"></a>
|
|||
|
|
|
|||
|
|
<h3>15.
|
|||
|
|
Implementation Considerations</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification defines features used by both Relying Parties and
|
|||
|
|
OpenID Providers.
|
|||
|
|
It is expected that some OpenID Providers will require
|
|||
|
|
static, out-of-band configuration of RPs using them,
|
|||
|
|
whereas others will support dynamic usage by RPs without
|
|||
|
|
a pre-established relationship between them.
|
|||
|
|
For that reason, the mandatory-to-implement features for OPs
|
|||
|
|
are listed below in two groups:
|
|||
|
|
the first for all OPs and the second for "Dynamic" OpenID Providers.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ServerMTI"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.1"></a>
|
|||
|
|
|
|||
|
|
<h3>15.1.
|
|||
|
|
Mandatory to Implement Features for All OpenID Providers</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
All OpenID Providers MUST implement the following features defined in this specification.
|
|||
|
|
This list augments the set of features that are already listed elsewhere
|
|||
|
|
as being "REQUIRED" or are described with a "MUST",
|
|||
|
|
and so is not, by itself, a comprehensive set of implementation requirements for OPs.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Signing ID Tokens with RSA SHA-256</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm
|
|||
|
|
(an <tt>alg</tt> value of
|
|||
|
|
<tt>RS256</tt>),
|
|||
|
|
unless the OP only supports returning ID Tokens from the Token Endpoint
|
|||
|
|
(as is the case for the Authorization Code Flow)
|
|||
|
|
and only allows Clients to register specifying
|
|||
|
|
<tt>none</tt> as the requested ID Token signing algorithm.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Prompt Parameter</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support the <tt>prompt</tt> parameter,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>, including the specified
|
|||
|
|
user interface behaviors such as <tt>none</tt>
|
|||
|
|
and <tt>login</tt>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Display Parameter</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support the <tt>display</tt> parameter,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
(Note that the minimum level of support required for this parameter is
|
|||
|
|
simply that its use must not result in an error.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Preferred Locales</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support requests for preferred languages and scripts
|
|||
|
|
for the user interface and for Claims via the
|
|||
|
|
<tt>ui_locales</tt> and
|
|||
|
|
<tt>claims_locales</tt> request parameters,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
(Note that the minimum level of support required for these parameters is
|
|||
|
|
simply to have their use not result in errors.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Time</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support returning the time at which the End-User authenticated
|
|||
|
|
via the <tt>auth_time</tt> Claim, when requested,
|
|||
|
|
as defined in <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Maximum Authentication Age</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support enforcing a maximum authentication age
|
|||
|
|
via the <tt>max_age</tt> parameter,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Authentication Context Class Reference</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
OPs MUST support requests for specific
|
|||
|
|
Authentication Context Class Reference values
|
|||
|
|
via the <tt>acr_values</tt> parameter,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
(Note that the minimum level of support required for this parameter is
|
|||
|
|
simply to have its use not result in an error.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="DynamicMTI"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.2"></a>
|
|||
|
|
|
|||
|
|
<h3>15.2.
|
|||
|
|
Mandatory to Implement Features for Dynamic OpenID Providers</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In addition to the features listed above,
|
|||
|
|
OpenID Providers supporting dynamic establishment of relationships with RPs
|
|||
|
|
that they do not have a pre-configured relationship with
|
|||
|
|
MUST also implement the following features defined in this and related specifications.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<dl>
|
|||
|
|
<dt>Response Types</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
These OpenID Providers MUST support the
|
|||
|
|
<tt>id_token</tt> Response Type and
|
|||
|
|
all that are not Self-Issued OPs MUST also support the
|
|||
|
|
<tt>code</tt> and
|
|||
|
|
<tt>id_token token</tt> Response Types.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Discovery</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
These OPs MUST support Discovery,
|
|||
|
|
as defined in
|
|||
|
|
<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,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Discovery].
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Dynamic Registration</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
These OPs MUST support Dynamic Client Registration,
|
|||
|
|
as defined in
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID
|
|||
|
|
Connect Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration].
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>UserInfo Endpoint</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint,
|
|||
|
|
as defined in <a class="info" href="#UserInfo">Section 5.3<span> (</span><span
|
|||
|
|
class="info">UserInfo Endpoint</span><span>)</span></a>.
|
|||
|
|
(Self-Issued OPs do not issue Access Tokens.)
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Public Keys Published as Bare Keys</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
These OPs MUST publish their public keys as bare JWK keys
|
|||
|
|
(which MAY also be accompanied by X.509 representations of those keys).
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
<dt>Request URI</dt>
|
|||
|
|
<dd>
|
|||
|
|
|
|||
|
|
These OPs MUST support requests made using a Request Object value
|
|||
|
|
that is retrieved from a Request URI that is provided
|
|||
|
|
with the <tt>request_uri</tt> parameter,
|
|||
|
|
as defined in <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</dd>
|
|||
|
|
</dl>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="DiscoReg"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.3"></a>
|
|||
|
|
|
|||
|
|
<h3>15.3.
|
|||
|
|
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 might 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,” November 2014.</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., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration]
|
|||
|
|
specifications.
|
|||
|
|
</p>
|
|||
|
|
<a name="RPMTI"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.4"></a>
|
|||
|
|
|
|||
|
|
<h3>15.4.
|
|||
|
|
Mandatory to Implement Features for Relying Parties</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In general, it is up to Relying Parties which features they use
|
|||
|
|
when interacting with OpenID Providers.
|
|||
|
|
However, some choices are dictated by the nature of their OAuth Client,
|
|||
|
|
such as whether it is a Confidential Client, capable of keeping secrets,
|
|||
|
|
in which case the Authorization Code Flow may be appropriate,
|
|||
|
|
or whether it is a Public Client, for instance, a
|
|||
|
|
User Agent Based Application or a statically registered Native Application,
|
|||
|
|
in which case the Implicit Flow may be appropriate.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using OpenID Connect features, those listed as being
|
|||
|
|
"REQUIRED" or are described with a "MUST" are
|
|||
|
|
mandatory to implement, when used by a Relying Party.
|
|||
|
|
Likewise, those features that are described as "OPTIONAL"
|
|||
|
|
need not be used or supported unless they provide value
|
|||
|
|
in the particular application context.
|
|||
|
|
Finally, when interacting with OpenID Providers that support Discovery,
|
|||
|
|
the OP's Discovery document can be used to dynamically determine
|
|||
|
|
which OP features are available for use by the RP.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplementationNotes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.5"></a>
|
|||
|
|
|
|||
|
|
<h3>15.5.
|
|||
|
|
Implementation Notes</h3>
|
|||
|
|
|
|||
|
|
<a name="CodeNotes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.5.1"></a>
|
|||
|
|
|
|||
|
|
<h3>15.5.1.
|
|||
|
|
Authorization Code Implementation Notes</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When using the Authorization Code or Hybrid flows,
|
|||
|
|
an ID Token is returned from the Token Endpoint
|
|||
|
|
in response to a Token Request using an Authorization Code.
|
|||
|
|
Some implementations may choose to encode state about
|
|||
|
|
the ID Token to be returned in the Authorization Code value.
|
|||
|
|
Others may use the Authorization Code value
|
|||
|
|
as an index into a database storing this state.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="NonceNotes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.5.2"></a>
|
|||
|
|
|
|||
|
|
<h3>15.5.2.
|
|||
|
|
Nonce Implementation Notes</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>nonce</tt> parameter value needs to include
|
|||
|
|
per-session state and be unguessable to attackers.
|
|||
|
|
One method to achieve this for Web Server Clients is to store a cryptographically random value
|
|||
|
|
as an HttpOnly session cookie and use a cryptographic hash of the value
|
|||
|
|
as the <tt>nonce</tt> parameter.
|
|||
|
|
In that case, the <tt>nonce</tt> in the returned
|
|||
|
|
ID Token is compared to the hash of the session cookie
|
|||
|
|
to detect ID Token replay by third parties.
|
|||
|
|
A related method applicable to JavaScript Clients is to store the cryptographically random value
|
|||
|
|
in HTML5 local storage and use a cryptographic hash of this value.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="FragmentNotes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.5.3"></a>
|
|||
|
|
|
|||
|
|
<h3>15.5.3.
|
|||
|
|
Redirect URI Fragment Handling Implementation Notes</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When response parameters are returned in the Redirection URI fragment value,
|
|||
|
|
the Client needs to have the User Agent parse the fragment encoded values
|
|||
|
|
and pass them to on to the Client's processing logic for consumption.
|
|||
|
|
User Agents that have direct access to cryptographic APIs may be able to be
|
|||
|
|
self-contained, for instance, with all Client code being written in JavaScript.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
However, if the Client does not run entirely in the User Agent,
|
|||
|
|
one way to achieve this
|
|||
|
|
is to post them to a Web Server Client for validation.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>The following is an example of a JavaScript file that a Client might host at its
|
|||
|
|
<tt>redirect_uri</tt>. This is loaded by the redirect from
|
|||
|
|
the Authorization Server. The fragment component is parsed and then sent by <tt>POST</tt> to a URI
|
|||
|
|
that will validate and use the information received.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Following is a non-normative example of a
|
|||
|
|
Redirect URI response:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /cb HTTP/1.1
|
|||
|
|
Host: client.example.org
|
|||
|
|
|
|||
|
|
HTTP/1.1 200 OK
|
|||
|
|
Content-Type: text/html
|
|||
|
|
|
|||
|
|
<script type="text/javascript">
|
|||
|
|
|
|||
|
|
// First, parse the query string
|
|||
|
|
var params = {}, postBody = location.hash.substring(1),
|
|||
|
|
regex = /([^&=]+)=([^&]*)/g, m;
|
|||
|
|
while (m = regex.exec(postBody)) {
|
|||
|
|
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
// And send the token over to the server
|
|||
|
|
var req = new XMLHttpRequest();
|
|||
|
|
// using POST so query isn't logged
|
|||
|
|
req.open('POST', 'https://' + window.location.host +
|
|||
|
|
'/catch_response', true);
|
|||
|
|
req.setRequestHeader('Content-Type',
|
|||
|
|
'application/x-www-form-urlencoded');
|
|||
|
|
|
|||
|
|
req.onreadystatechange = function (e) {
|
|||
|
|
if (req.readyState == 4) {
|
|||
|
|
if (req.status == 200) {
|
|||
|
|
// If the response from the POST is 200 OK, perform a redirect
|
|||
|
|
window.location = 'https://'
|
|||
|
|
+ window.location.host + '/redirect_after_login'
|
|||
|
|
}
|
|||
|
|
// if the OAuth response is invalid, generate an error message
|
|||
|
|
else if (req.status == 400) {
|
|||
|
|
alert('There was an error processing the token')
|
|||
|
|
} else {
|
|||
|
|
alert('Something other than 200 was returned')
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
};
|
|||
|
|
req.send(postBody);
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="CompatibilityNotes"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.6"></a>
|
|||
|
|
|
|||
|
|
<h3>15.6.
|
|||
|
|
Compatibility Notes</h3>
|
|||
|
|
|
|||
|
|
<a name="PreFinalIETFSpecs"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.6.1"></a>
|
|||
|
|
|
|||
|
|
<h3>15.6.1.
|
|||
|
|
Pre-Final IETF Specifications</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Implementers should be aware that
|
|||
|
|
this specification uses several IETF specifications that are
|
|||
|
|
not yet final specifications. Those specifications are:
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li><a class="info" href="#JWT">JSON Web Token (JWT) draft
|
|||
|
|
-25<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#JWS">JSON Web Signature (JWS) draft
|
|||
|
|
-31<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWS]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#JWE">JSON Web Encryption (JWE) draft
|
|||
|
|
-31<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWE]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#JWK">JSON Web Key (JWK) draft
|
|||
|
|
-31<span> (</span><span class="info">Jones, M., “JSON Web Key (JWK),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWK]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#JWA">JSON Web Algorithms draft
|
|||
|
|
-31<span> (</span><span
|
|||
|
|
class="info">Jones, M., “JSON Web Algorithms (JWA),” July 2014.</span><span>)</span></a> [JWA]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#OAuth.Assertions">Assertion Framework
|
|||
|
|
for OAuth 2.0 Client Authentication and Authorization Grants draft -17<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Assertions]
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#OAuth.JWT">JSON Web Token (JWT)
|
|||
|
|
Profile for OAuth 2.0 Client Authentication and Authorization Grants draft -10<span> (</span><span class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.JWT]
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
While every effort will be made to prevent breaking
|
|||
|
|
changes to these specifications, should they occur,
|
|||
|
|
OpenID Connect implementations should continue to use the
|
|||
|
|
specifically referenced draft versions above in preference
|
|||
|
|
to the final versions, unless using a possible future
|
|||
|
|
OpenID Connect profile or specification that
|
|||
|
|
updates some or all of these references.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="GoogleIss"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.6.2"></a>
|
|||
|
|
|
|||
|
|
<h3>15.6.2.
|
|||
|
|
Google "iss" Value</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Implementers may want to be aware that,
|
|||
|
|
as of the time of this writing,
|
|||
|
|
Google's deployed OpenID Connect implementation issues ID Tokens
|
|||
|
|
that omit the required <tt>https://</tt>
|
|||
|
|
scheme prefix from the <tt>iss</tt> (issuer)
|
|||
|
|
Claim Value.
|
|||
|
|
Relying Party implementations wishing to work with Google
|
|||
|
|
will therefore need to have code to work around this,
|
|||
|
|
until such time as their implementation is updated.
|
|||
|
|
Any such workaround code should be written in a manner
|
|||
|
|
that will not break at such point Google adds the
|
|||
|
|
missing prefix to their issuer values.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RelatedSpecs"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.15.7"></a>
|
|||
|
|
|
|||
|
|
<h3>15.7.
|
|||
|
|
Related Specifications and Implementer's Guides</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
These related OPTIONAL specifications MAY be used in
|
|||
|
|
combination with this specification to provide additional functionality:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
<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,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Discovery] -
|
|||
|
|
Defines how Relying Parties dynamically discover information about OpenID Providers
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
<a class="info" href="#OpenID.Registration">OpenID Connect
|
|||
|
|
Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Registration] -
|
|||
|
|
Defines how Relying Parties dynamically register with OpenID Providers
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
<a class="info" href="#OpenID.Session">OpenID Connect
|
|||
|
|
Session Management 1.0<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,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Session] -
|
|||
|
|
Defines how to manage OpenID Connect sessions, including logout functionality
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
<a class="info" href="#OAuth.Post">OAuth 2.0 Form Post
|
|||
|
|
Response Mode<span> (</span><span class="info">Jones, M. and B. Campbell, “OAuth 2.0 Form Post Response Mode,” February 2014.</span><span>)</span></a>
|
|||
|
|
[OAuth.Post] -
|
|||
|
|
Defines how to return OAuth 2.0 Authorization Response parameters
|
|||
|
|
(including OpenID Connect Authentication Response parameters)
|
|||
|
|
using HTML form values that are auto-submitted by the User Agent
|
|||
|
|
using HTTP <tt>POST</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
These implementer's guides are intended to serve as self-contained references
|
|||
|
|
for implementers of basic Web-based Relying Parties:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li><a class="info" href="#OpenID.Basic">OpenID Connect Basic
|
|||
|
|
Client Implementer's Guide 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Basic] -
|
|||
|
|
Implementer's guide containing a subset of this specification
|
|||
|
|
that is intended for use by basic
|
|||
|
|
Web-based Relying Parties using the
|
|||
|
|
OAuth Authorization Code Flow
|
|||
|
|
</li>
|
|||
|
|
<li><a class="info" href="#OpenID.Implicit">OpenID Connect
|
|||
|
|
Implicit Client Implementer's Guide 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Implicit Client Implementer's Guide 1.0,” November 2014.</span><span>)</span></a>
|
|||
|
|
[OpenID.Implicit] -
|
|||
|
|
Implementer's guide containing a subset of this specification
|
|||
|
|
that is intended for use by basic
|
|||
|
|
Web-based Relying Parties using the
|
|||
|
|
OAuth Implicit Flow
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Security"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16"></a>
|
|||
|
|
|
|||
|
|
<h3>16.
|
|||
|
|
Security Considerations</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification references the security considerations defined in
|
|||
|
|
Section 10 of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749], and
|
|||
|
|
Section 5 of <a class="info" href="#RFC6750">OAuth 2.0 Bearer
|
|||
|
|
Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6750].
|
|||
|
|
Furthermore, the <a class="info" href="#RFC6819">OAuth 2.0
|
|||
|
|
Threat Model and Security
|
|||
|
|
Considerations<span> (</span><span class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a>
|
|||
|
|
[RFC6819] specification provides an extensive list of threats and controls
|
|||
|
|
that apply to this specification as well,
|
|||
|
|
given that it is based upon OAuth 2.0.
|
|||
|
|
<a class="info" href="#ISO29115">ISO/IEC
|
|||
|
|
29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.</span><span>)</span></a>
|
|||
|
|
[ISO29115]
|
|||
|
|
also provides threats and controls that
|
|||
|
|
implementers need to take into account.
|
|||
|
|
Implementers are highly advised to
|
|||
|
|
read these references in detail and apply the countermeasures described therein.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In addition, the following list of attack vectors and remedies are
|
|||
|
|
also considered.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="RequestDisclosure"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.1"></a>
|
|||
|
|
|
|||
|
|
<h3>16.1.
|
|||
|
|
Request Disclosure</h3>
|
|||
|
|
|
|||
|
|
<p>If appropriate measures are not taken, a request might be disclosed to
|
|||
|
|
an attacker, posing security and privacy threats.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>In addition to what is stated in Section 5.1.1 of <a class="info"
|
|||
|
|
href="#RFC6819">[RFC6819]<span> (</span><span
|
|||
|
|
class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a>,
|
|||
|
|
this standard provides a way to provide the confidentiality of the request
|
|||
|
|
end to end through the
|
|||
|
|
use of <tt>request</tt> or <tt>request_uri</tt>
|
|||
|
|
parameters, where the content of the <tt>request</tt>
|
|||
|
|
is an encrypted JWT with the appropriate key and cipher.
|
|||
|
|
This protects even against a compromised User Agent
|
|||
|
|
in the case of indirect request.
|
|||
|
|
</p>
|
|||
|
|
<a name="ServerMasquerading"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.2"></a>
|
|||
|
|
|
|||
|
|
<h3>16.2.
|
|||
|
|
Server Masquerading</h3>
|
|||
|
|
|
|||
|
|
<p>A malicious Server might masquerade as the legitimate server
|
|||
|
|
using various means. To detect such an attack, the Client needs to authenticate
|
|||
|
|
the server.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>In addition to what is stated in Section 5.1.2 of <a class="info"
|
|||
|
|
href="#RFC6819">[RFC6819]<span> (</span><span
|
|||
|
|
class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a>,
|
|||
|
|
this standard provides a way to authenticate the Server through either the
|
|||
|
|
use of Signed or Encrypted JWTs
|
|||
|
|
with an appropriate key and cipher.
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenManufacture"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.3"></a>
|
|||
|
|
|
|||
|
|
<h3>16.3.
|
|||
|
|
Token Manufacture/Modification</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
An Attacker might generate a bogus token or modify the token contents
|
|||
|
|
(such as Claims values or the signature)
|
|||
|
|
of an existing parseable token, causing the RP to grant
|
|||
|
|
inappropriate access to the Client. For example, an Attacker might modify
|
|||
|
|
the parseable token to extend the validity period; a Client might modify the
|
|||
|
|
parseable token to have access to information that they should not be able to view.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>There are two ways to mitigate this attack:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>The token can be digitally signed by the OP. The Relying
|
|||
|
|
Party SHOULD validate the digital signature to verify that it was
|
|||
|
|
issued by a legitimate OP.
|
|||
|
|
</li>
|
|||
|
|
<li>The token can be sent over a protected channel such as TLS.
|
|||
|
|
See <a class="info" href="#TLSRequirements">Section 16.17<span> (</span><span
|
|||
|
|
class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.
|
|||
|
|
In this specification, the token is always sent over a TLS protected channel.
|
|||
|
|
Note however, that this measure is only a defense against third party attackers
|
|||
|
|
and is not applicable to the case where the Client is the attacker.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="AccessTokenDisclosure"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.4"></a>
|
|||
|
|
|
|||
|
|
<h3>16.4.
|
|||
|
|
Access Token Disclosure</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Access Tokens are credentials used to access Protected
|
|||
|
|
Resources, as defined in Section 1.4 of
|
|||
|
|
<a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749]. Access Tokens represent
|
|||
|
|
an End-User's authorization and MUST NOT be exposed to
|
|||
|
|
unauthorized parties.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ResponseDisclosure"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.5"></a>
|
|||
|
|
|
|||
|
|
<h3>16.5.
|
|||
|
|
Server Response Disclosure</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The server response might contain authentication data and Claims
|
|||
|
|
that include sensitive Client information. Disclosure of the
|
|||
|
|
response contents can make the Client vulnerable to other types of
|
|||
|
|
attacks.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The server response disclosure can be mitigated in the following two
|
|||
|
|
ways:
|
|||
|
|
</p>
|
|||
|
|
<ol class="text">
|
|||
|
|
<li>Using the <tt>code</tt> Response Type.
|
|||
|
|
The response is sent over a TLS protected
|
|||
|
|
channel, where the Client is authenticated by the
|
|||
|
|
<tt>client_id</tt> and
|
|||
|
|
<tt>client_secret</tt>.
|
|||
|
|
</li>
|
|||
|
|
<li>For other Response Types,
|
|||
|
|
the signed response can be encrypted with the Client's
|
|||
|
|
public key or a shared secret as an encrypted JWT
|
|||
|
|
with an appropriate key and cipher.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ServerResponseRepudiation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.6"></a>
|
|||
|
|
|
|||
|
|
<h3>16.6.
|
|||
|
|
Server Response Repudiation</h3>
|
|||
|
|
|
|||
|
|
<p>A response might be repudiated by the server if the proper mechanisms are not in place.
|
|||
|
|
For example, if a Server does not digitally sign a response, the Server can claim that it was not
|
|||
|
|
generated through the services of the Server.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>To mitigate this threat, the response MAY be digitally signed by
|
|||
|
|
the Server using a key that supports non-repudiation. The Client SHOULD validate
|
|||
|
|
the digital signature to verify that it was issued by a legitimate
|
|||
|
|
Server and its integrity is intact.
|
|||
|
|
</p>
|
|||
|
|
<a name="RequestRepudation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.7"></a>
|
|||
|
|
|
|||
|
|
<h3>16.7.
|
|||
|
|
Request Repudiation</h3>
|
|||
|
|
|
|||
|
|
<p>Since it is possible for a
|
|||
|
|
compromised or malicious Client to send a request to the wrong party,
|
|||
|
|
a Client that was authenticated
|
|||
|
|
using only a bearer token can repudiate any transaction.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>To mitigate this threat, the Server MAY require that the
|
|||
|
|
request be digitally signed by
|
|||
|
|
the Client using a key that supports non-repudiation.
|
|||
|
|
The Server SHOULD validate
|
|||
|
|
the digital signature to verify that it was issued by a legitimate
|
|||
|
|
Client and the integrity is intact.
|
|||
|
|
</p>
|
|||
|
|
<a name="AccessTokenRedirect"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.8"></a>
|
|||
|
|
|
|||
|
|
<h3>16.8.
|
|||
|
|
Access Token Redirect</h3>
|
|||
|
|
|
|||
|
|
<p>An Attacker uses the Access Token generated for one resource to
|
|||
|
|
obtain access to a second resource.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>To mitigate this threat, the Access Token SHOULD be audience
|
|||
|
|
and scope restricted. One way of implementing it is to include
|
|||
|
|
the identifier of the resource for whom it was generated as audience.
|
|||
|
|
The resource verifies that
|
|||
|
|
incoming tokens include its identifier as the audience of the
|
|||
|
|
token.
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenReuse"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.9"></a>
|
|||
|
|
|
|||
|
|
<h3>16.9.
|
|||
|
|
Token Reuse</h3>
|
|||
|
|
|
|||
|
|
<p>An Attacker attempts to use a one-time use token such as
|
|||
|
|
an Authorization Code that has already
|
|||
|
|
been used once with the intended Resource.
|
|||
|
|
To mitigate this threat, the token SHOULD include a timestamp
|
|||
|
|
and a short validity lifetime.
|
|||
|
|
The Relying Party then checks the timestamp and lifetime values
|
|||
|
|
to ensure that the token is currently valid.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Alternatively, the server MAY record the state of the use of
|
|||
|
|
the token and check the status for each request.
|
|||
|
|
</p>
|
|||
|
|
<a name="AuthCodeCapture"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.10"></a>
|
|||
|
|
|
|||
|
|
<h3>16.10.
|
|||
|
|
Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)</h3>
|
|||
|
|
|
|||
|
|
<p>In addition to the attack patterns described in
|
|||
|
|
Section 4.4.1.1 of <a class="info"
|
|||
|
|
href="#RFC6819">[RFC6819]<span> (</span><span
|
|||
|
|
class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a>,
|
|||
|
|
an Authorization Code can be captured in the User Agent where the TLS
|
|||
|
|
session is terminated if the User Agent is infected by malware.
|
|||
|
|
However, capturing it is not useful as long as either
|
|||
|
|
Client Authentication or an encrypted response is used.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenSubstitution"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.11"></a>
|
|||
|
|
|
|||
|
|
<h3>16.11.
|
|||
|
|
Token Substitution</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Token Substitution is a class of attacks in which a malicious user
|
|||
|
|
swaps various tokens, including swapping an Authorization Code for
|
|||
|
|
a legitimate user with another token that the attacker has.
|
|||
|
|
One means of accomplishing this is for the attacker to copy
|
|||
|
|
a token out one session and use it in an HTTP message for
|
|||
|
|
a different session, which is easy to do when the token is
|
|||
|
|
available to the browser; this is known as the "cut and paste" attack.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Implicit Flow of <a class="info" href="#RFC6749">OAuth
|
|||
|
|
2.0<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749]
|
|||
|
|
is not designed to mitigate this risk. In Section 10.16,
|
|||
|
|
it normatively requires that any use of the authorization
|
|||
|
|
process as a form of delegated End-User authentication to the
|
|||
|
|
Client MUST NOT use the Implicit Flow without employing
|
|||
|
|
additional security mechanisms that enable the Client to
|
|||
|
|
determine whether the ID Token and Access Token were issued for its use.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In OpenID Connect, this is mitigated through mechanisms
|
|||
|
|
provided through the ID Token. The ID Token is a signed
|
|||
|
|
security token that provides Claims such as
|
|||
|
|
<tt>iss</tt> (issuer),
|
|||
|
|
<tt>sub</tt> (subject),
|
|||
|
|
<tt>aud</tt> (audience),
|
|||
|
|
<tt>azp</tt> (authorized party),
|
|||
|
|
<tt>at_hash</tt> (access token hash), and
|
|||
|
|
<tt>c_hash</tt> (code hash). Using the ID Token,
|
|||
|
|
the Client is capable of detecting the Token Substitution Attack.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The <tt>c_hash</tt> in the ID Token enables
|
|||
|
|
Clients to prevent Authorization Code substitution.
|
|||
|
|
The <tt>at_hash</tt> in the ID Token enables
|
|||
|
|
Clients to prevent Access Token substitution.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Also, a malicious user may attempt to impersonate a more
|
|||
|
|
privileged user by subverting the communication channel
|
|||
|
|
between the Authorization Endpoint and Client, or the Token Endpoint
|
|||
|
|
and Client, for example by swapping the Authorization Code
|
|||
|
|
or reordering the messages, to convince the Token Endpoint
|
|||
|
|
that the attacker's authorization grant corresponds to a grant
|
|||
|
|
sent on behalf of a more privileged user.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
For the HTTP binding defined by this specification, the
|
|||
|
|
responses to Token Requests are bound to the corresponding
|
|||
|
|
requests by message order in HTTP, as both the response
|
|||
|
|
containing the token and requests are protected by TLS, which
|
|||
|
|
will detect and prevent packet reordering.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When designing another binding of this specification to a
|
|||
|
|
protocol incapable of strongly binding Token Endpoint
|
|||
|
|
requests to responses, additional mechanisms to
|
|||
|
|
address this issue MUST be utilized. One such mechanism could
|
|||
|
|
be to include an ID Token with a <tt>c_hash</tt>
|
|||
|
|
Claim in the token request and response.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TimingAttack"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.12"></a>
|
|||
|
|
|
|||
|
|
<h3>16.12.
|
|||
|
|
Timing Attack</h3>
|
|||
|
|
|
|||
|
|
<p>A timing attack enables the attacker to
|
|||
|
|
obtain an unnecessary large amount of information through the elapsed time
|
|||
|
|
differences in the code paths taken by successful and unsuccessful decryption operations or
|
|||
|
|
successful and unsuccessful signature validation of a message.
|
|||
|
|
It can be used to reduce the effective key length of the
|
|||
|
|
cipher used.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Implementations SHOULD NOT terminate the validation process
|
|||
|
|
at the instant of the finding an error but SHOULD continue
|
|||
|
|
running until all the octets have been processed to avoid this attack.
|
|||
|
|
</p>
|
|||
|
|
<a name="OtherCryptoAttacks"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.13"></a>
|
|||
|
|
|
|||
|
|
<h3>16.13.
|
|||
|
|
Other Crypto Related Attacks</h3>
|
|||
|
|
|
|||
|
|
<p>There are various crypto related attacks possible depending on the
|
|||
|
|
method used for encryption and signature / integrity checking.
|
|||
|
|
Implementers need to consult the Security Considerations
|
|||
|
|
for the <a class="info" href="#JWT">JWT<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>
|
|||
|
|
[JWT] specification and
|
|||
|
|
specifications that it references
|
|||
|
|
to avoid the vulnerabilities
|
|||
|
|
identified in these specifications.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SigningOrder"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.14"></a>
|
|||
|
|
|
|||
|
|
<h3>16.14.
|
|||
|
|
Signing and Encryption Order</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Signatures over encrypted text are not considered valid
|
|||
|
|
in many jurisdictions.
|
|||
|
|
Therefore, for integrity and non-repudiation,
|
|||
|
|
this specification requires signing
|
|||
|
|
the plain text JSON Claims, when signing is performed.
|
|||
|
|
If both signing and encryption are desired, it is performed on
|
|||
|
|
the JWS containing the signed Claims,
|
|||
|
|
with the result being a Nested JWT, as specified in <a class="info"
|
|||
|
|
href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
Note that since all JWE encryption algorithms provide integrity protection,
|
|||
|
|
there is no need to separately sign the encrypted content.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="IssuerIdentifier"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.15"></a>
|
|||
|
|
|
|||
|
|
<h3>16.15.
|
|||
|
|
Issuer Identifier</h3>
|
|||
|
|
|
|||
|
|
<p>OpenID Connect supports multiple Issuers per Host and Port combination.
|
|||
|
|
The issuer returned by discovery MUST exactly match the value of
|
|||
|
|
<tt>iss</tt> in the ID Token.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
OpenID Connect treats the path component of any Issuer URI as
|
|||
|
|
being part of the Issuer Identifier. For instance, the subject
|
|||
|
|
"1234" with an Issuer Identifier of "https://example.com" is not
|
|||
|
|
equivalent to the subject "1234" with an Issuer Identifier of
|
|||
|
|
"https://example.com/sales".
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
It is RECOMMENDED that only a single Issuer per host be used.
|
|||
|
|
However, if a host supports multiple tenants,
|
|||
|
|
multiple Issuers for that host may be needed.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ImplicitFlowThreats"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.16"></a>
|
|||
|
|
|
|||
|
|
<h3>16.16.
|
|||
|
|
Implicit Flow Threats</h3>
|
|||
|
|
|
|||
|
|
<p>In the Implicit Flow, the Access Token is returned in the
|
|||
|
|
fragment component of the Client's <tt>redirect_uri</tt> through HTTPS, thus it is
|
|||
|
|
protected between the OP and the User Agent, and between the User Agent and the
|
|||
|
|
RP. The only place it can be captured is the User Agent where the
|
|||
|
|
TLS session is terminated, which is possible if the User Agent is
|
|||
|
|
infected by malware or under the control of a malicious party.
|
|||
|
|
</p>
|
|||
|
|
<a name="TLSRequirements"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.17"></a>
|
|||
|
|
|
|||
|
|
<h3>16.17.
|
|||
|
|
TLS Requirements</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Implementations MUST support TLS.
|
|||
|
|
Which version(s) ought to be implemented will vary over
|
|||
|
|
time, and depend on the widespread deployment and known
|
|||
|
|
security vulnerabilities at the time of implementation.
|
|||
|
|
At the time of this writing,
|
|||
|
|
TLS version 1.2 <a class="info" href="#RFC5246">[RFC5246]<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>
|
|||
|
|
is the most recent version, but has very limited actual
|
|||
|
|
deployment, and might not be readily available in
|
|||
|
|
implementation toolkits.
|
|||
|
|
TLS version 1.0 <a class="info" href="#RFC2246">[RFC2246]<span> (</span><span
|
|||
|
|
class="info">Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a>
|
|||
|
|
is the most widely deployed version, and will give the
|
|||
|
|
broadest interoperability.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
To protect against information disclosure and tampering,
|
|||
|
|
confidentiality protection MUST be applied using TLS
|
|||
|
|
with a ciphersuite that provides confidentiality and
|
|||
|
|
integrity protection.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Whenever TLS is used, a TLS server certificate check
|
|||
|
|
MUST be performed, per <a class="info" href="#RFC6125">RFC
|
|||
|
|
6125<span> (</span><span class="info">Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.</span><span>)</span></a>
|
|||
|
|
[RFC6125].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="TokenLifetime"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.18"></a>
|
|||
|
|
|
|||
|
|
<h3>16.18.
|
|||
|
|
Lifetimes of Access Tokens and Refresh Tokens</h3>
|
|||
|
|
|
|||
|
|
<p>Access Tokens might not be revocable by the Authorization Server.
|
|||
|
|
Access Token lifetimes SHOULD therefore be kept to single use or
|
|||
|
|
very short lifetimes.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
If ongoing access to the UserInfo Endpoint or other Protected Resources is required,
|
|||
|
|
a Refresh Token can be used. The Client can then exchange the Refresh Token at
|
|||
|
|
the Token Endpoint for a fresh short-lived Access Token that can be used to
|
|||
|
|
access the resource.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Authorization Server SHOULD clearly identify long-term grants to the User
|
|||
|
|
during Authorization.
|
|||
|
|
The Authorization Server SHOULD provide a mechanism for the End-User to revoke
|
|||
|
|
Access Tokens and Refresh Tokens granted to a Client.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="SymmetricKeyEntropy"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.19"></a>
|
|||
|
|
|
|||
|
|
<h3>16.19.
|
|||
|
|
Symmetric Key Entropy</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In <a class="info"
|
|||
|
|
href="#Signing">Section 10.1<span> (</span><span
|
|||
|
|
class="info">Signing</span><span>)</span></a> and <a class="info"
|
|||
|
|
href="#Encryption">Section 10.2<span> (</span><span
|
|||
|
|
class="info">Encryption</span><span>)</span></a>, keys are derived
|
|||
|
|
from the <tt>client_secret</tt> value.
|
|||
|
|
Thus, when used with symmetric signing or encryption operations,
|
|||
|
|
<tt>client_secret</tt> values MUST contain
|
|||
|
|
sufficient entropy to generate cryptographically strong keys.
|
|||
|
|
Also, <tt>client_secret</tt> values MUST also contain
|
|||
|
|
at least the minimum of number of octets required for MAC keys for the
|
|||
|
|
particular algorithm used.
|
|||
|
|
So for instance, for <tt>HS256</tt>, the
|
|||
|
|
<tt>client_secret</tt> value MUST contain
|
|||
|
|
at least 32 octets (and almost certainly SHOULD contain more,
|
|||
|
|
since <tt>client_secret</tt> values are
|
|||
|
|
likely to use a restricted alphabet).
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="NeedForSignedRequests"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.20"></a>
|
|||
|
|
|
|||
|
|
<h3>16.20.
|
|||
|
|
Need for Signed Requests</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In some situations, Clients might need to use signed requests to ensure that
|
|||
|
|
the desired request parameters are delivered to the OP without having
|
|||
|
|
been tampered with. For instance, the <tt>max_age</tt>
|
|||
|
|
and <tt>acr_values</tt> provide more assurance about
|
|||
|
|
the nature of the authentication performed when delivered in signed requests.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="NeedForEncryptedRequests"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.16.21"></a>
|
|||
|
|
|
|||
|
|
<h3>16.21.
|
|||
|
|
Need for Encrypted Requests</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In some situations, knowing the contents of an OpenID Connect request can,
|
|||
|
|
in and of itself, reveal sensitive information about the End-User.
|
|||
|
|
For instance, knowing that the Client is requesting a particular Claim or
|
|||
|
|
that it is requesting that a particular authentication method be used
|
|||
|
|
can reveal sensitive information about the End-User.
|
|||
|
|
OpenID Connect enables requests to be encrypted to the OpenID Provider
|
|||
|
|
to prevent such potentially sensitive information from being revealed.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Privacy"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.17"></a>
|
|||
|
|
|
|||
|
|
<h3>17.
|
|||
|
|
Privacy Considerations</h3>
|
|||
|
|
|
|||
|
|
<a name="PII"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.17.1"></a>
|
|||
|
|
|
|||
|
|
<h3>17.1.
|
|||
|
|
Personally Identifiable Information</h3>
|
|||
|
|
|
|||
|
|
<p>The UserInfo Response typically contains Personally Identifiable
|
|||
|
|
Information (PII). As such, End-User consent for the release of the information
|
|||
|
|
for the specified purpose should be obtained at or prior to the
|
|||
|
|
authorization time in accordance with relevant regulations. The purpose
|
|||
|
|
of use is typically registered in association with the <tt>redirect_uris</tt>.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Only necessary UserInfo data should be stored at the Client and the
|
|||
|
|
Client SHOULD associate the received data with the purpose of use
|
|||
|
|
statement.
|
|||
|
|
</p>
|
|||
|
|
<a name="AccessMonitoring"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.17.2"></a>
|
|||
|
|
|
|||
|
|
<h3>17.2.
|
|||
|
|
Data Access Monitoring</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The Resource Server SHOULD make End-Users' UserInfo access logs
|
|||
|
|
available to them so that they can monitor who accessed their data.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Correlation"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.17.3"></a>
|
|||
|
|
|
|||
|
|
<h3>17.3.
|
|||
|
|
Correlation</h3>
|
|||
|
|
|
|||
|
|
<p>To protect the End-User from a possible correlation among Clients, the
|
|||
|
|
use of a Pairwise Pseudonymous Identifier (PPID) as the
|
|||
|
|
<tt>sub</tt> (subject) SHOULD be considered.
|
|||
|
|
</p>
|
|||
|
|
<a name="OfflineAccessPrivacy"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.17.4"></a>
|
|||
|
|
|
|||
|
|
<h3>17.4.
|
|||
|
|
Offline Access</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Offline access enables access to Claims when the user is not present,
|
|||
|
|
posing greater privacy risk than the Claims transfer when the user is present.
|
|||
|
|
Therefore, it is prudent to obtain explicit consent for
|
|||
|
|
offline access to resources.
|
|||
|
|
This specification mandates the use of the <tt>prompt</tt>
|
|||
|
|
parameter to obtain consent unless it is already known that the
|
|||
|
|
request complies with the conditions for processing the request in each jurisdiction.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
When an Access Token is returned via the User Agent
|
|||
|
|
using the Implicit Flow or Hybrid Flow, there is
|
|||
|
|
a greater risk of it being exposed to an attacker, who could
|
|||
|
|
later use it to access the UserInfo endpoint.
|
|||
|
|
If the Access Token does not enable offline access and the server
|
|||
|
|
can differentiate whether the Client request has been made
|
|||
|
|
offline or online, the risk will be substantially reduced.
|
|||
|
|
Therefore, this specification mandates ignoring
|
|||
|
|
the offline access request when the Access Token is
|
|||
|
|
transmitted through the User Agent.
|
|||
|
|
Note that differentiating between online and offline access
|
|||
|
|
from the server can be difficult especially for native clients.
|
|||
|
|
The server may well have to rely on heuristics.
|
|||
|
|
Also, the risk of exposure for the Access Token delivered
|
|||
|
|
through the User Agent for the Response Types of
|
|||
|
|
<tt>code token</tt> and
|
|||
|
|
<tt>token</tt> is the same.
|
|||
|
|
Thus, the implementations should be prepared to detect
|
|||
|
|
whether the Access Token was issued through the User Agent
|
|||
|
|
or directly from the Token Endpoint and deny offline access
|
|||
|
|
if the token was issued through the User Agent.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Note that although these provisions require an explicit
|
|||
|
|
consent dialogue through the <tt>prompt</tt> parameter,
|
|||
|
|
the mere fact that the user pressed an "accept" button etc.,
|
|||
|
|
might not constitute a valid consent.
|
|||
|
|
Developers should be aware that for the act of consent to
|
|||
|
|
be valid, typically, the impact of the terms have to be
|
|||
|
|
understood by the End-User, the consent must be freely given
|
|||
|
|
and not forced (i.e., other options have to be available),
|
|||
|
|
and the terms must fair and equitable.
|
|||
|
|
In general, it is advisable for the service to follow the
|
|||
|
|
required privacy principles in each jurisdiction and rely on
|
|||
|
|
other conditions for processing the request than simply explicit consent,
|
|||
|
|
as online self-service "explicit consent" often does not
|
|||
|
|
form a valid consent in some jurisdictions.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="IANA"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18"></a>
|
|||
|
|
|
|||
|
|
<h3>18.
|
|||
|
|
IANA Considerations</h3>
|
|||
|
|
|
|||
|
|
<a name="ClaimsRegistry"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.1"></a>
|
|||
|
|
|
|||
|
|
<h3>18.1.
|
|||
|
|
JSON Web Token Claims Registration</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification registers the Claims defined in
|
|||
|
|
<a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> and <a class="info"
|
|||
|
|
href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> in the IANA
|
|||
|
|
JSON Web Token Claims registry
|
|||
|
|
defined in <a class="info" href="#JWT">[JWT]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ClaimsContents"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.1.1"></a>
|
|||
|
|
|
|||
|
|
<h3>18.1.1.
|
|||
|
|
Registry Contents</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>name</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Full name
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>given_name</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Given name(s) or first name(s)
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>family_name</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Surname(s) or last name(s)
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>middle_name</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Middle name(s)
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>nickname</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Casual name
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>preferred_username</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Shorthand name by which the End-User wishes to be referred to
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>profile</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Profile page URL
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>picture</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Profile picture URL
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>website</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Web page or blog URL
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>email</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Preferred e-mail address
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>email_verified</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: True if the e-mail address has been verified; otherwise false
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>gender</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Gender
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>birthdate</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Birthday
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>zoneinfo</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Time zone
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>locale</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Locale
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>phone_number</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Preferred telephone number
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>phone_number_verified</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: True if the phone number has been verified; otherwise false
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>address</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Preferred postal address
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>updated_at</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Time the information was last updated
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#StandardClaims">Section 5.1<span> (</span><span
|
|||
|
|
class="info">Standard Claims</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>azp</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Authorized party - the party to which the ID Token was issued
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>nonce</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Value used to associate a Client session with an ID Token
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>auth_time</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Time when the authentication occurred
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>at_hash</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Access Token hash value
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>c_hash</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Code hash value
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#HybridIDToken">Section 3.3.2.11<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>acr</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Authentication Context Class Reference
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>amr</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Authentication Methods References
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info" href="#IDToken">Section 2<span> (</span><span
|
|||
|
|
class="info">ID Token</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>
|
|||
|
|
Claim Name: <tt>sub_jwk</tt>
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Claim Description: Public key used to check the signature of an ID Token
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
Specification Document(s): <a class="info"
|
|||
|
|
href="#SelfIssuedResponse">Section 7.4<span> (</span><span
|
|||
|
|
class="info">Self-Issued OpenID Provider Response</span><span>)</span></a> of this document
|
|||
|
|
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="OAuthParametersRegistry"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.2"></a>
|
|||
|
|
|
|||
|
|
<h3>18.2.
|
|||
|
|
OAuth Parameters Registration</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification registers the following parameters
|
|||
|
|
in the IANA
|
|||
|
|
OAuth Parameters registry
|
|||
|
|
defined in <a class="info" href="#RFC6749">RFC
|
|||
|
|
6749<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ParametersContents"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.2.1"></a>
|
|||
|
|
|
|||
|
|
<h3>18.2.1.
|
|||
|
|
Registry Contents</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>nonce</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>display</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>prompt</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>max_age</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>ui_locales</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>claims_locales</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#ClaimsLanguagesAndScripts">Section 5.2<span> (</span><span
|
|||
|
|
class="info">Claims Languages and Scripts</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>id_token_hint</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>login_hint</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>acr_values</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthorizationEndpoint">Section 3.1.2<span> (</span><span
|
|||
|
|
class="info">Authorization Endpoint</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>claims</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#ClaimsParameter">Section 5.5<span> (</span><span
|
|||
|
|
class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a> of this
|
|||
|
|
document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>registration</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#RegistrationParameter">Section 7.2.1<span> (</span><span
|
|||
|
|
class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a> of
|
|||
|
|
this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>request</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#JWTRequests">Section 6<span> (</span><span
|
|||
|
|
class="info">Passing Request Parameters as JWTs</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>request_uri</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Request
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#JWTRequests">Section 6<span> (</span><span
|
|||
|
|
class="info">Passing Request Parameters as JWTs</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Parameter name: <tt>id_token</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Parameter usage location: Authorization Response,
|
|||
|
|
Access Token Response
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#TokenResponse">Section 3.1.3.3<span> (</span><span
|
|||
|
|
class="info">Successful Token Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
<li>Related information: None
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="OAuthErrorRegistry"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.3"></a>
|
|||
|
|
|
|||
|
|
<h3>18.3.
|
|||
|
|
OAuth Extensions Error Registration</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
This specification registers the following errors
|
|||
|
|
in the IANA
|
|||
|
|
OAuth Extensions Error registry
|
|||
|
|
defined in <a class="info" href="#RFC6749">RFC
|
|||
|
|
6749<span> (</span><span
|
|||
|
|
class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
|
|||
|
|
[RFC6749].
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="ErrorContents"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.18.3.1"></a>
|
|||
|
|
|
|||
|
|
<h3>18.3.1.
|
|||
|
|
Registry Contents</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>interaction_required</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>login_required</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>account_selection_required</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>consent_required</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>invalid_request_uri</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>invalid_request_object</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>request_not_supported</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>request_uri_not_supported</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<ul class="text">
|
|||
|
|
<li>Error name: <tt>registration_not_supported</tt>
|
|||
|
|
</li>
|
|||
|
|
<li>Error usage location: Authorization Endpoint
|
|||
|
|
</li>
|
|||
|
|
<li>Related protocol extension: OpenID Connect
|
|||
|
|
</li>
|
|||
|
|
<li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
|
|||
|
|
</li>
|
|||
|
|
<li>Specification document(s): <a class="info"
|
|||
|
|
href="#AuthError">Section 3.1.2.6<span> (</span><span
|
|||
|
|
class="info">Authentication Error Response</span><span>)</span></a> of this document
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="rfc.references"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.19"></a>
|
|||
|
|
|
|||
|
|
<h3>19.
|
|||
|
|
References</h3>
|
|||
|
|
|
|||
|
|
<a name="rfc.references1"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<h3>19.1. Normative References</h3>
|
|||
|
|
<table width="99%" border="0">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="CORS">[CORS]</a></td>
|
|||
|
|
<td class="author-text">Opera Software ASA, “<a href="http://www.w3.org/TR/access-control/">Cross-Origin
|
|||
|
|
Resource Sharing</a>,” July 2010.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="E.164">[E.164]</a></td>
|
|||
|
|
<td class="author-text">International Telecommunication Union, “<a
|
|||
|
|
href="http://www.itu.int/rec/T-REC-E.164-201011-I/en">E.164: The international public telecommunication
|
|||
|
|
numbering plan</a>,” 2010.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="IANA.Language">[IANA.Language]</a></td>
|
|||
|
|
<td class="author-text">Internet Assigned Numbers Authority (IANA), “<a
|
|||
|
|
href="http://www.iana.org/assignments/language-subtag-registry">Language Subtag Registry</a>,” 2005.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="ISO29115">[ISO29115]</a></td>
|
|||
|
|
<td class="author-text">International Organization for Standardization, “<a
|
|||
|
|
href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138">ISO/IEC
|
|||
|
|
29115:2013 --
|
|||
|
|
Information technology - Security techniques - Entity authentication
|
|||
|
|
assurance framework</a>,” ISO/IEC 29115, March 2013.
|
|||
|
|
</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="ISO8601-2004">[ISO8601-2004]</a></td>
|
|||
|
|
<td class="author-text">International Organization for
|
|||
|
|
Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange -
|
|||
|
|
Representation of dates and times,” 2004.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWA">[JWA]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">JSON
|
|||
|
|
Web Algorithms (JWA)</a>,” draft-ietf-jose-json-web-algorithms (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., Rescorla, E., and J. Hildebrand, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>,”
|
|||
|
|
draft-ietf-jose-json-web-encryption (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWK">[JWK]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key">JSON Web
|
|||
|
|
Key (JWK)</a>,” draft-ietf-jose-json-web-key (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature (JWS)</a>,”
|
|||
|
|
draft-ietf-jose-json-web-signature (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-31">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">JSON Web Token (JWT)</a>,”
|
|||
|
|
draft-ietf-oauth-json-web-token (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OAuth.Assertions">[OAuth.Assertions]</a></td>
|
|||
|
|
<td class="author-text">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-oauth-assertions">Assertion Framework for OAuth 2.0 Client
|
|||
|
|
Authentication and Authorization Grants</a>,” draft-ietf-oauth-assertions (work in progress), July 2014
|
|||
|
|
(<a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-17">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OAuth.JWT">[OAuth.JWT]</a></td>
|
|||
|
|
<td class="author-text">Jones, M., Campbell, B., and C. Mortimore, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer">JSON Web Token (JWT) Profile for OAuth 2.0
|
|||
|
|
Client Authentication and Authorization Grants</a>,” draft-ietf-oauth-jwt-bearer (work in progress), July 2014
|
|||
|
|
(<a href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OAuth.Responses">[OAuth.Responses]</a></td>
|
|||
|
|
<td class="author-text">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “<a
|
|||
|
|
href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">OAuth 2.0 Multiple Response
|
|||
|
|
Type Encoding Practices</a>,” February 2014.
|
|||
|
|
</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>,”
|
|||
|
|
November 2014.
|
|||
|
|
</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., and M. Jones, “<a
|
|||
|
|
href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client
|
|||
|
|
Registration 1.0</a>,” November 2014.
|
|||
|
|
</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="RFC2246">[RFC2246]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:tdierks@certicom.com">Dierks, T.</a> and <a
|
|||
|
|
href="mailto:callen@certicom.com">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS
|
|||
|
|
Protocol Version 1.0</a>,” RFC 2246, January 1999 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc2246.txt">TXT</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="RFC3339">[RFC3339]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a
|
|||
|
|
href="mailto:chris.newman@sun.com">C. Newman</a>, “<a href="http://tools.ietf.org/html/rfc3339">Date and
|
|||
|
|
Time on the Internet: Timestamps</a>,” RFC 3339, July 2002 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC3966">[RFC3966]</a></td>
|
|||
|
|
<td class="author-text">Schulzrinne, H., “<a href="http://tools.ietf.org/html/rfc3966">The tel URI for Telephone
|
|||
|
|
Numbers</a>,” RFC 3966, December 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3966.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding,
|
|||
|
|
R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform
|
|||
|
|
Resource Identifier (URI): Generic Syntax</a>,” STD 66, RFC 3986, January 2005 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
|
|||
|
|
<td class="author-text">Crockford, D., “<a href="http://tools.ietf.org/html/rfc4627">The application/json Media
|
|||
|
|
Type for JavaScript Object Notation (JSON)</a>,” RFC 4627, July 2006 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</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="RFC5322">[RFC5322]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:presnick@qualcomm.com">Resnick, P., Ed.</a>, “<a
|
|||
|
|
href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>,” RFC 5322, October 2008
|
|||
|
|
(<a href="http://www.rfc-editor.org/rfc/rfc5322.txt">TXT</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/html/rfc5322.html">HTML</a>, <a
|
|||
|
|
href="http://xml.resource.org/public/rfc/xml/rfc5322.xml">XML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC5646">[RFC5646]</a></td>
|
|||
|
|
<td class="author-text">Phillips, A. and M. Davis, “<a href="http://tools.ietf.org/html/rfc5646">Tags for
|
|||
|
|
Identifying Languages</a>,” BCP 47, RFC 5646, September 2009 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc5646.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC6125">[RFC6125]</a></td>
|
|||
|
|
<td class="author-text">Saint-Andre, P. and J. Hodges, “<a href="http://tools.ietf.org/html/rfc6125">Representation
|
|||
|
|
and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure
|
|||
|
|
Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>,” RFC 6125, March 2011
|
|||
|
|
(<a href="http://www.rfc-editor.org/rfc/rfc6125.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC6711">[RFC6711]</a></td>
|
|||
|
|
<td class="author-text">Johansson, L., “<a href="http://tools.ietf.org/html/rfc6711">An IANA Registry for Level
|
|||
|
|
of Assurance (LoA) Profiles</a>,” RFC 6711, August 2012 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc6711.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
|
|||
|
|
<td class="author-text">Hardt, D., “<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization
|
|||
|
|
Framework</a>,” RFC 6749, October 2012 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc6749.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC6750">[RFC6750]</a></td>
|
|||
|
|
<td class="author-text">Jones, M. and D. Hardt, “<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0
|
|||
|
|
Authorization Framework: Bearer Token Usage</a>,” RFC 6750, October 2012 (<a
|
|||
|
|
href="http://www.rfc-editor.org/rfc/rfc6750.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC6819">[RFC6819]</a></td>
|
|||
|
|
<td class="author-text">Lodderstedt, T., McGloin, M., and P. Hunt, “<a
|
|||
|
|
href="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>,” RFC 6819,
|
|||
|
|
January 2013 (<a href="http://www.rfc-editor.org/rfc/rfc6819.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="USA15">[USA15]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler,
|
|||
|
|
K.</a>, and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
|
|||
|
|
</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">Raggett, D., Hors, A., and I. Jacobs, “<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>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
|
|||
|
|
<a name="rfc.references2"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<h3>19.2. Informative References</h3>
|
|||
|
|
<table width="99%" border="0">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="JWK.Thumbprint">[JWK.Thumbprint]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, “<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint">JSON Web Key (JWK) Thumbprint</a>,”
|
|||
|
|
draft-jones-jose-jwk-thumbprint (work in progress), July 2014 (<a
|
|||
|
|
href="http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OAuth.Post">[OAuth.Post]</a></td>
|
|||
|
|
<td class="author-text">Jones, M. and B. Campbell, “<a
|
|||
|
|
href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">OAuth 2.0 Form Post Response
|
|||
|
|
Mode</a>,” February 2014.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OpenID.2.0">[OpenID.2.0]</a></td>
|
|||
|
|
<td class="author-text">OpenID Foundation, “OpenID Authentication 2.0,” December 2007 (<a
|
|||
|
|
href="http://openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a
|
|||
|
|
href="http://openid.net/specs/openid-authentication-2_0.html">HTML</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OpenID.Basic">[OpenID.Basic]</a></td>
|
|||
|
|
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a
|
|||
|
|
href="http://openid.net/specs/openid-connect-basic-1_0.html">OpenID Connect Basic Client Implementer's
|
|||
|
|
Guide 1.0</a>,” November 2014.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OpenID.Implicit">[OpenID.Implicit]</a></td>
|
|||
|
|
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a
|
|||
|
|
href="http://openid.net/specs/openid-connect-implicit-1_0.html">OpenID Connect Implicit Client
|
|||
|
|
Implementer's Guide 1.0</a>,” November 2014.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="OpenID.PAPE">[OpenID.PAPE]</a></td>
|
|||
|
|
<td class="author-text"><a href="mailto:david@sixapart.com">Recordon, D.</a>, <a
|
|||
|
|
href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:johnny.bufu@gmail.com">Bufu, J., Ed.</a>,
|
|||
|
|
<a href="mailto:cygnus@janrain.com">Daugherty, J., Ed.</a>, and <a href="mailto:n-sakimura@nri.co.jp">N.
|
|||
|
|
Sakimura</a>, “OpenID Provider
|
|||
|
|
Authentication Policy Extension 1.0,” December 2008 (<a
|
|||
|
|
href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.txt">TXT</a>, <a
|
|||
|
|
href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">HTML</a>).
|
|||
|
|
</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>,”
|
|||
|
|
November 2014.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="RFC4949">[RFC4949]</a></td>
|
|||
|
|
<td class="author-text">Shirey, R., “<a href="http://tools.ietf.org/html/rfc4949">Internet Security Glossary,
|
|||
|
|
Version 2</a>,” RFC 4949, August 2007 (<a href="http://www.rfc-editor.org/rfc/rfc4949.txt">TXT</a>).
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text" valign="top"><a name="X.1252">[X.1252]</a></td>
|
|||
|
|
<td class="author-text">International Telecommunication Union, “<a
|
|||
|
|
href="http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.1252-201004-I!!PDF-E&type=items">ITU-T
|
|||
|
|
Recommendation X.1252 -- Cyberspace security -- Identity management
|
|||
|
|
-- Baseline identity management terms and definitions</a>,” ITU-T X.1252, November 2010.
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
|
|||
|
|
<a name="AuthorizationExamples"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A"></a>
|
|||
|
|
|
|||
|
|
<h3>Appendix A.
|
|||
|
|
Authorization Examples</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following are non-normative examples of Authorization Requests with
|
|||
|
|
different <tt>response_type</tt> values and their responses
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="codeExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.1"></a>
|
|||
|
|
|
|||
|
|
<h3>A.1.
|
|||
|
|
Example using response_type=code</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb?
|
|||
|
|
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="id_tokenExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.2"></a>
|
|||
|
|
|
|||
|
|
<h3>A.2.
|
|||
|
|
Example using response_type=id_token</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=id_token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz
|
|||
|
|
cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4
|
|||
|
|
Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi
|
|||
|
|
bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz
|
|||
|
|
MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6
|
|||
|
|
ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm
|
|||
|
|
ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6
|
|||
|
|
ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l
|
|||
|
|
eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn
|
|||
|
|
spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip
|
|||
|
|
R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac
|
|||
|
|
AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY
|
|||
|
|
u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD
|
|||
|
|
4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl
|
|||
|
|
6cQQWNiDpWOl_lxXjQEvQ
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
The value of the <tt>id_token</tt> parameter is the ID Token,
|
|||
|
|
which is a signed JWT,
|
|||
|
|
containing three base64url encoded segments separated by period ('.') characters.
|
|||
|
|
The first segment represents the JOSE Header.
|
|||
|
|
Base64url decoding it will result in the following set of Header Parameters:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {"kid":"1e9gdk7","alg":"RS256"}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
The <tt>alg</tt> value represents the algorithm
|
|||
|
|
that was used to sign the JWT, in this case
|
|||
|
|
<tt>RS256</tt>, representing RSASSA-PKCS-v1_5 using SHA-256.
|
|||
|
|
The <tt>kid</tt> value is a key identifier used
|
|||
|
|
in identifying the key to be used to verify the signature.
|
|||
|
|
If the <tt>kid</tt> value is unknown to the RP,
|
|||
|
|
it needs to retrieve the contents of the OP's JWK Set again
|
|||
|
|
to obtain the OP's current set of keys.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The second segment represents the Claims in the ID Token.
|
|||
|
|
Verifying and decoding the ID Token will yield the following Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "http://server.example.com",
|
|||
|
|
"sub": "248289761001",
|
|||
|
|
"aud": "s6BhdRkqt3",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"name": "Jane Doe",
|
|||
|
|
"given_name": "Jane",
|
|||
|
|
"family_name": "Doe",
|
|||
|
|
"gender": "female",
|
|||
|
|
"birthdate": "0000-10-31",
|
|||
|
|
"email": "janedoe@example.com",
|
|||
|
|
"picture": "http://example.com/janedoe/me.jpg"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
The third segment represents the ID Token signature,
|
|||
|
|
which is verified as described in <a class="info" href="#JWS">[JWS]<span> (</span><span
|
|||
|
|
class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.</span><span>)</span></a>.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="id_token-tokenExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.3"></a>
|
|||
|
|
|
|||
|
|
<h3>A.3.
|
|||
|
|
Example using response_type=id_token token</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=id_token%20token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
|
|||
|
|
&token_type=Bearer
|
|||
|
|
&id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
|
|||
|
|
zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
|
|||
|
|
4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
|
|||
|
|
ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
|
|||
|
|
zMTEyODA5NzAsCiAiYXRfaGFzaCI6ICI3N1FtVVB0alBmeld0RjJBbnBLOVJ
|
|||
|
|
RIgp9.F9gRev0Dt2tKcrBkHy72cmRqnLdzw9FLCCSebV7mWs7o_sv2O5s6zM
|
|||
|
|
ky2kmhHTVx9HmdvNnx9GaZ8XMYRFeYk8L5NZ7aYlA5W56nsG1iWOou_-gji0
|
|||
|
|
ibWIuuf4Owaho3YSoi7EvsTuLFz6tq-dLyz0dKABMDsiCmJ5wqkPUDTE3QTX
|
|||
|
|
jzbUmOzUDli-gCh5QPuZAq0cNW3pf_2n4zpvTYtbmj12cVcxGIMZby7TMWES
|
|||
|
|
RjQ9_o3jvhVNcCGcE0KAQXejhA1ocJhNEvQNqMFGlBb6_0RxxKjDZ-Oa329e
|
|||
|
|
GDidOvvp0h5hoES4a8IuGKS7NOcpp-aFwp0qVMDLI-Xnm-Pg
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
Verifying and decoding the ID Token will yield the following Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "http://server.example.com",
|
|||
|
|
"sub": "248289761001",
|
|||
|
|
"aud": "s6BhdRkqt3",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="code-id_tokenExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.4"></a>
|
|||
|
|
|
|||
|
|
<h3>A.4.
|
|||
|
|
Example using response_type=code id_token</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code%20id_token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
|
|||
|
|
&id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
|
|||
|
|
zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
|
|||
|
|
4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
|
|||
|
|
ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
|
|||
|
|
zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
|
|||
|
|
iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
|
|||
|
|
egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
|
|||
|
|
_7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
|
|||
|
|
sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
|
|||
|
|
7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
|
|||
|
|
gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
Verifying and decoding the ID Token will yield the following Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "http://server.example.com",
|
|||
|
|
"sub": "248289761001",
|
|||
|
|
"aud": "s6BhdRkqt3",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"c_hash": "LDktKdoQak3Pk0cnXxCltA"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="code-tokenExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.5"></a>
|
|||
|
|
|
|||
|
|
<h3>A.5.
|
|||
|
|
Example using response_type=code token</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code%20token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
|
|||
|
|
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
|
|||
|
|
&token_type=Bearer
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="code-id_token-tokenExample"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.6"></a>
|
|||
|
|
|
|||
|
|
<h3>A.6.
|
|||
|
|
Example using response_type=code id_token token</h3>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> GET /authorize?
|
|||
|
|
response_type=code%20id_token%20token
|
|||
|
|
&client_id=s6BhdRkqt3
|
|||
|
|
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
|
|||
|
|
&scope=openid%20profile%20email
|
|||
|
|
&nonce=n-0S6_WzA2Mj
|
|||
|
|
&state=af0ifjsldkj HTTP/1.1
|
|||
|
|
Host: server.example.com
|
|||
|
|
|
|||
|
|
HTTP/1.1 302 Found
|
|||
|
|
Location: https://client.example.org/cb#
|
|||
|
|
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
|
|||
|
|
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
|
|||
|
|
&token_type=Bearer
|
|||
|
|
&id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
|
|||
|
|
zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
|
|||
|
|
4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
|
|||
|
|
ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
|
|||
|
|
zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
|
|||
|
|
iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
|
|||
|
|
egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
|
|||
|
|
_7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
|
|||
|
|
sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
|
|||
|
|
7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
|
|||
|
|
gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
|
|||
|
|
&state=af0ifjsldkj
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<p>
|
|||
|
|
Verifying and decoding the ID Token will yield the following Claims:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"iss": "http://server.example.com",
|
|||
|
|
"sub": "248289761001",
|
|||
|
|
"aud": "s6BhdRkqt3",
|
|||
|
|
"nonce": "n-0S6_WzA2Mj",
|
|||
|
|
"exp": 1311281970,
|
|||
|
|
"iat": 1311280970,
|
|||
|
|
"at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
|
|||
|
|
"c_hash": "LDktKdoQak3Pk0cnXxCltA"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="ExampleRSAKey"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.A.7"></a>
|
|||
|
|
|
|||
|
|
<h3>A.7.
|
|||
|
|
RSA Key Used in Examples</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The following RSA public key, represented in JWK format, can be used to
|
|||
|
|
validate the ID Token signatures in the above examples
|
|||
|
|
(with line wraps within values for display purposes only):
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre> {
|
|||
|
|
"kty":"RSA",
|
|||
|
|
"kid":"1e9gdk7",
|
|||
|
|
"n":"w7Zdfmece8iaB0kiTY8pCtiBtzbptJmP28nSWwtdjRu0f2GFpajvWE4VhfJA
|
|||
|
|
jEsOcwYzay7XGN0b-X84BfC8hmCTOj2b2eHT7NsZegFPKRUQzJ9wW8ipn_aD
|
|||
|
|
JWMGDuB1XyqT1E7DYqjUCEOD1b4FLpy_xPn6oV_TYOfQ9fZdbE5HGxJUzeku
|
|||
|
|
GcOKqOQ8M7wfYHhHHLxGpQVgL0apWuP2gDDOdTtpuld4D2LK1MZK99s9gaSj
|
|||
|
|
RHE8JDb1Z4IGhEcEyzkxswVdPndUWzfvWBBWXWxtSUvQGBRkuy1BHOa4sP6F
|
|||
|
|
KjWEeeF7gm7UMs2Nm2QUgNZw6xvEDGaLk4KASdIxRQ",
|
|||
|
|
"e":"AQAB"
|
|||
|
|
}
|
|||
|
|
</pre>
|
|||
|
|
</div>
|
|||
|
|
<a name="Acknowledgements"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.B"></a>
|
|||
|
|
|
|||
|
|
<h3>Appendix B.
|
|||
|
|
Acknowledgements</h3>
|
|||
|
|
|
|||
|
|
<p>As a successor version of OpenID, this specification heavily relies
|
|||
|
|
on ideas explored in <a class="info" href="#OpenID.2.0">OpenID
|
|||
|
|
Authentication 2.0<span> (</span><span class="info">OpenID Foundation, “OpenID Authentication 2.0,” December 2007.</span><span>)</span></a>
|
|||
|
|
[OpenID.2.0]. Please
|
|||
|
|
refer to Appendix C of OpenID Authentication 2.0 for the full list of
|
|||
|
|
the contributors for that specification.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
In addition, the OpenID Community would like to thank the following people for
|
|||
|
|
their contributions to this specification:
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
</p>
|
|||
|
|
<blockquote class="text">
|
|||
|
|
<p>Naveen Agarwal (naa@google.com), Google
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Amanda Anganes (aanganes@mitre.org), MITRE
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Casper Biering (cb@peercraft.com), Peercraft
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>John Bradley (ve7jtb@ve7jtb.com), Ping Identity
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Tim Bray (tbray@textuality.com), Google
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Johnny Bufu (jbufu@janrain.com), Janrain
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Brian Campbell (bcampbell@pingidentity.com), Ping Identity
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Blaine Cook (romeda@gmail.com), Independent
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Breno de Medeiros (breno@google.com), Google
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Pamela Dingle (pdingle@pingidentity.com), Ping Identity
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>George Fletcher (george.fletcher@corp.aol.com), AOL
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Edmund Jay (ejay@mgi1.com), Illumila
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Nov Matake (nov@matake.jp), Independent
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Chuck Mortimore (cmortimore@salesforce.com), Salesforce
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Anthony Nadalin (tonynad@microsoft.com), Microsoft
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>David Recordon (dr@fb.com), Facebook
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Justin Richer (jricher@mitre.org), MITRE
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Luke Shepard (lshepard@fb.com), Facebook
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Andreas Åkre Solberg (andreas.solberg@uninett.no), UNINET
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>Paul Tarjan (pt@fb.com), Facebook
|
|||
|
|
</p>
|
|||
|
|
</blockquote>
|
|||
|
|
<p>
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="Notices"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<a name="rfc.section.C"></a>
|
|||
|
|
|
|||
|
|
<h3>Appendix C.
|
|||
|
|
Notices</h3>
|
|||
|
|
|
|||
|
|
<p>Copyright (c) 2014 The OpenID Foundation.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The OpenID Foundation (OIDF) grants to any Contributor, developer,
|
|||
|
|
implementer, or other interested party a non-exclusive, royalty free,
|
|||
|
|
worldwide copyright license to reproduce, prepare derivative works from,
|
|||
|
|
distribute, perform and display, this Implementers Draft or
|
|||
|
|
Final Specification solely for the purposes of (i) developing
|
|||
|
|
specifications, and (ii) implementing Implementers Drafts and
|
|||
|
|
Final Specifications based on such documents, provided that attribution
|
|||
|
|
be made to the OIDF as the source of the material, but that such attribution
|
|||
|
|
does not indicate an endorsement by the OIDF.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
The technology described in this specification was
|
|||
|
|
made available from contributions from various sources,
|
|||
|
|
including members of the OpenID Foundation and others.
|
|||
|
|
Although the OpenID Foundation has taken steps to help ensure
|
|||
|
|
that the technology is available for distribution, it takes
|
|||
|
|
no position regarding the validity or scope of any intellectual
|
|||
|
|
property or other rights that might be claimed to pertain to
|
|||
|
|
the implementation or use of the technology described in
|
|||
|
|
this specification or the extent to which any license under
|
|||
|
|
such rights might or might not be available; neither does it
|
|||
|
|
represent that it has made any independent effort to identify
|
|||
|
|
any such rights. The OpenID Foundation and the contributors
|
|||
|
|
to this specification make no (and hereby expressly disclaim any)
|
|||
|
|
warranties (express, implied, or otherwise), including implied
|
|||
|
|
warranties of merchantability, non-infringement, fitness for
|
|||
|
|
a particular purpose, or title, related to this specification,
|
|||
|
|
and the entire risk as to implementing this specification is
|
|||
|
|
assumed by the implementer. The OpenID Intellectual
|
|||
|
|
Property Rights policy requires contributors to offer
|
|||
|
|
a patent promise not to assert certain patent claims against
|
|||
|
|
other contributors and against implementers. The OpenID Foundation invites
|
|||
|
|
any interested party to bring to its attention any copyrights,
|
|||
|
|
patents, patent applications, or other proprietary rights
|
|||
|
|
that may cover technology that may be required to practice
|
|||
|
|
this specification.
|
|||
|
|
|
|||
|
|
</p>
|
|||
|
|
<a name="rfc.authors"></a><br>
|
|||
|
|
<hr>
|
|||
|
|
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="TOCbug"><a href="#toc"> TOC </a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
<h3>Authors' Addresses</h3>
|
|||
|
|
<table width="99%" border="0" cellpadding="0" cellspacing="0">
|
|||
|
|
<tbody>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text"> </td>
|
|||
|
|
<td class="author-text">Nat Sakimura</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>
|
|||
|
|
<td class="author" align="right">URI: </td>
|
|||
|
|
<td class="author-text"><a href="http://nat.sakimura.org/">http://nat.sakimura.org/</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">Ping Identity</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author" align="right">Email: </td>
|
|||
|
|
<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author" align="right">URI: </td>
|
|||
|
|
<td class="author-text"><a href="http://www.thread-safe.com/">http://www.thread-safe.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</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>
|
|||
|
|
<td class="author" align="right">URI: </td>
|
|||
|
|
<td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</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>
|
|||
|
|
<td class="author" align="right">URI: </td>
|
|||
|
|
<td class="author-text"><a href="http://stackoverflow.com/users/311376/breno">http://stackoverflow.com/users/311376/breno</a>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr cellpadding="3">
|
|||
|
|
<td> </td>
|
|||
|
|
<td> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text"> </td>
|
|||
|
|
<td class="author-text">Chuck Mortimore</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author-text"> </td>
|
|||
|
|
<td class="author-text">Salesforce</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author" align="right">Email: </td>
|
|||
|
|
<td class="author-text"><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a></td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td class="author" align="right">URI: </td>
|
|||
|
|
<td class="author-text"><a href="https://twitter.com/cmort">https://twitter.com/cmort</a></td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
|
|||
|
|
<div id="cntvlive2-is-installed"></div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|