User:Sakimura/sandbox

=OpenID=

OpenID is the trademark owned by the OpenID Foundation to protect the series of open standards so that only the implementations that conform can use the mark. Any compliant implementations can claim to support OpenID without obtaining an explicit license from the OpenID Foundation while if the implementation does not conform, the license is not granted.

OpenID Specifications are created and maintained by the Working Groups of the foundation according to OpenID Process.

OpenID Standards
OpenID Standards are the final specifications that were created by consensus and after 60 days of the public review period.

The final specifications as of 2018-10-15 include:


 * OpenID Connect Core 1.0
 * OpenID Connect Discovery 1.0
 * OpenID Connect Dynamic Client Registration 1.0
 * OAuth 2.0 Multiple Response Types
 * OAuth 2.0 Form Post Response Mode
 * OpenID 2.0 to OpenID Connect Migration 1.0

Obsoleted Specifications
Following specifications were retired and are not recommended for new implementations.


 * OpenID Authentication 2.0
 * OpenID 2.0 PAPE
 * OpenID Authenticaiton 1.1

=OpenID Connect=

OpenID Connect (OIDC') is an identity layer on top of OAuth 2.0, an authorization framework. It creates an authenticated identity (set of claims) and encodes them in ID Token that is passed from the OpenID Provider to the Relying Party. Using ID Token, the Reling Party (web services and smartphone application) can login the user to its service. The standard is created and maintained by the OpenID Foundation's AB/Connect Working Group.

Technology
OpenID Connect uses OAuth 2.0 as the base protocol to request and transfer user identity (set of claims). The identity is represented in the form of JSON Web Token (JWT) and is signed by JSON Web Signature (JWS). It can also be optionally encrypted using JSON Web Encryption (JWE).

The request for the ID Token is signalled in OAuth 2.0 as the scope value "openid". If the compliant authorization server receives it, the authorization server first authenticates the user and then creates the ID Token and returns it to the client either from the authorization endpoint or the token endpoint depending on the OAuth grant type used.

Supported OAuth grant types are "code", "code id_token", "token id_token", "code token id_token".

The location from which the ID Token is returned depending on the grant type are as follows:


 * "code": Token Endpoint
 * "code id_token": Token Endpoint and Authorization Endpoint
 * "token id_token": Authorization Endpoint
 * "code token id_token": Token Endpoint and Authorization Endpoint

When the id_token is returned from the Authorization Endpoint, it also acts as a detached signature for the authorization response so that the client can detect if the response has been tampered.

History
Work on OpenID Connect started in 2009 when Nat Sakimura, John Bradley and Breno de Madeiros got together to create a new protocol that is versatile and secure enough for financial transactions and contractual formation. Initially, they explored the use of OpenID Authentication 2.0 as the base protocol as it was already used by multiple payment services, but soon they found that canonicalization involved in signing the request and response is error-prone and causes problems. They then explored the use of XML and XML Digital Signature as the payload but the developers they surveyed did not like it as it was both bulky and error-prone as well due to the canonicalization. The preferred format from the developer perspective was JSON.

Thus, Sakimura, Bradley and de Madeiros made a set of design decision.


 * Identity payload should use JSON.
 * New signature and encryption specification needs to be created as there is no such thing.
 * In doing so, there shall be no canonicalization and they should be ASCII armoured.

The resulting drafts were JSON Simple Signature and JSON Simple Encryption, which later became JSON Web Signature (JWS, RFC7515) and JSON Web Encryption (JWE, RFC7516) respectively by consolidating with Magic Signature which was created independently by Dirk Belfanz. The consolidation was lead by Michael B. Jones.

For the underlying protocol, they started to create a new protocol that does not involve canonicalization and signing. However, when Dick Hardt came up with OAuth WRAP, which did not involve canonicalization nor signature scheme, it was adopted as the base protocol. Later, OAuth WRAP was adopted as the basis for OAuth 2.0 and thus the OpenID Connect's base became the OAuth 2.0 Framework [RFC6749].

After several rounds of interops and beta testing by major internet platforms, it was adopted as the OpenID Foundation standard in February 2014.

Adoption
The adoption started before the specification became final. Major platforms like Google, Amazon, Microsoft, etc., mobile operators such as Deutsche Telekom, Telefonica, Orange, started to support it. As of April 2018, over 92% of the authentication transaction on Microsoft Azure AD is happening over OpenID Connect.

Certification
=OpenID Authentication 2.0=

OpenID Authentication 2.0 is an federated authentication protocol. It passes the result of the user authentication performed at a website called OpenID Provider to another website called Relying Party. It also works as a framework to pass other identity attributes using Attribute Exchange extension.

It is deprecated in 2015 and is not recommended to be used in new implementations.

Adoption
=References=