Current workflow is three screens:

Screen One

Screen Two

Screen Three

---

I think we should retain one of these screens the first time you login. Here's the attack I can perform if there is no user interaction at all required to log in:

• I start an instance, evil.phacility.com.
• I add you (my victim) to the instance.
• I trick you into visiting a page which loads the login screen in a hidden iframe.
• Since we've removed all the checks, the iframe redirects to admin.phacility.com, which authorizes you. admin.phacility.com redirects back to evil.phacility.com, which reads your data and shows you a login screen.
• I export a backup of the data for my instance.
• I can read your email (and a small amount of other personal information) out of the external_account table.

This seems bad enough to justify requiring a click to confirm that you want to join an instance. After initial approval, we can log you in directly in other cases, or we can just leave the screen. This is common in other OAuth implementations.

---

First of three parts is to remove this screen:

Removing this screen (if we also remove the other screens, except make one of them one-time-only) allows an attacker to log a user into an instance, provided they are currently logged out but are logged in to admin.phacility.com, and already have an account on the instance. This does not seem meaningfully dangerous. It is possible it could disclose that the victim has an account (maybe: time the cost of making some request; try to log the user in; time the cost of making the request again; if it went up a lot because the logged-in version of the page is way more expensive, maybe that detects that they have an account). But this is a pretty targeted and generally useless-seeming attack. (It is also very rare for users to be logged in to the upstream but not to their instance.)

To remove this dialog, I think the cleanest approach is to add a checkbox to the Auth configuration, like:

• Automatically login with this provider if it is the only available provider.

Then, on the login start page, check if there's exactly one provider with that flag set. If so, just redirect the user as though they had clicked the button.

---

Second part is this screen:

I think we should keep this, but it would be nice to make it simpler:

• We do not need an infinite-duration token and do not benefit from it. If the client doesn't request that scope (and we shouldn't), can we just hide the checkbox and always issue a temporary token?
• If the user unchecks the user.whoami checkbox, nothing works anyway. We can just make this implicit in "allow ... access your Phabricator account data", since this is the minimal level of access that makes sense anyway. We also get this exception on uncheck, currently:

So I think we should:

• Don't prompt for inifinite tokens if the client didn't ask for them.
• Make granting "user.whoami" implicit in granting any access at all.
• Fix that exception, I guess.

---

Third part is this screen:

This was added as part of D8517. Without it, attackers can steal OAuth tokens from a login provider by registering an OAuth server, then using it to redirect users from the login provider through their client and ultimately to their server.

This screen is safe to remove if we trust the server, and the servers we create are trustworthy. I think the simplest approach here is:

• Add a "trusted" flag to OAuth servers.
• Users can set it with bin/auth trust-oauth-server or similar (it should not be settable via the web UI).
• We'll set it internally when we build the servers.
• If an OAuth server has the flag set, it can safely just do the redirect on this screen instead of prompting the user.

---

That will leave us with one simple prompt confirming login to the instance, instead of three weird/complex screens. I think that's pretty reasonable.

If we want to refine things further, we can skip the prompt if: the OAuth server is trusted, and the user has already logged in before. But this won't make the first login experience any better, so I'm not sure it's worth it.

Let's start with that and see how it feels?