CINXE.COM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"><head><title>Final: OpenID Connect Core 1.0 incorporating errata set 2</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="description" content="OpenID Connect Core 1.0 incorporating errata set 2"> <meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)"> <style type='text/css'></style> </head> <body> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> <tr><td class="header">Final</td><td class="header">N. Sakimura</td></tr> <tr><td class="header"> </td><td class="header">NAT.Consulting (was at NRI)</td></tr> <tr><td class="header"> </td><td class="header">J. Bradley</td></tr> <tr><td class="header"> </td><td class="header">Yubico (was at Ping Identity)</td></tr> <tr><td class="header"> </td><td class="header">M. Jones</td></tr> <tr><td class="header"> </td><td class="header">Self-Issued Consulting (was at</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">Disney (was at Salesforce)</td></tr> <tr><td class="header"> </td><td class="header">December 15, 2023</td></tr> </table></td></tr></table> <h1><br />OpenID Connect Core 1.0 incorporating errata set 2</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>  URI 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="#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="#HTTP307Redirects">16.22.</a>  HTTP 307 Redirects<br />     <a href="#iOSCustomSchemes">16.23.</a>  Custom URI Schemes on iOS<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="#URISchemeRegistry">18.4.</a>  URI Scheme Registration<br />         <a href="#URISchemeContents">18.4.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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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., Ed., “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),” May 2015.</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,” December 2023.</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,” December 2023.</span><span>)</span></a> [OpenID.Registration], or may be obtained via other mechanisms. </p> <p> The previous versions of this specification are: </p> <ul class="text"> <li><a class='info' href='#OpenID.Core.Errata1'>OpenID Connect Core 1.0 incorporating errata set 1<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0 incorporating errata set 1,” November 2014.</span><span>)</span></a> [OpenID.Core.Errata1] </li> <li><a class='info' href='#OpenID.Core.Final'>OpenID Connect Core 1.0 (final)<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0 (final),” February 2014.</span><span>)</span></a> [OpenID.Core.Final] </li> </ul><p> </p> <a name="rnc"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.1.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 specification, 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 specification, 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),” May 2015.</span><span>)</span></a> [JWS] and <a class='info' href='#JWE'>JSON Web Encryption (JWE)<span> (</span><span class='info'>Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 Server", "Response Type", and "Token Endpoint" defined by <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “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),” May 2015.</span><span>)</span></a> [JWT], the terms "Base64url Encoding", "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),” May 2015.</span><span>)</span></a> [JWS], the term "User Agent" defined by <a class='info' href='#RFC7230'>RFC 7230<span> (</span><span class='info'>Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.</span><span>)</span></a> [RFC7230], 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,” April 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., Ed., “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),” May 2015.</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,” April 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,” April 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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 <a class='info' href='#RFC20'>[RFC20]<span> (</span><span class='info'>Cerf, V., “ASCII format for Network Interchange,” October 1969.</span><span>)</span></a> 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 by the RP when performing authentication with the OP. 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 <a class='info' href='#RFC8259'>[RFC8259]<span> (</span><span class='info'>Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” December 2017.</span><span>)</span></a> number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. See <a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G. 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. NOTE: The ID Token expiration time is unrelated the lifetime of the authenticated session between the RP and the OP. </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-01T00:00:00Z 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-01T00:00:00Z 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,” April 2013.</span><span>)</span></a> [ISO29115] level 1. For historic reasons, the value "0" is used to indicate that there is no confidence that the same person is actually there. 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 <tt>amr</tt> value is an array of case-sensitive strings. Values used in the <tt>amr</tt> Claim SHOULD be from those registered in the IANA Authentication Method Reference Values registry <a class='info' href='#IANA.AMR'>[IANA.AMR]<span> (</span><span class='info'>IANA, “Authentication Method Reference Values,” .</span><span>)</span></a> established by <a class='info' href='#RFC8176'>[RFC8176]<span> (</span><span class='info'>Jones, M., Hunt, P., and A. Nadalin, “Authentication Method Reference Values,” June 2017.</span><span>)</span></a>; parties using this claim will need to agree upon the meanings of any unregistered values used, which may be context specific. </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. The <tt>azp</tt> value is a case-sensitive string containing a StringOrURI value. Note that in practice, the <tt>azp</tt> Claim only occurs when extensions beyond the scope of this specification are used; therefore, implementations not using such extensions are encouraged to not use <tt>azp</tt> and to ignore it when it does occur. </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),” May 2015.</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),” May 2015.</span><span>)</span></a> [JWS] and <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.</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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 was performed, 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"> <col align="left"><col align="left"><col align="left"><col align="left"> <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> </table> <br clear="all" /> <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> OpenID Connect Authentication Flows </b></font><br /></td></tr></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"> <col align="left"><col align="left"> <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> </table> <br clear="all" /> <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> OpenID Connect "response_type" Values </b></font><br /></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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='#RFC7231'>RFC 7231<span> (</span><span class='info'>Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.</span><span>)</span></a> [RFC7231] 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. Also, if the Client is a native application, it MAY use the <tt>http</tt> scheme with <tt>localhost</tt> or the IP loopback literals <tt>127.0.0.1</tt> or <tt>[::1]</tt> as the hostname. 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> </dd> <dt></dt> <dd> The Authorization Server MAY also attempt to detect the capabilities of the User Agent and present an appropriate display. </dd> <dt></dt> <dd> If an OP receives a <tt>display</tt> value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new <tt>display</tt> values. </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> </dd> <dt></dt> <dd> 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></dt> <dd> If an OP receives a <tt>prompt</tt> value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new <tt>prompt</tt> values. </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. Note that <tt>max_age=0</tt> is equivalent to <tt>prompt=login</tt>. </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., Ed. and M. Davis, Ed., “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 already logged in or is logged in as a result of the request (with the OP possibly evaluating other information beyond the ID Token in this decision), then the Authorization Server returns a positive response; otherwise, it MUST 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> <li> When an <tt>id_token_hint</tt> is present, the OP MUST validate that it was the issuer of the ID Token. The OP SHOULD accept ID Tokens when the RP identified by the ID Token has a current session or had a recent session at the OP, even when the <tt>exp</tt> time has passed. </li> </ol><p> </p> <p> As specified in <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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. If the Redirection URI is invalid, the Authorization Server MUST NOT redirect the User Agent to the invalid Redirection URI. </p> <p> If the Response Mode value is not supported, the Authorization Server returns an HTTP response code of 400 (Bad Request) without Error Response parameters, since understanding the Response Mode is necessary to know how to return those parameters. </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> 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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. Note that the <tt>token_type</tt> value is case insensitive. </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"> <col align="left"><col align="left"> <tr><th align="left">Header Name</th><th align="left">Header Value</th></tr> <tr> <td align="left">Cache-Control</td> <td align="left">no-store</td> </tr> </table> <br clear="all" /> <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> HTTP Response Headers and Values </b></font><br /></td></tr></table><hr class="insert" /> <p> 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 { "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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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 { "error": "invalid_request" } </pre></div> <a name="TokenResponseValidation"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.3.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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 implementation is using extensions (which are beyond the scope of this specification) that result in the <tt>azp</tt> (authorized party) Claim being present, it SHOULD validate the <tt>azp</tt> value as specified by those extensions. </li> <li> This validation MAY include that when 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),” May 2015.</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 <a class='info' href='#RFC3629'>[RFC3629]<span> (</span><span class='info'>Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.</span><span>)</span></a> 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. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> or the IP loopback literals <tt>127.0.0.1</tt> or <tt>[::1]</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> Whenever Error Response parameters are returned, such as when End-User denies the authorization 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 Section 4.2.2.1 of <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> <dt>nonce</dt> <dd> REQUIRED if the Response Type of the request is <tt>code id_token</tt> or <tt>code id_token token</tt> and OPTIONAL when the Response Type of the request is <tt>code token</tt>. It is a 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 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> Whenever Error Response parameters are returned, such as when End-User denies the authorization 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 Section 4.2.2.1 of <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> If a <tt>nonce</tt> parameter is present in the Authentication Request, Authorization Servers MUST include a <tt>nonce</tt> Claim in the ID Token. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. Note that this login initiation endpoint can be a different page at the RP than the RP's 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,” December 2023.</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 End-User to be authenticated. The meaning of this string-valued parameter is left to the OP's discretion. In common use cases, the value will contain an e-mail address, phone number, or username collected by the RP before requesting authentication at the OP. For example, this hint can be used by an RP after it asks the End-User for their e-mail address (or other identifier), passing that identifier as a hint to the OpenID Provider. It is RECOMMENDED that the hint value match the value provided for discovery. Other uses MAY include using the <tt>sub</tt> claim from the ID Token as the hint value or potentially other kinds of information about the requested authentication. </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., Ed., 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"> <col align="left"><col align="left"><col align="left"> <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-1'>ISO 8601-1<span> (</span><span class='info'>International Organization for Standardization, “ISO 8601-1:2019/Amd 1:2022. Date and time - Representations for information interchange - Part 1: Basic rules,” October 2022.</span><span>)</span></a> [ISO8601‑1] <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 IANA Time Zone Database <a class='info' href='#IANA.time-zones'>[IANA.time‑zones]<span> (</span><span class='info'>IANA, “Time Zone Database,” .</span><span>)</span></a> 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., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tag. This is typically an <a class='info' href='#ISO639'>ISO 639 Alpha-2<span> (</span><span class='info'>International Organization for Standardization, “ISO 639:2023. Code for individual languages and language groups,” November 2023.</span><span>)</span></a> [ISO639] 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:2020. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” August 2020.</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='#RFC8259'>[RFC8259]<span> (</span><span class='info'>Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” December 2017.</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-01T00:00:00Z as measured in UTC until the date/time. </td> </tr> </table> <br clear="all" /> <table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Table 1: Registered Member Definitions </b></font><br /></td></tr></table><hr class="insert" /> <a name="AddressClaim"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.5.1.1"></a><h3>5.1.1.  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 represent the same address, with the formatted address indicating how the component fields are combined. </p> <p> All the address values defined below are represented as JSON strings. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed. and M. Davis, Ed., “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 name 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 IANA "Language Subtag Registry" <a class='info' href='#IANA.Language'>[IANA.Language]<span> (</span><span class='info'>IANA, “Language Subtag Registry,” .</span><span>)</span></a>. 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., Ed. and M. Davis, Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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='#RFC7231'>RFC 7231<span> (</span><span class='info'>Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.</span><span>)</span></a> [RFC7231]. </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 JavaScript Clients and other Browser-Based Clients to access it. </p> <a name="UserInfoRequest"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.5.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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. It is not an error condition to not return a requested Claim. </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,” December 2023.</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),” May 2015.</span><span>)</span></a>. </p> <p> If signed, the UserInfo Response MUST contain the Claims <tt>iss</tt> (issuer) and <tt>aud</tt> (audience) as members. The <tt>iss</tt> value MUST be the OP's Issuer Identifier URL. The <tt>aud</tt> value MUST 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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: Bearer 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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> 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> </p> <p> Other members MAY be present. Any members used that are not understood MUST be ignored. </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 specific combinations of 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. An equality comparison is used to determine whether the requested Claim value matches. </dd> <dt></dt> <dd> When the Claim value does not match the requested value, the Claim is not included in the response. If the Claim was <tt>sub</tt>, a mismatch MUST cause the authentication to fail, as described in <a class='info' href='#AuthRequestValidation'>Section 3.1.2.2<span> (</span><span class='info'>Authentication Request Validation</span><span>)</span></a>. </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. This is processed equivalently to a <tt>value</tt> request, except that a choice of acceptable Claim values is provided. </dd> <dt></dt> <dd> 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. An equality comparison is used to determine whether the requested Claim values match. </dd> <dt></dt> <dd> When the Claim value does not match any of the requested values, the Claim is not included in the response. </dd> </dl></blockquote> </dd> <dt></dt> <dd> 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> 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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>value</tt> or <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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed. and M. Davis, Ed., “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 does not have, any versions of those Claims returned that do not 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> { "sub": "248289761001", "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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. The OP MAY omit some Claims available from referenced Claims Providers from the set of Claim Names. </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),” May 2015.</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> Since it is not an error condition to not return a requested Claim, RPs MUST be prepared to handle the condition that some Claims listed in <tt>_claim_sources</tt> are not returned from the Claims Provider. They SHOULD treat this the same as when any other requested Claim is not returned. </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> An <tt>iss</tt> (issuer) Claim SHOULD be included in any JWT issued by a Claims Provider so that the Claims Provider's keys can be retrieved for signature validation of the JWT. The value of the Claim is the Claims Provider's Issuer Identifier URL. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> In this example, these Claims about Jane Doe have been issued by Claims Provider A. (The example also includes the Claims Provider's Issuer Identifier URL.) </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> { "iss": "https://a.example.com", "address": { "street_address": "1234 Hollywood Blvd.", "locality": "Los Angeles", "region": "CA", "postal_code": "90210", "country": "United States of America"}, "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> 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> { "sub": "248289761001", "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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> In this example, these Claims about Jane Doe are held by Claims Provider B (Jane Doe's bank). (The example also includes the Claims Provider's Issuer Identifier URL.) </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> { "iss": "https://bank.example.com", "shipping_address": { "street_address": "1234 Hollywood Blvd.", "locality": "Los Angeles", "region": "CA", "postal_code": "90210", "country": "United States of America"}, "payment_info": "Some_Card 1234 5678 9012 3456", "phone_number": "+1 (310) 123-4567" } </pre></div> <p> <p> Also in this example, this Claim about Jane Doe is held by Claims Provider C (a credit agency). (The example also includes the Claims Provider's Issuer Identifier URL.) </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> { "iss": "https://creditagency.example.com", "credit_score": 650 } </pre></div> <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> { "sub": "248289761001", "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> <p> Note that not returning <tt>phone_number</tt>, which is held by Claims Provider B, demonstrates that not all Claims held by a utilized Claims Provider need be included. </p> <a name="ClaimStability"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.5.7"></a><h3>5.7.  Claim Stability and Uniqueness</h3> <p> The <tt>sub</tt> (subject) and <tt>iss</tt> (issuer) Claims from the ID Token, 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>, <tt>preferred_username</tt>, and <tt>name</tt> MUST NOT be used as unique identifiers for the End-User, whether obtained from the ID Token or the UserInfo Endpoint. </p> <a name="JWTRequests"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6"></a><h3>6.  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 referencing a resource containing a Request Object value, which is a JWT containing the request parameters. This URL MUST use the <tt>https</tt> scheme unless the target Request Object is signed in a way that is verifiable by the OP. </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> <p> Note that the Request Objects defined here are compatible with those specified by <a class='info' href='#RFC9101'>The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)<span> (</span><span class='info'>Sakimura, N., Bradley, J., and M. Jones, “The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR),” August 2021.</span><span>)</span></a> [RFC9101]. </p> <a name="RequestObject"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6.1"></a><h3>6.1.  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 (unsecured). When it is unsecured, 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),” May 2015.</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. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.</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),” May 2015.</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> 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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>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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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 SHOULD 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>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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6.2.1"></a><h3>6.2.1.  URI 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.</span><span>)</span></a> [JWE] specification. The result MAY be either a signed or unsigned (unsecured) 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.7.3"></a><h3>7.3.  Self-Issued OpenID Provider Request</h3> <p> The self-issued OP's Authorization Endpoint is the URI <tt>openid:</tt>. </p> <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>. Encrypting content to Self-Issued OPs is not supported. </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>. Encrypting content to Self-Issued OPs is not supported. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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 whitespace 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. and N. Sakimura, “JSON Web Key (JWK) Thumbprint,” September 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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-issued.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),” May 2015.</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> 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 MUST 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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 re-register 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,” December 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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., Ed., “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,” May 2015.</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,” May 2015.</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 JWT 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,” May 2015.</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,” May 2015.</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,” May 2015.</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,” May 2015.</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,” May 2015.</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 JWT 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,” May 2015.</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,” May 2015.</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,” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.</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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 the left-most bits of a 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 truncated retaining the left-most bits 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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='#RFC7234'>RFC 7234<span> (</span><span class='info'>Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching,” June 2014.</span><span>)</span></a> [RFC7234], 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 offline access when the registered <tt>application_type</tt> is <tt>web</tt>, </li> <li> SHOULD explicitly receive or have consent for offline access 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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> if the implementation is using extensions (which are beyond the scope of this specification) that result in the <tt>azp</tt> (authorized party) Claim being present, those extensions might specify that its <tt>azp</tt> Claim Value MUST be the same as in the ID Token issued when the original authentication occurred; likewise, they might specify that if no <tt>azp</tt> Claim was present in the original ID Token, one MUST NOT be present in the new ID Token, </li> <li> it SHOULD NOT have a <tt>nonce</tt> Claim, even when the ID Token issued at the time of the original authentication contained <tt>nonce</tt>; however, if it is present, its value MUST be the same as in the ID Token issued at the time of the original authentication, 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 { "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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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.SPSD-html401-20180327'>[W3C.SPSD‑html401‑20180327]<span> (</span><span class='info'>, “HTML 4.01 Specification,” March 2018.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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.SPSD-html401-20180327'>[W3C.SPSD‑html401‑20180327]<span> (</span><span class='info'>, “HTML 4.01 Specification,” March 2018.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 <a class='info' href='#UNICODE'>[UNICODE]<span> (</span><span class='info'>The Unicode Consortium, “The Unicode Standard,” .</span><span>)</span></a> 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'>Whistler, K., “Unicode Normalization Forms,” August 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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,” December 2023.</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='#RequestUriParameter'>Section 6.2<span> (</span><span class='info'>Passing a Request Object by Reference</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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,” December 2023.</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,” December 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 and other Browser-Based 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.15.6"></a><h3>15.6.  Compatibility Notes</h3> <p> NOTE: Potential compatibility issues that were previously described in the original version of this specification have since been addressed. </p> <a name="RelatedSpecs"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.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,” December 2023.</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,” December 2023.</span><span>)</span></a> [OpenID.Registration] - Defines how Relying Parties dynamically register with OpenID Providers </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,” April 2015.</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> <li> <a class='info' href='#OpenID.RPInitiated'>OpenID Connect RP-Initiated Logout 1.0<span> (</span><span class='info'>Jones, M., de Medeiros, B., Agarwal, N., Sakimura, N., and J. Bradley, “OpenID Connect RP-Initiated Logout 1.0,” September 2022.</span><span>)</span></a> [OpenID.RPInitiated] - Defines how a Relying Party requests that an OpenID Provider log out the End-User </li> <li> <a class='info' href='#OpenID.Session'>OpenID Connect Session Management 1.0<span> (</span><span class='info'>de Medeiros, B., Agarwal, N., Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Session Management 1.0,” September 2022.</span><span>)</span></a> [OpenID.Session] - Defines how to manage OpenID Connect sessions, including postMessage-based logout and RP-initiated logout functionality </li> <li> <a class='info' href='#OpenID.FrontChannel'>OpenID Connect Front-Channel Logout 1.0<span> (</span><span class='info'>Jones, M., “OpenID Connect Front-Channel Logout 1.0,” September 2022.</span><span>)</span></a> [OpenID.FrontChannel] - Defines a front-channel logout mechanism that does not use an OP iframe on RP pages </li> <li> <a class='info' href='#OpenID.BackChannel'>OpenID Connect Back-Channel Logout 1.0<span> (</span><span class='info'>Jones, M. and J. Bradley, “OpenID Connect Back-Channel Logout 1.0,” December 2023.</span><span>)</span></a> [OpenID.BackChannel] - Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out </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,” December 2023.</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,” December 2023.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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., Ed., 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,” April 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 its integrity is intact. </p> <a name="AccessTokenRedirect"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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., Ed., “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>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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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),” May 2015.</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. Implementations SHOULD follow the guidance in BCP 195 <a class='info' href='#RFC8996'>[RFC8996]<span> (</span><span class='info'>Moriarty, K. and S. Farrell, “Deprecating TLS 1.0 and TLS 1.1,” March 2021.</span><span>)</span></a> <a class='info' href='#RFC9325'>[RFC9325]<span> (</span><span class='info'>Sheffer, Y., Saint-Andre, P., and T. Fossati, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” November 2022.</span><span>)</span></a>, which provides recommendations and requirements for improving the security of deployed services that use TLS. </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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="HTTP307Redirects"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.16.22"></a><h3>16.22.  HTTP 307 Redirects</h3> <p> HTTP 307 redirects send a POST request to the party being redirected to that contains all the form data from the previous request. This can leak credentials intended for the OpenID Provider to the Relying Party. Therefore, HTTP 307 redirects MUST NOT be used when redirecting to the Redirection URI. Likewise, while HTTP 302 redirects are typically implemented in a way that does not do this, the use of HTTP 303 redirect is preferable, as it is defined not to do this. </p> <a name="iOSCustomSchemes"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.16.23"></a><h3>16.23.  Custom URI Schemes on iOS</h3> <p> Note that on iOS, multiple applications can register as handlers for a custom URI scheme, therefore it is not deterministic that the calling application will receive the Authentication Reply from the Self-Issued OpenID Provider. Use of a claimed URI is an alternative to using the <tt>openid:</tt> custom URI scheme. </p> <p> While it is possible to assign handlers to custom URI schemes and it is possible that the operating system could help the End-User select the correct handler, it is not possible to guarantee that the handler for a given custom URI scheme has not been replaced by a subsequently installed native application. At the time of this writing, there appears to be no fool-proof mitigation for this vulnerability. </p> <a name="Privacy"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.17"></a><h3>17.  Privacy Considerations</h3> <a name="PII"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.17.3"></a><h3>17.3.  Correlation</h3> <p>To protect the End-User from 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.18.1"></a><h3>18.1.  JSON Web Token Claims Registration</h3> <p> This specification registers the following Claims in the IANA "JSON Web Token Claims" registry <a class='info' href='#IANA.JWT.Claims'>[IANA.JWT.Claims]<span> (</span><span class='info'>IANA, “JSON Web Token Claims,” .</span><span>)</span></a> established by <a class='info' href='#JWT'>[JWT]<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.</span><span>)</span></a>. </p> <a name="ClaimsContents"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </li> </ul><p> </p> <p> </p> <ul class="text"> <li> Claim Name: <tt>_claim_names</tt> </li> <li> Claim Description: JSON object whose member names are the Claim Names for the Aggregated and Distributed Claims </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='#AggregatedDistributedClaims'>Section 5.6.2<span> (</span><span class='info'>Aggregated and Distributed Claims</span><span>)</span></a> of this specification </li> </ul><p> </p> <p> </p> <ul class="text"> <li> Claim Name: <tt>_claim_sources</tt> </li> <li> Claim Description: JSON object whose member names are referenced by the member values of the <tt>_claim_names</tt> member </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='#AggregatedDistributedClaims'>Section 5.6.2<span> (</span><span class='info'>Aggregated and Distributed Claims</span><span>)</span></a> of this specification </li> </ul><p> </p> <a name="OAuthParametersRegistry"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.18.2"></a><h3>18.2.  OAuth Parameters Registration</h3> <p> This specification registers the following parameters in the IANA "OAuth Parameters" registry <a class='info' href='#IANA.OAuth.Parameters'>[IANA.OAuth.Parameters]<span> (</span><span class='info'>IANA, “OAuth Parameters,” .</span><span>)</span></a> established by <a class='info' href='#RFC6749'>RFC 6749<span> (</span><span class='info'>Hardt, D., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 <a class='info' href='#IANA.OAuth.Parameters'>[IANA.OAuth.Parameters]<span> (</span><span class='info'>IANA, “OAuth Parameters,” .</span><span>)</span></a> established by <a class='info' href='#RFC6749'>RFC 6749<span> (</span><span class='info'>Hardt, D., Ed., “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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </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 specification </li> </ul><p> </p> <a name="URISchemeRegistry"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.18.4"></a><h3>18.4.  URI Scheme Registration</h3> <p> This specification registers the following URI scheme in the IANA "Uniform Resource Identifier (URI) Schemes" registry <a class='info' href='#IANA.URISchemes'>[IANA.URISchemes]<span> (</span><span class='info'>IANA, “Uniform Resource Identifier (URI) Schemes,” .</span><span>)</span></a> established by <a class='info' href='#RFC7595'>RFC 7595<span> (</span><span class='info'>Thaler, D., Ed., Hansen, T., and T. Hardie, “Guidelines and Registration Procedures for URI Schemes,” June 2015.</span><span>)</span></a> [RFC7595]. </p> <a name="URISchemeContents"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.18.4.1"></a><h3>18.4.1.  Registry Contents</h3> <p> </p> <ul class="text"> <li>Scheme name: <tt>openid</tt> </li> <li>Status: Permanent </li> <li>Applications/protocols that use this scheme name: OpenID Connect </li> <li>Contact: Michael B. Jones - michael_b_jones@hotmail.com </li> <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net </li> <li>References: <a class='info' href='#SelfIssuedRequest'>Section 7.3<span> (</span><span class='info'>Self-Issued OpenID Provider Request</span><span>)</span></a> of this specification </li> </ul><p> </p> <a name="rfc.references"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.19"></a><h3>19.  References</h3> <a name="rfc.references1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>19.1. Normative References</h3> <table width="99%" border="0"> <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="https://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.AMR">[IANA.AMR]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/assignments/authentication-method-reference-values">Authentication Method Reference Values</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="IANA.JWT.Claims">[IANA.JWT.Claims]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/assignments/jwt">JSON Web Token Claims</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="IANA.Language">[IANA.Language]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/assignments/language-subtag-registry">Language Subtag Registry</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="IANA.OAuth.Parameters">[IANA.OAuth.Parameters]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/assignments/oauth-parameters">OAuth Parameters</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="IANA.URISchemes">[IANA.URISchemes]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/assignments/uri-schemes">Uniform Resource Identifier (URI) Schemes</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="IANA.time-zones">[IANA.time-zones]</a></td> <td class="author-text">IANA, “<a href="https://www.iana.org/time-zones">Time Zone Database</a>.”</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="https://www.iso.org/standard/45138.html">ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework</a>,” ISO/IEC 29115:2013, April 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="https://www.iso.org/standard/72482.html">ISO 3166-1:2020. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes</a>,” August 2020.</td></tr> <tr><td class="author-text" valign="top"><a name="ISO639">[ISO639]</a></td> <td class="author-text">International Organization for Standardization, “<a href="https://www.iso.org/standard/74575.html">ISO 639:2023. Code for individual languages and language groups</a>,” November 2023.</td></tr> <tr><td class="author-text" valign="top"><a name="ISO8601-1">[ISO8601-1]</a></td> <td class="author-text">International Organization for Standardization, “<a href="https://www.iso.org/standard/81801.html">ISO 8601-1:2019/Amd 1:2022. Date and time - Representations for information interchange - Part 1: Basic rules</a>,” October 2022.</td></tr> <tr><td class="author-text" valign="top"><a name="JWA">[JWA]</a></td> <td class="author-text">Jones, M., “<a href="https://www.rfc-editor.org/info/rfc7518">JSON Web Algorithms (JWA)</a>,” RFC 7518, DOI 10.17487/RFC7518, May 2015.</td></tr> <tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td> <td class="author-text">Jones, M. and J. Hildebrand, “<a href="https://www.rfc-editor.org/info/rfc7516">JSON Web Encryption (JWE)</a>,” RFC 7516, DOI 10.17487/RFC7516, May 2015.</td></tr> <tr><td class="author-text" valign="top"><a name="JWK">[JWK]</a></td> <td class="author-text">Jones, M., “<a href="https://www.rfc-editor.org/info/rfc7517">JSON Web Key (JWK)</a>,” RFC 7517, DOI 10.17487/RFC7517, May 2015.</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="https://www.rfc-editor.org/info/rfc7515">JSON Web Signature (JWS)</a>,” RFC 7515, DOI 10.17487/RFC7515, May 2015.</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="https://www.rfc-editor.org/info/rfc7519">JSON Web Token (JWT)</a>,” RFC 7519, DOI 10.17487/RFC7519, May 2015.</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="https://www.rfc-editor.org/info/rfc7521">Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants</a>,” RFC 7521, DOI 10.17487/RFC7521, May 2015.</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="https://www.rfc-editor.org/info/rfc7523">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</a>,” RFC 7523, DOI 10.17487/RFC7523, May 2015.</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="https://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="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” December 2023.</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="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client Registration 1.0</a>,” December 2023.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC20">[RFC20]</a></td> <td class="author-text">Cerf, V., “<a href="https://www.rfc-editor.org/info/rfc20">ASCII format for Network Interchange</a>,” STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td> <td class="author-text">Bradner, S., “<a href="https://www.rfc-editor.org/info/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td> <td class="author-text">Klyne, G. and C. Newman, “<a href="https://www.rfc-editor.org/info/rfc3339">Date and Time on the Internet: Timestamps</a>,” RFC 3339, DOI 10.17487/RFC3339, July 2002.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td> <td class="author-text">Yergeau, F., “<a href="https://www.rfc-editor.org/info/rfc3629">UTF-8, a transformation format of ISO 10646</a>,” STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3966">[RFC3966]</a></td> <td class="author-text">Schulzrinne, H., “<a href="https://www.rfc-editor.org/info/rfc3966">The tel URI for Telephone Numbers</a>,” RFC 3966, DOI 10.17487/RFC3966, December 2004.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td> <td class="author-text">Berners-Lee, T., Fielding, R., and L. Masinter, “<a href="https://www.rfc-editor.org/info/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,” STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC5322">[RFC5322]</a></td> <td class="author-text">Resnick, P., Ed., “<a href="https://www.rfc-editor.org/info/rfc5322">Internet Message Format</a>,” RFC 5322, DOI 10.17487/RFC5322, October 2008.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC5646">[RFC5646]</a></td> <td class="author-text">Phillips, A., Ed. and M. Davis, Ed., “<a href="https://www.rfc-editor.org/info/rfc5646">Tags for Identifying Languages</a>,” BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.</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="https://www.rfc-editor.org/info/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, DOI 10.17487/RFC6125, March 2011.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC6711">[RFC6711]</a></td> <td class="author-text">Johansson, L., “<a href="https://www.rfc-editor.org/info/rfc6711">An IANA Registry for Level of Assurance (LoA) Profiles</a>,” RFC 6711, DOI 10.17487/RFC6711, August 2012.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td> <td class="author-text">Hardt, D., Ed., “<a href="https://www.rfc-editor.org/info/rfc6749">The OAuth 2.0 Authorization Framework</a>,” RFC 6749, DOI 10.17487/RFC6749, October 2012.</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="https://www.rfc-editor.org/info/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>,” RFC 6750, DOI 10.17487/RFC6750, October 2012.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC6819">[RFC6819]</a></td> <td class="author-text">Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “<a href="https://www.rfc-editor.org/info/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>,” RFC 6819, DOI 10.17487/RFC6819, January 2013.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC7230">[RFC7230]</a></td> <td class="author-text">Fielding, R., Ed. and J. Reschke, Ed., “<a href="https://www.rfc-editor.org/info/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>,” RFC 7230, DOI 10.17487/RFC7230, June 2014.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC7231">[RFC7231]</a></td> <td class="author-text">Fielding, R., Ed. and J. Reschke, Ed., “<a href="https://www.rfc-editor.org/info/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>,” RFC 7231, DOI 10.17487/RFC7231, June 2014.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC7234">[RFC7234]</a></td> <td class="author-text">Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “<a href="https://www.rfc-editor.org/info/rfc7234">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>,” RFC 7234, DOI 10.17487/RFC7234, June 2014.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC8176">[RFC8176]</a></td> <td class="author-text">Jones, M., Hunt, P., and A. Nadalin, “<a href="https://www.rfc-editor.org/info/rfc8176">Authentication Method Reference Values</a>,” RFC 8176, DOI 10.17487/RFC8176, June 2017.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC8259">[RFC8259]</a></td> <td class="author-text">Bray, T., Ed., “<a href="https://www.rfc-editor.org/info/rfc8259">The JavaScript Object Notation (JSON) Data Interchange Format</a>,” STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC8996">[RFC8996]</a></td> <td class="author-text">Moriarty, K. and S. Farrell, “<a href="https://www.rfc-editor.org/info/rfc8996">Deprecating TLS 1.0 and TLS 1.1</a>,” BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC9325">[RFC9325]</a></td> <td class="author-text">Sheffer, Y., Saint-Andre, P., and T. Fossati, “<a href="https://www.rfc-editor.org/info/rfc9325">Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</a>,” BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022.</td></tr> <tr><td class="author-text" valign="top"><a name="UNICODE">[UNICODE]</a></td> <td class="author-text">The Unicode Consortium, “<a href="http://www.unicode.org/versions/latest/">The Unicode Standard</a>.”</td></tr> <tr><td class="author-text" valign="top"><a name="USA15">[USA15]</a></td> <td class="author-text">Whistler, K., “<a href="https://www.unicode.org/reports/tr15/">Unicode Normalization Forms</a>,” Unicode Standard Annex 15, August 2023.</td></tr> <tr><td class="author-text" valign="top"><a name="W3C.SPSD-html401-20180327">[W3C.SPSD-html401-20180327]</a></td> <td class="author-text">“<a href="https://www.w3.org/TR/2018/SPSD-html401-20180327/">HTML 4.01 Specification</a>,” W3C REC SPSD-html401-20180327, W3C SPSD-html401-20180327, March 2018.</td></tr> </table> <a name="rfc.references2"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>19.2. Informative References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><a name="JWK.Thumbprint">[JWK.Thumbprint]</a></td> <td class="author-text">Jones, M. and N. Sakimura, “<a href="https://www.rfc-editor.org/info/rfc7638">JSON Web Key (JWK) Thumbprint</a>,” RFC 7638, DOI 10.17487/RFC7638, September 2015.</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="https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">OAuth 2.0 Form Post Response Mode</a>,” April 2015.</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, “<a href="https://openid.net/specs/openid-authentication-2_0.html">OpenID Authentication 2.0</a>,” December 2007.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.BackChannel">[OpenID.BackChannel]</a></td> <td class="author-text">Jones, M. and J. Bradley, “<a href="https://openid.net/specs/openid-connect-backchannel-1_0.html">OpenID Connect Back-Channel Logout 1.0</a>,” December 2023.</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="https://openid.net/specs/openid-connect-basic-1_0.html">OpenID Connect Basic Client Implementer's Guide 1.0</a>,” December 2023.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.Core.Errata1">[OpenID.Core.Errata1]</a></td> <td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a href="https://openid.net/specs/openid-connect-core-1_0-errata1.html">OpenID Connect Core 1.0 incorporating errata set 1</a>,” November 2014.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.Core.Final">[OpenID.Core.Final]</a></td> <td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a href="https://openid.net/specs/openid-connect-core-1_0-final.html">OpenID Connect Core 1.0 (final)</a>,” February 2014.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.FrontChannel">[OpenID.FrontChannel]</a></td> <td class="author-text">Jones, M., “<a href="https://openid.net/specs/openid-connect-frontchannel-1_0.html">OpenID Connect Front-Channel Logout 1.0</a>,” September 2022.</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="https://openid.net/specs/openid-connect-implicit-1_0.html">OpenID Connect Implicit Client Implementer's Guide 1.0</a>,” December 2023.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.PAPE">[OpenID.PAPE]</a></td> <td class="author-text">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “<a href="https://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID Provider Authentication Policy Extension 1.0</a>,” December 2008.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.RPInitiated">[OpenID.RPInitiated]</a></td> <td class="author-text">Jones, M., de Medeiros, B., Agarwal, N., Sakimura, N., and J. Bradley, “<a href="https://openid.net/specs/openid-connect-rpinitiated-1_0.html">OpenID Connect RP-Initiated Logout 1.0</a>,” September 2022.</td></tr> <tr><td class="author-text" valign="top"><a name="OpenID.Session">[OpenID.Session]</a></td> <td class="author-text">de Medeiros, B., Agarwal, N., Sakimura, N., Bradley, J., and M. Jones, “<a href="https://openid.net/specs/openid-connect-session-1_0.html">OpenID Connect Session Management 1.0</a>,” September 2022.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC4949">[RFC4949]</a></td> <td class="author-text">Shirey, R., “<a href="https://www.rfc-editor.org/info/rfc4949">Internet Security Glossary, Version 2</a>,” FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC7595">[RFC7595]</a></td> <td class="author-text">Thaler, D., Ed., Hansen, T., and T. Hardie, “<a href="https://www.rfc-editor.org/info/rfc7595">Guidelines and Registration Procedures for URI Schemes</a>,” BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC9101">[RFC9101]</a></td> <td class="author-text">Sakimura, N., Bradley, J., and M. Jones, “<a href="https://www.rfc-editor.org/info/rfc9101">The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</a>,” RFC 9101, DOI 10.17487/RFC9101, August 2021.</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="https://www.itu.int/SG-CP/example_docs/ITU-T-REC/ITU-T-REC_E.pdf">ITU-T Recommendation X.1252 - Cyberspace security - Identity management - Baseline identity management terms and definitions</a>,” ITU-T X.1252, April 2010.</td></tr> </table> <a name="AuthorizationExamples"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.A"></a><h3>Appendix A.  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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx MjgwOTcwLAogIm5hbWUiOiAiSmFuZSBEb2UiLAogImdpdmVuX25hbWUiOiAiSmFu ZSIsCiAiZmFtaWx5X25hbWUiOiAiRG9lIiwKICJnZW5kZXIiOiAiZmVtYWxlIiwK ICJiaXJ0aGRhdGUiOiAiMDAwMC0xMC0zMSIsCiAiZW1haWwiOiAiamFuZWRvZUBl eGFtcGxlLmNvbSIsCiAicGljdHVyZSI6ICJodHRwOi8vZXhhbXBsZS5jb20vamFu ZWRvZS9tZS5qcGciCn0. NTibBYW_ZoNHGm4ZrWCqYA9oJaxr1AVrJCze6FEcac4t_EOQiJFbD2nVEPkUXPuM shKjjTn7ESLIFUnfHq8UKTGibIC8uqrBgQAcUQFMeWeg-PkLvDTHk43Dn4_aNrxh mWwMNQfkjqx3wd2Fvta9j8yG2Qn790Gwb5psGcmBhqMJUUnFrGpyxQDhFIzzodmP okM7tnUxBNj-JuES_4CE-BvZICH4jKLp0TMu-WQsVst0ss-vY2RPdU1MzL59mq_e Kk8Rv9XhxIr3WteA2ZlrgVyT0cwH3hlCnRUsLfHtIEb8k1Y_WaqKUu3DaKPxqRi6 u0rN7RO2uZYPzC454xe-mg &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-PKCS1-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": "https://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),” May 2015.</span><span>)</span></a>. </p> <a name="id_token-tokenExample"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.A.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. ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIKfQ. kdqTmftlaXg5WBYBr1wkxhkqCGZPc0k8vTiV5g2jj67jQ7XkrDamYx2bOkZLdZrp MPIzkdYB1nZI_G8vQGQuamRhJcEIt21kblGPZ-yhEhdkAiZIZLu38rChalDS2Mh0 glE_rke5XXRhmqqoEFFdziFdnO3p61-7y51co84OEAZvARSINQaOWIzvioRfs4zw IFOaT33Vpxfqr8HDyh31zo9eBW2dSQuCa071z0ENWChWoPliK1JCo_Bk9eDg2uwo 2ZwhsvHzj6TMQ0lYOTzufSlSmXIKfjlOsb3nftQeR697_hA-nMZyAdL8_NRfaC37 XnAbW8WB9wCfECp7cuNuOg &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": "https://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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx MjgwOTcwLAogImNfaGFzaCI6ICJMRGt0S2RvUWFrM1BrMGNuWHhDbHRBIgp9. MRPihYtNIcwKTZ_mcMSPfreVytGR4jfl1Tzbv4tH5Jr4WqONs2lUWrIEpZ2joKbZ fAGlouAqwqSYpfR3FQYKYvdgnZ3kjIJ_5M4fAARXHVSciGyhfqB-OhDUMXSHzFHi GKNY9TKSgRfiXf_314WRujpqaDtj2uoXbppobYXvAZIxWtsOein0-t91LDS39EW4 frNWAopKTBBi_XJPlpLVynWTDvNleEBP6UxIMgYJBKlqsP7RGfHTGk3ReXDacR7R GZlIVGa-0qRyDzvNqD7xfu9aYufUP0oBGqdBGgFVNmwJ7rmB0gdPtC2eJsXq9svC gBBfhRQZxhx1iLJjNc9nSw &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": "https://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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIsCiAi Y19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEEiCn0. A2OhhJzbUNaCbNLqNaqetGLJoxB3ujVbq_HLYSOWgWCJ3-B__YxlqIg8gpeL0Vhv rWX0mwz7w_pGTRN4JdgsI0xAlT5fob1ZPnrazgonSyzaXcg2bgD896SsBSlG_8JX 6JKaztXifn8k2gy65Me-sMyQrRF8xv_q1CeC871sZpMjJzy5nx65BTI17vcXjntZ HADv6o2CrHrEdHp8xSlnTLiiIqgDOmKlpkeqqOBK6dqa4rXZlSqMAUm1LYZmtb2D 8sHvQsxTbWlBkX7VZaTSqMJ487s4ZIEea8Bw4KGVOntQue4VhBjBnQ4bQKhB_47D xlWpSyOWdy3cer_zxKrfvw &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": "https://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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 (Naveen.Agarwal@microsoft.com), Microsoft (was at Google) </p> <p>Amanda Anganes (aanganes@mitre.org), MITRE </p> <p>Casper Biering (cb@peercraft.com), Peercraft </p> <p>John Bradley (ve7jtb@ve7jtb.com), Yubico (was at Ping Identity) </p> <p>Tim Bray (tbray@textuality.com), independent (was at Google) </p> <p>Johnny Bufu (johnny.bufu@gmail.com), independent (was at 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 (Pamela.Dingle@microsoft.com), Microsoft (was at Ping Identity) </p> <p>Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id (was at Nimbus Directory Services) </p> <p>George Fletcher (gffletch@aol.com), Capital One (was at AOL) </p> <p>Roland Hedberg (roland@catalogix.se), independent (was at University of Umeå) </p> <p>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc. </p> <p>Edmund Jay (ejay@mgi1.com), Illumila </p> <p>Michael B. Jones (michael_b_jones@hotmail.com), Self-Issued Consulting (was at Microsoft) </p> <p>Torsten Lodderstedt (torsten@lodderstedt.net), independent (was at Deutsche Telekom) </p> <p>James Manger (James.H.Manger@team.telstra.com), Telstra </p> <p>Nov Matake (nov@matake.jp), independent </p> <p>Chuck Mortimore (charliemortimore@gmail.com), Disney (was at Salesforce) </p> <p>Anthony Nadalin (nadalin@prodigy.net), independent (was at 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 (recordond@gmail.com), independent (was at Facebook) </p> <p>Justin Richer (justin@bspk.io), Bespoke Engineering (was at MITRE) </p> <p>Nat Sakimura (nat@nat.consulting), NAT.Consulting (was at NRI) </p> <p>Luke Shepard (luke@lukeshepard.com), Facebook </p> <p>Andreas Åkre Solberg (Andreas.Solberg@sikt.no), Sikt (was at UNINET) </p> <p>Paul Tarjan (paul@paultarjan.com), Facebook </p> </blockquote><p> </p> <a name="Notices"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.C"></a><h3>Appendix C.  Notices</h3> <p>Copyright (c) 2023 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>Authors' Addresses</h3> <table width="99%" border="0" cellpadding="0" cellspacing="0"> <tr><td class="author-text"> </td> <td class="author-text">Nat Sakimura</td></tr> <tr><td class="author-text"> </td> <td class="author-text">NAT.Consulting</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:nat@nat.consulting">nat@nat.consulting</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="https://nat.sakimura.org/">https://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">Yubico</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">Self-Issued Consulting</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:michael_b_jones@hotmail.com">michael_b_jones@hotmail.com</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="https://self-issued.info/">https://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="https://stackoverflow.com/users/311376/breno">https://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">Disney</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:charliemortimore@gmail.com">charliemortimore@gmail.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> </table> </body></html>