Supporting other "famous" IdPs

[djc]

In my test instance, Hotmail/Outlook.com is also supported. We could easily support a few other big OIDC-supporting providers in the future. It seems like this should be reflected in the documentation somehow?

[akuckartz]

How is support for "big OIDC-supporting providers" different from support for all OIDC-supporting providers?

[djc]

For most OIDC providers, you need to register. For the canonical Portier broker, I don't think we want to register with a potentially endless list of providers, so we only register with providers that (a) provide us with a large population, or (b) support our native IdP protocol, which will rely on some kind of dynamic registration.

[callahad]

From experience on Persona, unilaterally supporting providers other than Gmail is untenable. We frequently saw situations where it was literally impossible to get an OAuth or OpenID gateway to return a user's preferred email address.

If we can't match user input to federated output, we can't in good conscience deploy a bespoke integration: Portier won't work, and we'll lock people out of websites.

For Yahoo, I know for a fact that we can't guarantee that there is any overt or discoverable relationship between the email address the user thinks they have and the email address returned by Yahoo's auth gateway. I believe we ran into similar issues regarding the many domains that have historically been associated with Hotmail and Outlook. None of this is documented by the providers themselves, so it's all guesswork and trying to reverse engineer unexpected failures.

Gmail was the only provider that worked reliably. Its normalization rules are sane:

• Downcase everything
• Treat gmail.com and googlemail.com as equivalent domains
• Strip . characters on the left-hand side
• Strip characters between from the first + to the @ on the left-hand side

Amusingly, none of the above necessarily apply to Google Apps accounts.

Closing this as WONTFIX, at least for the MVP.

[andreipopovici]

Have the email normalization changes introduced in https://github.com/portier/portier-broker/releases/tag/v0.3.0 changed the conclusion on this issue at all, by any chance?

[onli]

Definitely worth investigating again. The situation might have improved.

[andreipopovici]

Yeah, v0.3.0 threw me off today when a user created two accounts, one with dots and one without 😅 I was expecting the GMail-normalized version, but I'll go ahead and do it myself on the backend now.

[stephank]

Have the email normalization changes introduced in https://github.com/portier/portier-broker/releases/tag/v0.3.0 changed the conclusion on this issue at all, by any chance?

They've not changed the conclusion, unfortunately, but maybe the situation for those providers has changed, since? We can look into that.

When we talk to a provider, we want some guarantee that the account they authenticate matches what we requested (using our login_hint). Before 0.3, we just took whatever email address the provider authenticated, and returned it to the RP, regardless if it matched the original user input. This turned out to be dangerous, because a user could switch providers, for example, and the new provider might return a slightly different 'canonical' email address than before. (The user could lose access to their accounts on relying parties, because of a silly change.)

With the change in 0.3, we can offer a much stronger guarantee to the relying party that the email address is a stable identifier, because it's just the users input, with a little normalization applied (a pure function).

So for us to support additional providers means we need to have good confidence that it's going to authenticate what we send as login_hint. And actually, even our current GMail implementation fails that rule on two counts:

• Every now and again, Google asks you to re-enter your password. Before the password prompt, there's a prompt asking you to confirm your email address, prefilled with our login_hint. We sort of expect the user to accept the prefilled value. If the user changes it to a completely different account, Portier will fail the authentication.

• When using a G Suite domain, accounts may have aliases. Users cannot use those aliases to login. (Support for G Suite domains is currently opt-in per domain.)

Both of these issues exist because login_hint is just a hint to Google. If we could instead ask Google to guarantee it was authenticating login_hint, we wouldn't have to verify its output, and these issues would be fixed. But we consider these minor issues, and enable GMail support any way.

If we can find a way to support more providers, while following this rule for, say, 95% (like GMail), that'd be great!