Revision as of 16:37, 7 August 2018 by Tom
Full Title or Meme
- 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 (sub), the client id (client_id), and a URL pointing to a set of configuration parameters of the OpenID Provider (OP).
- The Subject ID may be ephemeral.
- The Subject ID may be shared among all of the clients that use the same OP.
- The Identifier or Attribute Provider may optionally ask for User Consent and may provide any set of claims they deem appropriate.
These are additional limitations that need to be provided to the OpenID Connect implementation to meet existing legislation for the 3 party problem.
- The Subject ID must be persistent and not used for different users for at least one year after it use is no longer used for its original Subject.
- The Subject ID must not be shared with different clients by implementing pair-wise identifiers in the OP.
- The Identifier or Attribute Provider must not provide any claims to the Relying Party that have not been part of an User Consent approval process.