Welcome to OpenID Connect (i)

What is OpenID Connect

OpenID Connect1.0 is a simple identity layer located above the OAuth2.0. It allows the client to authenticate the end user through the authorization server, obtaining basic profile information for the end customer through interoperability and rest-like.

OpenID connections allow all types of customers, including networks, mobile phones, and JavaScript customers, to request and receive authenticated sessions and end-user information. The specification suite is extensible, providing optional features such as encrypting identity data, discovering OpenID providers, and session management, all of which make sense.

http://openid.net/connect/faq/, answers to frequently asked questions about OpenID connectivity.

The difference between OpenID Connetcton and OpenID 2.0

OpenID connectivity has many of the same features as OpenID 2.0, such as a friendly API that makes native and mobile applications available. The OpenID connection defines an optional robust signature and encryption mechanism. Integration of OAuth 1.0 and 2.0 OpenID required extensions, in OpenID connection, OAuth 2.0 feature integration protocol itself. (whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities is int Egrated with the protocol itself. Do not understand this sentence)

Normative organization

The OpenID Connect1.0 specification consists of the following 6 files:

• Core functionality-defines the core functionality of OpenID connection: Authentication is based on OAuth2.0 and uses claims to communicate information to end users.
• Discovery (Discovery)-(optional) defines how users can dynamically discover an OpenID provider.
• Dynamic registration-Optionally, define how clients are dynamically registered with the OpenID provider.
• OAuth2.0 multiple response types-Define a few specific new OAuth2.0 response types.
• OAuth2.0 form Send Request response mode-(optional) define how the OAuth2.0 authentication response parameters (including the OpenID connection authentication response parameters) are returned, and the end user submits the HTML form automatically using the HTTP post.
• Session Management-(optional) defines how to manage OpenID connect sessions, including logoff based on sending messages.
• HTML-based logoff-(optional) The HTTP-based injection mechanism, rather than using the OP Framework on the RP page.

Two implementation guides can also be used as a stand-alone reference for basic network relying parties:

• Basic client Implementation Guide-use the authentication stream for a simple subset of the core functionality of the web-relying party.
• Implicit client Implementation Guide-a simple subset of core functionality based on the Web relying party uses the authenticated implicit stream.

Of course, the Protocol for a migration specification is also feasible:

• OpenID2.0 migration to OpenID connection-defines how OpenID2.0 is migrated to an open connection.

The OpenID Connection protocol, implementation guidelines, and specifications are in the following diagram box. Click on the box to view the specification.

Welcome to OpenID Connect (i)