Social Login (OAuth Providers)
Authentication via third-party identity providers like Google, GitHub, or Apple using OAuth 2.0/OIDC, allowing users to sign in with existing accounts.
Description
Social login allows users to authenticate with your application using their existing accounts from third-party providers (Google, GitHub, Facebook, Apple, Microsoft, Twitter). Under the hood, this uses OAuth 2.0 authorization code flow (often with OIDC for identity) to securely exchange authentication data. The user is redirected to the provider, consents to sharing specific profile information, and is redirected back with an authorization code that your server exchanges for tokens containing the user's identity.
Implementing social login reduces friction by eliminating registration forms and password management for users. It also offloads the security burden of credential storage to providers who invest heavily in account security. However, it introduces dependencies on third-party availability and requires handling edge cases: users signing up with email who later try social login (account linking), users with multiple social providers linked to one account, provider API changes or deprecations, and users who revoke access from the provider side.
Each provider has its own developer console, scopes, and quirks. Google requires verification for sensitive scopes. Apple mandates social login support if you offer any social login on iOS. GitHub provides user email via a separate API call. Facebook's API changes frequently. Implementation should use a library like Passport.js (Node.js), NextAuth.js/Auth.js, or OmniAuth (Ruby) that abstracts provider differences. Store the provider name and provider-specific user ID as a linked identity, not as the primary user identifier. Implement proper state parameter validation for CSRF protection, and always verify the ID token or fetch user info server-side rather than trusting client-side claims.
Prompt Snippet
Implement social login using NextAuth.js (or Auth.js) with Google, GitHub, and Apple providers. Configure OAuth apps in each provider's developer console with strict redirect URI matching. Use the authorization code flow with PKCE for all providers. Store linked identities in an accounts table with (user_id, provider, provider_account_id) columns and a unique constraint on (provider, provider_account_id). Implement account linking: if a user signs in with a social provider whose email matches an existing account, prompt for password verification before linking. Verify the email_verified claim from the ID token before trusting the email. Handle Apple's 'hide my email' relay addresses gracefully.
Tags
Related Terms
OAuth 2.0
An authorization framework that enables third-party applications to obtain limited access to a web service on behalf of a resource owner.
OpenID Connect (OIDC)
An identity layer built on top of OAuth 2.0 that enables clients to verify the identity of the end-user and obtain basic profile information.
SSO (Single Sign-On)
An authentication scheme that allows users to authenticate once and gain access to multiple independent applications without re-entering credentials.
Session Management
The practice of securely creating, maintaining, and destroying user sessions to track authenticated state across stateless HTTP requests.
Magic Link Authentication
A passwordless authentication method that sends a unique, time-limited login link to the user's email address, granting access when clicked.