Social sign-in
Social sign-in lets a user sign in with an account they already have — Google, GitHub, Microsoft, and others — instead of creating a new password. It runs inside the same sign-in flow as everything else: ID presents the provider buttons, handles the round-trip to the provider, and returns the same token to your app. From your app's side, nothing changes.
How it fits the sign-in flow
You already send users to ID to sign in (see Sessions). When a provider is enabled, ID's sign-in page shows it as an option alongside email and password:
1. Your app sends the user to ID's sign-in page (the same flow as always).
2. The user picks a provider and approves access at that provider.
3. The provider returns the user to ID.
4. ID redirects back to your app with a one-time code.
5. Your app exchanges the code for a token — the same token as any other sign-in.
Because the provider step happens between ID and the provider, your app needs no provider-specific code. The token you get back works the same way: send it as Authorization: Bearer <JWT> on API calls. A user who signs in with Google one day and email the next is the same user, as long as the provider account uses the same verified email.
Enabling a provider
Providers are configured once for your tenant, not per app. To turn one on you:
- Register your app with the provider (for example, create an OAuth app in the provider's developer console) and get its client ID and secret.
- Give those credentials to your platform administrator to register the provider with ID for your tenant.
- Set the provider's allowed redirect URL to ID's callback address, which your administrator provides.
Once the provider is registered, its button appears on the sign-in page for everyone in your tenant. To offer a new provider later, repeat these steps; you don't ship an app change.
Troubleshooting
- The provider button doesn't appear — the provider isn't registered for your tenant yet, or its credentials are missing. Confirm the registration with your administrator.
- The provider rejects the sign-in — the redirect URL configured at the provider must exactly match ID's callback address, including scheme and path.
- A user ends up with two separate accounts — this happens when the provider account's email differs from, or isn't verified against, the email they used before. Have the user sign in with the same verified email each time.
What's next
- Sessions — the sign-in flow this builds on, and how to use the token.
- Multi-factor authentication — add a second factor on top of any sign-in method.