Difference between revisions of "Browser Identity Interactions"

From MgmtWiki
Jump to: navigation, search
(Context)
(Proposed Solutions=)
 
(13 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.
+
* 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.
+
** 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 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 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 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 websites can inform the web browser of the user's login state. This will allow identity providers to mark that the user is authenticated with the IdP for a certain website.
 +
* 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==
  
 
[[Category: Identity]]
 
[[Category: Identity]]

Latest revision as of 13:37, 3 June 2021

Full Title or Meme

The full range of Browser Identity Interactions from the initial identity creation to large scale federation interactions.

Context

  • 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 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 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 websites can inform the web browser of the user's login state. This will allow identity providers to mark that the user is authenticated with the IdP for a certain website.
  • 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