OpenID Connect

From MgmtWiki
Revision as of 14:20, 30 July 2018 by Tom (talk | contribs) (Solutions)

Jump to: navigation, search

Full Title or Meme

An extension of OAuth 2.0 to give a Relying Party access to User Information. (Other uses of this protocol are possible, but not of interest for Identity Management.

Context

  • The OAuth 2.0 protocol gave access to User Resources, but without authentication, it was fraught with may vulnerabilities.
  • The OpenID Connect protocol is always among three parties: the User (called subject), the Relying Party (called client for OAuth compatibility) and the Identifier or Attribute Provider (called OpenID Provider).
  • There are always three Identifiers: the subject id (sid), the client id (client_id)

Problems

  1. The Subject ID may be ephemeral.
  2. The Subject ID may be shared among all of the clients that use the same OP.

Solutions

These are additional limitations that need to be provided to the OpenID Connect implementation to meet existing legislation for the 3 party problem.

  1. The Subject ID must be persistent.
  2. The Subject ID must not be shared with different clients by implementing pair-wise identifiers.

References