Hypothesis

If we offer Google, GitHub, and Microsoft sign-up and sign-in alongside email and password, then more people complete sign-up and fewer drop off before they try the product.

Problem observations

• The public sign-up on the marketing site is four pages long, with no shortcut for people who would rather click "Sign up with Google".
• Logging in already shows an "external provider" option, but only when an instance admin has manually configured one identity provider.
• Customers ask for SSO. It is table stakes in this space.

In scope

• Sign-up and sign-in via Google, GitHub, and Microsoft.
• Linking an SSO provider to an existing email-and-password account, with a password confirmation step.
• Listing, linking, and unlinking providers from account settings, with a guard that prevents removal of the last sign-in method.
• Forgot-password flow lets people who only signed in via SSO set a password.
• Marketing login drops the v1 reference and surfaces the new buttons.
• Self-hosted operators get the same three providers by setting client IDs and secrets in environment variables.

Out of scope

• Providers beyond the three named.
• Account-level enforcement of SSO-only authentication.
• SAML or enterprise federation with customer identity providers.

Existing implementation

There's a generic OIDC login flow under lib/lightning/auth_providers/ built on the oauth2 hex package, with LightningWeb.OidcController as the entry point. It may have no production users; #4702 audits this.

The credential OAuth flow uses a different module (OauthHTTPClient) and isn't affected by this epic, but it shares the /authenticate/callback route via popup clauses on OidcController. The oauth2 cleanup is planned as a separate ticket outside this epic.