Support for federated logins, or the ability to transfer IsLoggedIn

[johnwilander]

Back in the original explainer, we explored an idea on how to support federated logins (logging in to one website with an account from another website that is not part of the same organization, as opposed to single sign-on which is about the same organization). This is what was said there:

Some websites allow the user to use an existing account with a federated login provider to bootstrap a new local user account and subsequently log in. The IsLoggedIn API needs to support such logins.

First, the federated login provider needs to call the API on its side, possibly after the user has clicked a “Log in with X” button:

 navigator.initiateLoggedInFederated(destination: secure origin) –> Promise<void>

For the promise to resolve, the user needs to already have the IsLoggedIn status set for the federated login provider, i.e. the user needs to be logged in to the provider first.

Then the destination website has to call the API on its side:

 navigator.setLoggedInFederated(
     loginProvider: secure origin,
     username,
     credentialTokenType,
     optionalParams { }
 ) –> Promise<void>

The promise would only resolve if the loginProvider had recently called setLoggedInFederated() for this destination website.

What this comes down to is the capability to set IsLoggedIn on DependingSite by taking the user through specific steps on IdentityProviderSite. This would allow IdentityProviderSite to "transfer the ability to set IsLoggedIn" to DependingSite without there having to be e.g. a login form on SiteA.

We should discuss this opportunity without being tied to the original proposal quoted above. The important part is to explore how to support such a transfer capability.

[melanierichards]

Ported to https://github.com/privacycg/is-logged-in/issues/35