Difference between revisions of "OpenID Connect"
From MgmtWiki
(→To be integrated) |
|||
| (35 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==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]]. | + | An extension of [[OAuth 2.0]] to give a [[Relying Party]] access to [[User Information]] for Identification. (Other uses of this protocol are possible, but not of interest for [[Identity Management]]). |
==Context== | ==Context== | ||
| − | *The [[OAuth 2.0]] protocol gave access to [[User]] [[Resource]]s, but without authentication, it was fraught with | + | *The [[OAuth 2.0]] protocol gave access to [[User]] [[Resource]]s, but without authentication, it was fraught with many vulnerabilities. |
| − | *The [[OpenID Connect]] protocol is always among three parties: the [[User]] (called | + | *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 ( | + | ** An exception is for [[Self-issued Identifier]]s where the user (sub) and the issuer (OP) are the same entity. |
| + | *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). | ||
| + | |||
| + | |||
| + | ===To be integrated=== | ||
| + | Note that in the Open ID document the RP is called a client and the IdP is called an Open ID provider (OP). It is a long-term goal for the [[IDEF]] to create an OpenID Connect profile that shows which options to use. In the meantime, the [[Compliant Implementation of RP on ASP.NET]] provides a working model of a compliant OpenID Connect implementation. The following items might be included in a [[IDEF]] profile: | ||
| + | #The RP and not the user has the ability to determine how the unprotected flow of [[Access Token]]s are handled. [[IDEF]] could require the use of the "Authorization Code Flow", as shown above, which places all access tokens in protected flows between the RP and the IdP. That presumes that the RP is able to protect secrets like the [[User Private Information]] from disclosure. | ||
| + | #The RP determines which [[User Private Information]] it wishes to receive and leaves it up to the IdP to determine whether the user has any choice as to which information to disclose. Some IdPs are very diligent and allow the user to select based on the claims profiles provided by the RP. It is more common for IdPs to offer the list of requested claims profiles to the user on a "take-it-or-leave-it" basis. the [[IDEF]] could require IdPs to give the user more granular control. | ||
| + | #The Subject Identifier (sub in OpenID) is provided from the IdP to the RP during authentication. It is not a requirement that the IdP avoid reuse the same "sub" between two RP's to prevent linking between [[User Object]]s in those two RPs unless "pairwise" is specified. Any [[IDEF]] profile should require [[Pairwise Identifier]]s for subject as it is not in the interest of any digital entity to enable it. See the wiki page on [[Pairwise Identifier]] for the pros and cons of this approach. | ||
| + | |||
| + | Features that are not available in OpenID Connect (see the wiki page [[OpenID Connect Future]] for more on this topic]] that would improve the user experience include: | ||
| + | #The ability to mark scope value by whether they were mandatory so that the consent form could let the user know which were optional. Please see [http://openid.net/2017/04/12/guest-blog-reaching-the-age-of-consent/ this paper] for more details on this issue. This might be solved by eliminating all values from the scope other than "openid". The use of the claims parameter might solve this problem as it does have an appropriate modifier. | ||
| + | #There is not a complete protocol for passing information between the various identity providers in the OpenID Connect specifications. The [https://tools.ietf.org/html/rfc7662 Token Introspection RFC] does provide data exchange, but does not describe the endpoint discovery mechanism. That would be needed at the point where the use case (or implementation guide) for the separation of the Attribute Provider from the other OpenID Providers (OP) was described. | ||
==Problems== | ==Problems== | ||
| − | #The [[Subject]] ID may be ephemeral. | + | * The great advantage of OpenID Connect is that it is simple and easy to implement. |
| − | #The [[Subject]] ID may be shared among all of the clients that use the same OP. | + | * The great disadvantage of OpenID Connect is that it is simple and easy to implement. |
| + | Some of the problems that arise when the solution is not sufficiently simple to use OpenID Connect as it is written. | ||
| + | # UK Open banking has found problems, like Bearer tokens, that resulted in the Financial-grade API of FAPI profile for OpenID Connect. | ||
| + | # The Issuer is defined in different ways even the the body of the document and other restrictions are found in the conditions near the end of the document. | ||
| + | # The dependence on the transport layer security (TLS) means that the legal entity and the URL need to be tightly bound, which is not always desirable. | ||
| + | These are issues that the [[OpenID Connect]] core specification leaves up the the implementer to choices 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. | #The [[Identifier or Attribute Provider]] may optionally ask for [[User Consent]] and may provide any set of claims they deem appropriate. | ||
| + | An existential threat to the continued dominance of [[OpenID Connect]] | ||
| + | * See the wiki page [[OpenID Connect Future]] | ||
==Solutions== | ==Solutions== | ||
These are additional limitations that need to be provided to the [[OpenID Connect]] implementation to meet existing legislation for the 3 party problem. | 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 | + | *Security Profile: |
| − | #The [[Subject]] ID must not be shared with different clients by implementing pair-wise identifiers in the OP. | + | #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 [[Identifier or Attribute Provider]] must not provide any claims to the [[Relying Party]] that have not been | + | #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. | ||
| + | |||
| + | ===Identity Token=== | ||
| + | * [https://openid.net/specs/openid-connect-core-1_0.html#IDToken Definition of ID token in OIDC] | ||
| + | |||
| + | ===Healthcare=== | ||
| + | * [https://openid.net/wordpress-content/uploads/2022/06/OIDF-and-the-Health-Whitepaper-June-21.pdf Debbi Bucci published a review] of how [[OpenID Connect]] and other standards work in the area of healthcare. The version of 2022-06 was mostly backward looking and give little guidance on how to move forward. | ||
==References== | ==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 | ||
| − | + | [[Category: Glossary]] | |
| − | [[Category: | + | [[Category: Identity]] |
| + | [[Category: Standard]] | ||
| + | [[Category: Health]] | ||
Latest revision as of 16:23, 19 July 2022
Contents
Full Title or Meme
An extension of OAuth 2.0 to give a Relying Party access to User Information for Identification. (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 many 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).
- An exception is for Self-issued Identifiers where the user (sub) and the issuer (OP) are the same entity.
- 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).
To be integrated
Note that in the Open ID document the RP is called a client and the IdP is called an Open ID provider (OP). It is a long-term goal for the IDEF to create an OpenID Connect profile that shows which options to use. In the meantime, the Compliant Implementation of RP on ASP.NET provides a working model of a compliant OpenID Connect implementation. The following items might be included in a IDEF profile:
- The RP and not the user has the ability to determine how the unprotected flow of Access Tokens are handled. IDEF could require the use of the "Authorization Code Flow", as shown above, which places all access tokens in protected flows between the RP and the IdP. That presumes that the RP is able to protect secrets like the User Private Information from disclosure.
- The RP determines which User Private Information it wishes to receive and leaves it up to the IdP to determine whether the user has any choice as to which information to disclose. Some IdPs are very diligent and allow the user to select based on the claims profiles provided by the RP. It is more common for IdPs to offer the list of requested claims profiles to the user on a "take-it-or-leave-it" basis. the IDEF could require IdPs to give the user more granular control.
- The Subject Identifier (sub in OpenID) is provided from the IdP to the RP during authentication. It is not a requirement that the IdP avoid reuse the same "sub" between two RP's to prevent linking between User Objects in those two RPs unless "pairwise" is specified. Any IDEF profile should require Pairwise Identifiers for subject as it is not in the interest of any digital entity to enable it. See the wiki page on Pairwise Identifier for the pros and cons of this approach.
Features that are not available in OpenID Connect (see the wiki page OpenID Connect Future for more on this topic]] that would improve the user experience include:
- The ability to mark scope value by whether they were mandatory so that the consent form could let the user know which were optional. Please see this paper for more details on this issue. This might be solved by eliminating all values from the scope other than "openid". The use of the claims parameter might solve this problem as it does have an appropriate modifier.
- There is not a complete protocol for passing information between the various identity providers in the OpenID Connect specifications. The Token Introspection RFC does provide data exchange, but does not describe the endpoint discovery mechanism. That would be needed at the point where the use case (or implementation guide) for the separation of the Attribute Provider from the other OpenID Providers (OP) was described.
Problems
- The great advantage of OpenID Connect is that it is simple and easy to implement.
- The great disadvantage of OpenID Connect is that it is simple and easy to implement.
Some of the problems that arise when the solution is not sufficiently simple to use OpenID Connect as it is written.
- UK Open banking has found problems, like Bearer tokens, that resulted in the Financial-grade API of FAPI profile for OpenID Connect.
- The Issuer is defined in different ways even the the body of the document and other restrictions are found in the conditions near the end of the document.
- The dependence on the transport layer security (TLS) means that the legal entity and the URL need to be tightly bound, which is not always desirable.
These are issues that the OpenID Connect core specification leaves up the the implementer to choices 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.
An existential threat to the continued dominance of OpenID Connect
- See the wiki page OpenID Connect Future
Solutions
These are additional limitations that need to be provided to the OpenID Connect implementation to meet existing legislation for the 3 party problem.
- Security Profile:
- 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.
Identity Token
Healthcare
- Debbi Bucci published a review of how OpenID Connect and other standards work in the area of healthcare. The version of 2022-06 was mostly backward looking and give little guidance on how to move forward.
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
