OpenID Connect – The Intro

OpenID Connect (T2B)

Convener: Pam Dingle & Justin Richer

Notes-taker(s): Paul Madsen

Tags for the session - technology discussed/ideas considered:

Elevator pitch – protocol framework based on OAuth – adds an identity layer to bare bones OAuth 2.0

The features of OpenID Connect can be divided into

a) those features required for a full platform (e.g. discovery & client registration)

b) standardization of identity pieces (e.g. UserInfo endpoint, id_token)

Note: some of the features defined in OpenID Connect are being fed back into the OAuth WG working on evolution of OAuth 2.0

Difference between a client & relying party? A relying party makes a decision based on a token/assertion it receives from elsewhere (an Idp). A client simply uses the token on an API call.

Justin went through the 3-party flow

                                                  User



                     RP                                                           OP                    
 (consumes tokens & attributes)                                                (issued tokens)

OpenID 2.0 – focused on front-channel

OAuth 2.0 – focused on back-channel

OpenID Connect – closer to OAuth 2.0

OP returns

• id_token
  • JWT carries issuer, userid etc
  • Logically similar to SAML assertion
• access token
  • Used on API call to UserInfo to retrieve attributes
  • Theoretically also used on calls to arbitrary APIs

Pam makes the point that OAuth & OpenID Connect makes different assumptions about how to apportion complexity between the OP/IdP & RP/SP than does SAML.

Question – what is the diff between the info in the id_token and that returned by the UserInfo? The former is bound to a session, with a small set of claims, the latter more long-lived.

OpenID Request Object allows relying party to describe its conditions

Phil Hunt asks about live deployments. Mike replied with description of ongoing interop tests at http://osis.idcommons.net