OAuth 2.0 (with OpenID Connect for identity claims) is the standard protocol for delegated authentication. Instead of asking users to create a new password on your site, you redirect them to an identity provider (IdP) — Google, Apple, Microsoft, GitHub, Facebook — where they authenticate, and the IdP returns a token confirming who they are.
Why offer SSO buttons:
- Lower friction — users skip the "create another password" step. Conversion lift on signup forms is typically 20-40%.
- Better security — the IdP handles 2FA, password management, breach detection. You inherit their hardening.
- Less liability — you never store the user's actual password. Reduces blast radius of a database breach.
Pattern in the wild:
<a href="/auth/google" class="sso-btn">Continue with Google</a>
<a href="/auth/apple" class="sso-btn">Continue with Apple</a>
<a href="/auth/microsoft" class="sso-btn">Continue with Microsoft</a>
<button onclick="loginWithGitHub()">Sign in with GitHub</button>
Detection signals BeaverCheck looks for:
- Link
hrefcontaining the IdP's OAuth authorize URL:accounts.google.com/o/oauth2,appleid.apple.com/auth/authorize,login.microsoftonline.com,github.com/login/oauth, etc. - Button / anchor text matching "Sign in with X" / "Continue with X" / "Login with X" patterns.
Provider-specific notes:
- Apple Sign-In is REQUIRED on iOS apps that offer any other social SSO option (Apple Store policy). Doesn't apply to web, but many web apps add it for parity.
- Google One Tap is a different UX (no button click needed; auto-popup). Detected via
accounts.google.com/gsi. - Magic links (passwordless email) are a separate auth pattern — same security benefit (no password storage) without the third-party dependency.
Trade-off vs password-only auth: SSO depends on the IdP's uptime and policy. If Google has an outage, your "Continue with Google" users can't log in. Best practice: offer SSO AS AN OPTION, keep email-password (or magic-link) as a fallback.