Separate User selection from authentication

[bellebaum]

There are several OIDC Core requirements for which this is useful:

• According to Section 3.1.2.2

If the sub (subject) Claim is requested with a specific value for the ID Token, the Authorization Server MUST
only send a positive response if the End-User identified by that sub value has an active session with the
Authorization Server or has been Authenticated as a result of the request. The Authorization Server
MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session
with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by
requesting a specific Claim Value as described in Section 5.5.1, if the claims parameter is supported by the
implementation. 

• According to the prompt values in Section 3.1.2.1

select_account
    The Authorization Server SHOULD prompt the End-User to select a user account.

So we are supposed to support letting the user choose an account, as well as mandating one.

The easiest way I can see to do this is to have one screen to select an account, followed by a second screen to input a password.
Alternatively, we could reuse the existing form and deactivate the input field for the username.
The former approach would likely be more flexible, as it would allow the user to be logged into multiple accounts.

[schanzen]

Not sure how to do this. We cannot let any user select any account for authentication, right?
I think we definitely have to check the sub claim request and if it matches the authenticated user if we already have a session which is currently not done.
I am really not sure how the account selection could work. Maybe we would have to implement a username screen followed by a password screen and then store the subs which were successfully authenticated against in the session.

It would be "better" subjectively to have a single page with user and password login prompt and IF the user previously authetnticated with at least one other account we should display an account selection (and optional reauthentication) unless we have to enforce the "sub" request.

[bellebaum]

As an idea, this is how Microsoft seems to handle this (determined by experiment):
They first have a page for the user to enter a uid (email, username,...), and afterwards have a second page to enter their password. But this way they are also able to automatically determine other providers and request tokens from there. For example, entering a mail adress ending in fraunhofer.de, the user agent is automatically redirected to the Fraunhofer SSO page, with the email address already pre-entered.

Unrelated, one simple solution for us would be to deactivate the username input field when we have to reauthenticate a specific user. The account selection page is a good idea, though we will need to support multiple sessions in the first place to do this.

[schanzen]

Yes, maybe two screens do make sense. Then, we also do not have to deactivate the input field.