!!! Overview
[{$pagename}] ([OIDC]) is an interoperable [Authentication] [Protocol] based on the [OAuth 2.0] family of specifications provided by the [OpenID Foundation]

[{$pagename}] uses straightforward [REST]/[JSON] message flows with a design goal of "making simple things simple and complicated things possible". 

[{$pagename}] is uniquely easy for developers to integrate, compared to any preceding Identity protocol.

[{$pagename}] lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, [{$pagename}] provides a secure verifiable, answer to the question "What is the identity of the person currently using the browser or native app that is connected to me?"

[{$pagename}] allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.

[{$pagename}] is ideally suited for [WEB Access Management].

[{$pagename}] is an standard that profiles and extends [OAuth 2.0] to add an identity layer – creating a single framework that promises to secure [API]s, mobile native applications, and browser applications in a single, cohesive architecture.


!! [{$pagename}] Identity
[{$pagename}] adds two notable identity constructs to [OAuth 2.0]'s token issuance model.
* an [Identity Token] - the delivery of which from one party to another can enable a [Federated Identity] [SSO|OIDC SSO] user experience
* a [standardized identity attribute API|Userinfo_endpoint] - at which a client can retrieve desired identity attributes for a given user.

!! [{$pagename}] provides the [Relying Party] answers to these Questions:
* Who is the [Digital Identity] that performed the [Authentication]
* Where did the [Authentication] take place (ie What [Identity Provider (IDP)]
* When was the [Digital Identity] [Authentication] process.
* How was the [Digital Identity] [Authentication] performed
* What [Digital Identity] Attributes are available to you
* Why did the [Digital Identity] provide access to the attributes

!! [{$pagename}] Libraries
[{$pagename}] ([OpenID Connect Core 1.0]) [Specification] is 86 pages of technical jargon not counting the many extensions and references. Not using [{$pagename}] [libraries|Software library] and trying to roll your own is not correct thinking.
Use the [OpenID Connect Client] [libraries|Software library] or a "Known Good" implementation created by experts.

!! Relationship to [OAuth 2.0]
[{$pagename}] provides identity semantics and constructs on top of [OAuth 2.0] by logically adding layers onto the [OAuth 2.0] base as opposed to other non-identity centric applications that are possible with [OAuth 2.0].

The [{$pagename}] specification uses the terms:
* [Access Token]
* [Authorization Code]
* [Authorization_endpoint]
* [Authorization Grant]
* [Authorization Server]
* [Client|OAuth Client]
* [Client_id]
* [Client Secret]
* [Grant Type]
* [Protected Resource]
* [Redirect_uri]
* [Refresh Token]
* [Resource Owner]
* [Resource Server]
* [Response_type]
* [Token_endpoint]
as defined by [OAuth 2.0] [RFC 6749]

[{$pagename}] terms:
* [Claim Name|JSON Web Token Claims]
* [Claim Value|JWT Claim Value]
* [JSON Web Token] ([JWT])
* [JWT Claims Set]
* [Nested JWT]
as defined by [JSON Web Token] ([JWT])

[{$pagename}] terms as defined by [JSON Web Signature] ([JWS]) 
* [JOSE Header Parameter]
* [JOSE Header]

[{$pagename}] term [User-agent] defined by [RFC 2616] 

[{$pagename}] term [Response_mode] defined by [OAuth 2.0 Multiple Response Type Encoding Practices]

[{$pagename}] introduces notable identity constructs on top of the [OAuth 2.0] base protocol:
* Defined [OAuth Scopes] - OpenID, Profile, email, address, phone
* [Identity Token] 
* [UserInfo Endpoint|Userinfo_endpoint]
* [Openid-configuration] [Endpoint] - Makes available configuration information that describes the Connect Authorization Server.



[{$pagename}] Leverages other emerging technologies
* Allows choice of [Identity Provider (IDP)]
* [REST]/[JSON] Friendly:
** [JSON Web Tokens] 
** [JSON Web Signature]
** [Simple Web Discovery]
** [WebFinger]
* Can provide [Level Of Assurance]
* Implements [User Managed Access|User-Managed Access]

Set to be adopted by Facebook, Google, and others

!! [{$pagename}] Flows
There are several [{$pagename}] Flows
* [OpenID Connect Authorization Flow]
* [OpenID Connect Implicit Flow]
* [OpenID Connect Optional Steps]

This is a General Diagram of [{$pagename}] Flows:

[{Image src='/images/OpenID Connect Flow.png' caption='Bar Code' align ='left' style='font-size: 120%;'}]
\\


!! [OpenID Connect Endpoints]


!! [{$pagename}] Documents
* [OpenID Connect Core 1.0 incorporating errata set 1|http://openid.net/specs/openid-connect-core-1_0.html|target='_blank']
* [OpenID Connect Discovery 1.0 incorporating errata set 1|http://openid.net/specs/openid-connect-discovery-1_0.html|target='_blank']
* [OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1|http://openid.net/specs/openid-connect-registration-1_0.html|target='_blank']
* [OpenID Connect Basic Client Implementer's Guide 1.0|http://openid.net/specs/openid-connect-basic-1_0.html|target='_blank']
* [OpenID Connect Implicit Client Implementer's Guide 1.0|http://openid.net/specs/openid-connect-implicit-1_0.html|target='_blank']
* [OpenID Provider Authentication Policy Extension 1.0|http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html|target='_blank']
* [OpenID Connect Session Management 1.0|http://openid.net/specs/openid-connect-session-1_0.html|target='_blank']
* [OpenID Connect for Identity Assurance]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OpenID Connect|http://openid.net/connect/|target='_blank'] - based on 2015-05-14
* [#2] - [OpenID Connect 1.0 for Enterprise|https://www.pingidentity.com/content/dam/pic/downloads/resources/white-papers/openid-connect-white-paper.pdf|target='_blank'] - based on 2015-05-14