Difference between revisions of "OpenID Connect"
From MgmtWiki
(→Full Title or Meme) |
(→Context) |
||
| Line 5: | Line 5: | ||
*The [[OAuth 2.0]] protocol gave access to [[User]] [[Resource]]s, but without authentication, it was fraught with may vulnerabilities. | *The [[OAuth 2.0]] protocol gave access to [[User]] [[Resource]]s, 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). | *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 [[Identifier]]s: the subject id (sub), the client id (client_id), and a URL pointing to | + | *There are always three [[Identifier]]s: the subject id (sub), the client id (client_id), and a URL pointing to an authoritative set of configuration parameters of the OpenID Provider (OP). |
==Problems== | ==Problems== | ||
Revision as of 20:53, 19 August 2018
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 (sub), the client id (client_id), and a URL pointing to an authoritative set of configuration parameters of the OpenID Provider (OP).
Problems
These are issues that the OpenID Connect core specification leaves up the the implementer to chose that create Security or Privacy problems.
- The Subject ID may be ephemeral. The following quote is from Draft profile FAPI Pt 2 " While the name ID Token suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature. "
- The Subject ID (sub) may be shared among all of the clients that use the same OP unless pair-wise sub is included in the meta-data.
- The Identifier or Attribute Provider may optionally ask for User Consent and may provide any set of claims they deem appropriate.
Solutions
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 (sub) must be persistent and not used for different users for at least one year after it use is no longer used for its most recent Subject.
- The Subject ID (sub) 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.
References
- OpenID specifications (use this if you want to be sure you have the latest version): http://openid.net/developers/specs/
- OpenID connect core specification with Errata Set 1 (2014-11-08): http://openid.net/specs/openid-connect-core-1_0.html
