Why we don't do "Sign in with Google"
Evaluators ask about social login early and the answer is no. It's ruled out by an architecture decision record rather than parked in a backlog, and since that costs us deals it seems worth explaining.
Worth clearing up an ambiguity first, since two opposite things get called "supporting Google". We are an identity provider. Your app redirects to us, we host the sign-in page, mint an authorization code, issue an id_token, publish discovery and JWKS, and a stock OIDC client works against us with no platform-specific code; we drive Auth.js v5 through the whole flow in our test suite. The direction we don't go is the other one, where the user clicks a button, we bounce them to Google, and we take Google's word for who they are.
Federation puts a US company on the sign-in path
Our hard constraint is that no US-headquartered third party sits on the runtime path for end-user identity. Picking a Frankfurt region doesn't satisfy it, since the constraint is about who controls the service.
Google, GitHub/Microsoft, Apple and Facebook are all US-headquartered. Federate sign-in to any of them and on every authentication the user's browser gets redirected to a US company, which learns that this person is signing into your product, from this address, now. It happens before we see the user at all, so there's no setting on our side that changes it.
Some teams need the feature and can't ship without it. If you run a consumer app where a real share of signups abandon at the email step, one-click social is worth money you shouldn't give up for our architectural preferences, and you should use somebody else. The bet is that for B2B products, internal tools, and anything sold to European buyers with a DPO involved, the same feature that lifts consumer conversion is the one that complicates a procurement review.
The smaller reason
Social login isn't a feature you add once. Every provider is an OAuth app registration, a client secret on a rotation schedule, and its own behaviour around scopes and token shapes and email verification. The verification semantics are the genuinely annoying part, because "this address is verified" means different things at different providers and the differences aren't collected anywhere.
Account linking is the part I'd actually worry about. Someone signs up as alice@example.com by email; months later she clicks "Sign in with GitHub" and GitHub asserts alice@example.com. Link on that assertion and any weakness in the provider's verification becomes an account-takeover path on your platform. Refuse to link and she's locked out of her own data. Every vendor offering social login has picked an answer, and the answers are all fine, but it's a surface that grows with each provider you add and we don't have it. There's one credential path here: an emailed link and code, with TOTP on top if you want it.
The door is not nailed shut
Federating to an EU-headquartered IdP is conceivable, and it removes the jurisdiction objection without touching the rest of the review: sub-processor status, what the assertion actually proves, how linking gets handled. A generic OIDC relying-party mode pointed at a customer's own Keycloak is conceivable too.
Both would need their own decision record and a customer asking for a specific one. Building the abstraction first, on the theory that somebody will eventually want it, is how you end up maintaining a federation layer with one user and four security advisories.
Timonier is EU-resident authentication with a self-hostable data plane. There's a Next.js quickstart if you want to see the flow.