How OpenID Connect Works
- The RP (Client) sends a request to the OpenID Provider (OP).
- The OP authenticates the User and obtains authorization.
- The OP responds with an Identity Token and usually an Access Token.
- The RP can send a request with the Access Token to the User device.
- The UserInfo Endpoint returns Claims about the End-User.
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 firstname.lastname@example.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.