Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multi-login and multiple user profiles #21

Open
johnwilander opened this issue Sep 10, 2020 · 5 comments
Open

Support multi-login and multiple user profiles #21

johnwilander opened this issue Sep 10, 2020 · 5 comments

Comments

@johnwilander
Copy link
Collaborator

The user may have multiple accounts for one website, multiple users may be using the same browser to log in to a specific website (shared device case), and some websites allow multiple concurrent logins with fast profile switching. In the case of multiple concurrent logins, there may be a dominant or operating account among them.

We should try to support these use cases.

If the username parameter is the key under which all other state hangs, it means it really needs to be the site-unique username for the user and not just a display name. We may resolve this with a parameter for both display name and site-unique user name and browsers would have to make sure a multi user case with duplicate display names doesn't get confusing. One way of solving that is to only show the display name if it's unique for this site in this browser, otherwise show the site-unique username. When I say "show," I'm not talking about something specified by this spec but something browsers may build such as an IsLoggedIn status pill in the URL bar.

@johnwilander johnwilander added the agenda+F2F Request to add this issue or PR to the agenda for our upcoming F2F. label Sep 10, 2020
@gffletch
Copy link

If there is both a unique-id and display name then the unique-id may not even need to be a "username" but could be any unique identifier the site wants to use to identify the user at the next login.

I'm also curious how sites should implement the "Account Chooser" UX and whether this proposal puts any limits on those implementations.

@johnwilander
Copy link
Collaborator Author

If there is both a unique-id and display name then the unique-id may not even need to be a "username" but could be any unique identifier the site wants to use to identify the user at the next login.

Right, we'd just have to name the parameters in a way that maximizes the chances of developers getting them right. 🙂

I'm also curious how sites should implement the "Account Chooser" UX and whether this proposal puts any limits on those implementations.

I don't see this proposal affecting or instructing websites how to implement account switching. Do you think it needs to? Sure, it would be nice to have browsers offer account switching which would require a defined way to switch state. That would likely have to be switching website data sessions completely. But what I'm thinking is that the site merely tells the browser which user is currently logged in and the browser accepts that as an account switch.

@gffletch
Copy link

In most cases today... if the browser is not currently logged in but has been in the past, when the browser visits the login service instead of being shown an username/password page, they are shown a page of all the identities that have logged in from that browser. This is usually stored in local storage on the fully qualified domain of the identity provider. As long as the local storage will persist across login/logout flows then existing behavior should work fine. Some identity providers use a persistent cookie for this data instead of local storage.

@johnwilander
Copy link
Collaborator Author

In most cases today... if the browser is not currently logged in but has been in the past, when the browser visits the login service instead of being shown an username/password page, they are shown a page of all the identities that have logged in from that browser. This is usually stored in local storage on the fully qualified domain of the identity provider. As long as the local storage will persist across login/logout flows then existing behavior should work fine. Some identity providers use a persistent cookie for this data instead of local storage.

The exact policies browsers might apply based on the IsLoggedIn signal is outside the scope of this proposal (although #15 will be discussed at the F2F). If a browser decides to delete or hide website data after N days of no logged in state, the list of previously used identities will not be there on page load after N days. That is the same thing as the user deleting website data or the user using an ephemeral session and restarting their browser.

@gffletch
Copy link

gffletch commented Sep 10, 2020

So, browsers that implement that behavior will cause the users of those browsers to have a more challenging login experience because it won't be possible for the IDP to distinguish between a browser the user has used in the past and a brand new one possibly driven by an attacker. So the IDP will likely require the user to pass multiple challenges to ensure it's the correct user even though they logged into the site say M days in the past.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants