Difference between revisions of "Browser Identity Interactions"
From MgmtWiki
(→Context) |
m (→Proposed Solutions) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
| − | * The [[OpenID Connect]] protocol was the first major successful method to create [[Single Sign On]] functionality in commonly available browsers. | + | * In this context Identity is taken to be the [[Identifier]]s and [[Attribute]]s held by a [[Data Controller]] in a [[User Object]]. |
| + | * The [[OpenID Connect]] protocol was the first major successful method to create [[Single Sign On]] (SSO) functionality in commonly available browsers. | ||
* This protocol worked its magic by a method now known as front-channel even though that term does not appear in the [[OpenID Connect]] spec. | * This protocol worked its magic by a method now known as front-channel even though that term does not appear in the [[OpenID Connect]] spec. | ||
** Front channel communications relies on communications from the IdP to the RP to flow through the user's browser, rather than the back channel flow directly between the Idp and RP. | ** Front channel communications relies on communications from the IdP to the RP to flow through the user's browser, rather than the back channel flow directly between the Idp and RP. | ||
** The problem occurs when the RP and IdP are not in the same domain (or origin see wiki page [[Cross-Origin iFrame]] for descriptions of those terms. | ** The problem occurs when the RP and IdP are not in the same domain (or origin see wiki page [[Cross-Origin iFrame]] for descriptions of those terms. | ||
** Will not be able to detect the IDP session changes, hence will not be able to log out from the client application using front channel (back channel still works). | ** Will not be able to detect the IDP session changes, hence will not be able to log out from the client application using front channel (back channel still works). | ||
| − | ** | + | ** Sign in functionality will work, but there is no SSO experience between multiple applications. That is between sites that are not recognized as first party sites. This applies only to RPs that embed the sign in page in the RP site as an iFrame, [[Pop-up Window]] or similar. |
| − | * The password manager (PM) is a pluggable feature in the browser. Generally the HTTP hooks are standardized, but the manager itself does not appear to be. | + | ** Some new protocols, like token-binding will no longer function during sign in, but these have limited market deployment. |
| + | * The password manager (PM) is a pluggable feature in the browser. Generally, the HTTP hooks are standardized, but the manager itself does not appear to be. The PM can be taken to be a [[Data Controller]] which contains a [[User Object]] on behalf of the holder of the device. The holder may be either the subject user or a delegate for the subject user. | ||
** The PM can recognize when a user has been at a site before and that the site is asking for a user name and password. | ** The PM can recognize when a user has been at a site before and that the site is asking for a user name and password. | ||
==Problems== | ==Problems== | ||
| + | * Giving the user control over their own identifiers creates the need for secure storage of user secrets that can be used during the sign in process. | ||
| + | ** This feature was include in Section 7 of the [[OpenID Connect]] spec using the scheme "opened://". | ||
| + | ** This can be handled by the browser but only for a single phone app. | ||
* The use of third party cookies to track the user from the RP to the IdP is the same method used by advertisers to track user behavior on the Web. | * The use of third party cookies to track the user from the RP to the IdP is the same method used by advertisers to track user behavior on the Web. | ||
* The browsers all block some use of third party cookies in 2020 and are set to soon block all use of third party cookies. | * The browsers all block some use of third party cookies in 2020 and are set to soon block all use of third party cookies. | ||
* Most of the money made on the web is through advertising. Companies like Google cannot afford the loss of their primary revenue stream. | * Most of the money made on the web is through advertising. Companies like Google cannot afford the loss of their primary revenue stream. | ||
| + | ==Proposed Solutions== | ||
| + | * The I[https://github.com/privacycg/is-logged-in sLoggedIn API] with which [[Web Site]]s can inform the web browser of the user's sign-in state. This will allow identity providers to mark that the user is authenticated with the IdP for a certain [[Web Site]]. | ||
| + | * The [https://wicg.github.io/WebID/README.html WebID initiative] intends to give browser core-level support for identity federation. One of the problems it addresses is to provide the capability to differentiate between federation cases where identity data is exchanged, as well as other scenarios. | ||
| + | * The OAuth WG has also initiated discussions on the impact on identity protocols by the use of tracking-prevention technologies that have been introduced by browsers, and new browser initiatives to provide core level support for identity federation. | ||
==References== | ==References== | ||
| + | * See more generic information on the wiki page [[Browser]]. | ||
[[Category: Identity]] | [[Category: Identity]] | ||
| + | [[Category: Browser]] | ||
Latest revision as of 18:04, 26 April 2023
Full Title or Meme
The full range of Browser Identity Interactions from the initial identity creation to large scale federation interactions.
Context
- In this context Identity is taken to be the Identifiers and Attributes held by a Data Controller in a User Object.
- The OpenID Connect protocol was the first major successful method to create Single Sign On (SSO) functionality in commonly available browsers.
- This protocol worked its magic by a method now known as front-channel even though that term does not appear in the OpenID Connect spec.
- Front channel communications relies on communications from the IdP to the RP to flow through the user's browser, rather than the back channel flow directly between the Idp and RP.
- The problem occurs when the RP and IdP are not in the same domain (or origin see wiki page Cross-Origin iFrame for descriptions of those terms.
- Will not be able to detect the IDP session changes, hence will not be able to log out from the client application using front channel (back channel still works).
- Sign in functionality will work, but there is no SSO experience between multiple applications. That is between sites that are not recognized as first party sites. This applies only to RPs that embed the sign in page in the RP site as an iFrame, Pop-up Window or similar.
- Some new protocols, like token-binding will no longer function during sign in, but these have limited market deployment.
- The password manager (PM) is a pluggable feature in the browser. Generally, the HTTP hooks are standardized, but the manager itself does not appear to be. The PM can be taken to be a Data Controller which contains a User Object on behalf of the holder of the device. The holder may be either the subject user or a delegate for the subject user.
- The PM can recognize when a user has been at a site before and that the site is asking for a user name and password.
Problems
- Giving the user control over their own identifiers creates the need for secure storage of user secrets that can be used during the sign in process.
- This feature was include in Section 7 of the OpenID Connect spec using the scheme "opened://".
- This can be handled by the browser but only for a single phone app.
- The use of third party cookies to track the user from the RP to the IdP is the same method used by advertisers to track user behavior on the Web.
- The browsers all block some use of third party cookies in 2020 and are set to soon block all use of third party cookies.
- Most of the money made on the web is through advertising. Companies like Google cannot afford the loss of their primary revenue stream.
Proposed Solutions
- The IsLoggedIn API with which Web Sites can inform the web browser of the user's sign-in state. This will allow identity providers to mark that the user is authenticated with the IdP for a certain Web Site.
- The WebID initiative intends to give browser core-level support for identity federation. One of the problems it addresses is to provide the capability to differentiate between federation cases where identity data is exchanged, as well as other scenarios.
- The OAuth WG has also initiated discussions on the impact on identity protocols by the use of tracking-prevention technologies that have been introduced by browsers, and new browser initiatives to provide core level support for identity federation.
References
- See more generic information on the wiki page Browser.
