Social login
Signing up with a Google, GitHub, or Apple account you already have, instead of creating one more password.
See it
What it is
Social login is signup and sign-in through an account the person already has: Google, Apple, GitHub, Microsoft, Facebook. Underneath it is OAuth 2.0, usually with OpenID Connect on top, though some providers (GitHub and Facebook among them) run their own provider-specific identity flow instead. Your app never sees a password, and the provider hands back a stable subject ID. Email is the part people assume and should not: it can be absent, hidden behind a relay address, or present but unverified. Key the account on issuer or provider plus that subject ID, and treat the email as optional until something verifies it. Fewer signup fields usually means measurably higher conversion.
Pick the buttons that match the audience, not all of them: GitHub for developer tools, Google for basically everyone, Microsoft for corporate, Apple if you ship an iOS app (App Store rules require it when you offer other social options). Two or three buttons plus email is the sweet spot. A wall of eight is a decision problem.
The gotcha everyone hits is account linking. The same human signs up with Google in March and clicks GitHub in June, and you now have two accounts and a support ticket. The safe default is to ask them to sign in with the original method first, then attach the new provider. Never auto-merge on an unverified email, and be careful even with a verified one, since addresses get reassigned and providers differ in what their verification actually promises. Also plan for 'Hide My Email' from Apple and for the day a user loses access to the provider account.
Ask AI for it
Add social login to this app with Google, GitHub, and Apple buttons on the sign-in screen, above a divider and an email fallback. Use OpenID Connect through [auth library] where the provider supports it and the provider's own identity endpoint where it does not, and request only the profile and email scopes. On callback, key the identity on issuer or provider plus subject ID, never on email alone, and treat a missing or unverified email as normal rather than an error. If the identity is new but the email matches an existing user, do not merge silently: prompt them to sign in with their existing method and link from there. Show provider logos with correct branding, keep the buttons the same width, and handle the user-cancelled case without an error page.