OpenID Connect FAQ
Questions
OpenID Connect General Questions
1) What’s OpenID Connect, and how is it different than OpenID 2.0?
2) How is OpenID Connect different than OAuth 2.0?
3) What problems does OpenID Connect solve that OpenID 1.x/2.x did not solve?
4) What problems does OpenID Connect NOT solve that OpenID 1.x/2.x did solve?
- Which problems does OpenID Connect solve that OpenID 1.x/2.x did not solve?
- Which problems does OpenID Connect not solve that OpenID 1.x/2.x did solve?
- Is OpenID Connect easier or harder to implement than OpenID 1.x/2.x?
- How can one implement OpenID 1.x/2.x and OpenID Connect at the same site?
- If two sites correctly implement all required parts of the spec, and selectively implement (different) optional parts of the spec, are they guaranteed to work together successfully (as judged by the non-technical user)?
- How do I recover an account?
- Where does it define what the user experience looks like?
OpenID Connect Implementation Questions
6) What’s the UserInfo endpoint?
7) What’s the CheckSession endpoint?
8) When should clients use the Implicit vs Code flows?
9) What’s the identifier for the user?
10) How do I extend OpenID Connect?
11) Is OpenID Connect easier or harder to implement than OpenID 1.x/2.x?
12) How can one implement both OpenID 1.x/2.x and OpenID Connect at the same time?
14) How do I recover an account?
15) Where does it define what the User Experience looks like?
Answers (a work in progress!)
OpenID Connect is a Single Sign On (SSO) authentication and attributes transmission protocol built on top of OAuth 2.0. It allows users to log into websites and into applications using an OpenID Connect-enabled account as well as passing various attributes about the user. Attributes can be served from multiple hosts.
OpenID Connect and OpenID 2.0 are similar in that they are both SSO protocols, however the underlying implementations are very different.
While it is possible to use both OpenID 2.0 and OAuth 1.0a simultaneously, it’s very difficult to implement. One of the goals of OpenID Connect is to make it very easy to implement.
OAuth 2.0 does not define a standard way to identify the user nor the way to transmit the attributes of the user, it only defines a way authorize API calls on behalf of a user.
OpenID Connect has support for client apps, and for Javascript browser based apps.
OpenID Connect is also intended to be easier to implement than OpenID 1.x/2.x
OpenID Connect does not require implementers to support Discovery, which allowed any OpenID 1.x/2.x client to interoperate with any OpenID 1.x/2.x server, without any previous configuration.
OpenID Connect does not support delegation.
[anything else?]
The id_token is signed JSON token, similar to an OpenID or SAML Assertion that contains the user’s identifer, and information about when and how the user authenticated.
[....more details to be filled in, including why it’s needed, when to use it, etc...]
The UserInfo endpoint is an OAuth2 protected API that returns information about the user, including the user’s identifier and basic profile information.
The CheckSession endpoint can be used by clients to decode and to verify the id_token.
In general, web server based apps should use the Code flow, while all other apps should use the Implicit flow.
The Code flow is potentially more secure because the Access Token is only returned to the client via HTTPS, and only in exchange for the Code and Client Secret.
The identifier is a unique, never recycled opaque string. It is local to the provider, so to be globally unique, it has to be coupled with a provider identifier.
[lots of open questions: Size limits? How to prevent identifiers from different providers from conflicting? Should it be displayable? What about email address/display name?]
OpenID Connect has generalized Claims request and response mechanism. One can define additional claim types to extend OpenID Connect, typically resulting in the extended UserInfo endpoint. The calim names can be fully qualified URI or IANA registered short name.
OAuth 2.0 also allows service providers can implement their own scopes for other APIs not defined in OpenID Connect.
One of the goals of OpenID Connect is to make it easier to implement than previous versions of OpenID and OAuth 1.0. Since it is based on OAuth 2.0, in the simplest case, it does not involve any crypto.
[no discovery, no crypto, can manually curl everything, etc]
You need to have separate endpoints.
[Not sure how this would work? One approach would be to define an OpenID 2.0 AX attribute that returns the OpenID Connect identifier so that clients could get the Connect identifier using OpenID 2.0.
Going in the other direction, the Connect UserInfo endpoint can return the legacy OpenID 2.0 identifier. Clients can do both OpenID 2.0 and Connect to verify that the identifiers match for legacy users. After verifying that the user controls both identifiers, clients should use Connect from that point onwards]
[not sure how to answer this. Presumably, the user expects that the optional parts are important for the application...]
If the user does not have access to their IdP account, then you’ll have to ask the user for an identifier that was previously associated with their account (eg: email address) and to prove that they control it (send an email with an account recovery link for them to click on).
[Authentication UX is often constrained by legal and business requirements, so it is not feasble at this time to define exact UX requirements.]