How OpenID Connect Works

OpenID Connect enables an Internet identity ecosystem through easy integration and support, security and privacy-preserving configuration, interoperability, wide support of clients and devices, and enabling any entity to be an OpenID Provider (OP). The OpenID Connect protocol, in abstract, follows these steps:
  1. The RP (Client) sends a request to the OpenID Provider (OP).
  2. The OP authenticates the User and obtains authorization.
  3. The OP responds with an Identity Token and usually an Access Token.
  4. The RP can send a request with the Access Token to the User device.
  5. The UserInfo Endpoint returns Claims about the End-User.
Authentication

The secure process of establishing and communicating that the person operating an application or browser is who they claim to be.

Authentication Token Request

Clients request tokens from the OP and depending on the scopes requested, the OP will return an identity token, an access token, or both.

Client

A client is a piece of software that requests tokens either for authenticating a user or for accessing a resource (also often called a relying party or RP). A client must be registered with the OP. Clients can be web applications, native mobile and desktop applications, etc.

Identity Provider (IDP)

IDP stands for Identity Provider, a party that offers user authentication as a service.

Identity Scopes

Scopes are identifiers for resources that a client wants to access. The identifier is sent to the OP during an authentication or token request. The identity profile scope of OpenID Connect can include first name, last name, preferred username, gender, profile picture, email address and more.

OpenID Provider (OP)

An OpenID Provider (OP) is an entity that has implemented the OpenID Connect and OAuth 2.0 protocols, OP’s can sometimes be referred to by the role it plays, such as: a security token service, an identity provider, or an authorization server.

Identity Token

An identity token represents the outcome of an authentication process. It contains at a bare minimum an identifier for the user (called the sub aka subject claim) and information about how and when the user authenticated. It can contain additional identity data.

Relying Party (RP)

RP stands for Relying Party, an application or website that outsources its user authentication function to an IDP.

Resource Scopes

Resource scopes identify APIs, for example, a scope named calendar that represents a calendar API. Every resource has a unique name and clients use this name to specify to which resources they want to get access to.

User

A user is a person that is using a registered client to access resources.

Frequently Asked Questions

It is easy, reliable, secure, and eliminates storing and managing people’s passwords. It improves the user experience of sign-up and registration and reduces website abandonment. Furthermore, Public-key-encryption-based authentication frameworks like OpenID Connect increase the security of the whole Internet by putting the responsibility for user identity verification in the hands of the most expert service providers.

Yes. There are already system-level APIs built into the Android operating system to provide OpenID Connect services. OpenID Connect can also accessed by interacting with the built-in system browser on mobile and desktop platforms; a variety of libraries are under construction to simplify this process.

OAuth 2.0, is a framework, specified by the IETF in RFCs 6749 and 6750 (published in 2012) designed to support the development of authentication and authorization protocols. It provides a variety of standardized message flows based on JSON and HTTP; OpenID Connect uses these to provide Identity services.

OpenID Connect has many architectural similarities to OpenID 2.0, and in fact the protocols solve a very similar set of problems. However, OpenID 2.0 used XML and a custom message signature scheme that in practice sometimes proved difficult for developers to get right, with the effect that OpenID 2.0 implementations would sometimes mysteriously refuse to interoperate. OAuth 2.0, the substrate for OpenID Connect, outsources the necessary encryption to the Web’s built-in TLS (also called HTTPS or SSL) infrastructure, which is universally implemented on both client and server platforms. OpenID Connect uses standard JSON Web Token (JWT) data structures when signatures are required. This makes OpenID Connect dramatically easier for developers to implement, and in practice has resulted in much better interoperability.

The FIDO Alliance is one organization in which non-password authentication technologies are being explored. Some OpenID Foundation members are also members of the FIDO Alliance, working on authentication technologies there that can be used by OpenID Providers.

The Security Assertion Markup Language (SAML) is an XML-based federation technology used in some enterprise and academic use cases. OpenID Connect can satisfy these same use cases but with a simpler, JSON/REST based protocol. OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications. SAML and OpenID Connect will likely coexist for quite some time, with each being deployed in situations where they make sense.

Criteria for being listed as an available consultant:

  • OpenID Foundation member in good standing — organization or individual
  • Contributor to a prior successful OpenID certification
  • Successful OpenID certifications – list of successful certifications (e.g. Connect, FAPI, etc.) to highlight specific expertise
  • Languages fluent – spoken languages fluent as this will be become increasingly important as the Foundation and FAPI scale globally

Please send a request to be listed as an available consultant to certification@oidf.org.

The OpenID Connect protocol designs are open to encourage an open ecosystem of IDPs. While the leading IDPs are currently large cloud services providers, such as Google and Microsoft, OpenID Connect enables many kinds of OP for Website, applications, clients, and devices.

OpenID Connect identifies a set of personal attributes that can be exchanged between Identity Providers and the apps that use them and includes an approval step (aka authorization) so that users can consent (or deny) the sharing of this information.