Social providers let your users sign in with an account they already have — Google, GitHub, Microsoft, Apple. The user clicks "Continue with Google" on your sign-in page, gets redirected to Google, signs in there, comes back signed in to your tenant.
The list view
Section titled “The list view”Authentication → Social providers. Lists every configured social connection plus the available unconfigured ones.
Each provider is a separate configuration. Add a provider by clicking it; remove a configured provider by opening it and clicking Delete.
Per-provider configuration
Section titled “Per-provider configuration”Each provider has a similar shape:
- Enabled toggle — controls whether the button shows on the sign-in page.
- Display name — what the button says ("Sign in with Google", "Continue with GitHub"). Defaults are sensible.
- Client ID — the OAuth client id you registered on the provider's side.
- Client secret — the OAuth client secret (kept server-side; never exposed to users).
- Scopes — what to request from the provider. Defaults:
openid email profile. Add more for richer user data (e.g., Google's calendar scope) but be sparing — every additional scope is a permission the user sees at consent. - Attribute mapping — how provider claims map to IntelliAuth user fields. Defaults are sensible per-provider; override for non-standard providers.
Save. The button appears on the sign-in page immediately.
Per-provider notes
Section titled “Per-provider notes”The most common social provider. Setup on the Google Cloud Console: create an OAuth 2.0 client of type "Web application"; add IntelliAuth's callback URL (https://<tenant>-<org>.<domain>/auth/callback/google); copy client ID + secret.
The full setup walk for developers is in Sign in with Google.
GitHub
Section titled “GitHub”The right choice for developer-facing tenants. Setup at GitHub OAuth Apps. Callback URL: https://<tenant>-<org>.<domain>/auth/callback/github.
GitHub's quirk: users can keep their primary email private. The platform handles this by requesting the user:email scope and reading verified emails through GitHub's /user/emails endpoint. See Sign in with GitHub.
Microsoft
Section titled “Microsoft”Connects to Microsoft Entra (formerly Azure AD). Setup in the Entra portal → App registrations. Decide between single-tenant (only your Entra users) vs multi-tenant (any Microsoft user). The platform supports either.
App Store policy requires Sign in with Apple if you offer any other social sign-in on iOS. Setup is the most involved of the four — Service ID, Team ID, Key ID, .p8 private key. Three Apple-specific quirks: email-relay addresses, single-event name claims, key rotation.
See Sign in with Apple for the full walk.
Custom OIDC
Section titled “Custom OIDC”For any OIDC provider not in the built-in list (Okta, Keycloak, Authentik, Zitadel, custom partner IDP). Provide an issuer URL; the platform discovers endpoints + JWKS.
This is also the right path for B2B "our customer has their own IdP" scenarios where the customer's IdP speaks OIDC. See Custom OIDC provider.
Attribute mapping
Section titled “Attribute mapping”Each provider returns different claim names; the platform maps them to IntelliAuth user fields. The defaults work for most cases.
For Google:
| Provider claim | IntelliAuth field |
|---|---|
sub | external_subject |
email | |
email_verified | email_verified |
name | name |
given_name | given_name |
family_name | family_name |
picture | picture |
For GitHub, similar but with login mapped to a custom attribute github_username if you want it on the user record.
For Microsoft, similar but with oid (Entra object id) often mapped to a custom attribute for cross-reference with Microsoft Graph.
Customise in the connection's Advanced tab. Map non-standard claims to custom attributes if your application needs them.
Account linking
Section titled “Account linking”When a user signs in with Google for the first time, does the platform create a new user, or link to an existing user with the same email?
- Email-matched (default) — if the Google identity's email matches an existing IntelliAuth user, the Google identity is linked. The user can sign in either way (password OR Google) after that.
- Strict — no auto-link. Google sign-in always creates a new user record (or matches an existing user only by external
sub).
Email-matched is friendlier but trusts the email. For Google, this is fine — Google verifies emails. For GitHub, the email is less trustworthy (users can claim emails they don't verify); the platform handles this by requiring email_verified: true from the provider before linking.
Configure linking behaviour per-provider in the connection's Advanced tab.
Disable / delete
Section titled “Disable / delete”- Disable — toggle off. The button stops showing on the sign-in page. Existing users who linked the provider can still use their other identities (password, other socials). They CAN'T sign in via the disabled provider until you re-enable. No data is lost.
- Delete — removes the connection configuration entirely. Existing users who only had this provider's identity can no longer sign in.
Default to disable. Delete only when you're sure no users depend on it.
Every social sign-in records:
federation.sso_completedon success — with provider name + external subject + the user_id matched / created.federation.sso_failedon failure — with the specific error.
Filter audit on these to investigate "why are Google sign-ins suddenly failing?" patterns.