GitHub-based sign-in is the default for developer-facing products. Your users already have a GitHub account; "Sign in with GitHub" is a familiar one-click path with no new password to remember.
GitHub is an OAuth 2.0 provider, not strictly an OIDC one — IntelliAuth handles the slight difference and surfaces a normal IntelliAuth user to your application.
Before you start
Section titled “Before you start”You need a GitHub OAuth App. Create one at https://github.com/settings/developers:
- New OAuth App.
- Application name → whatever your users will see ("Cymmetri Banking").
- Homepage URL → your app's marketing or login URL.
- Authorisation callback URL — fill in step 1 below.
Keep the client ID + client secret handy.
Step 1 — register the callback URL
Section titled “Step 1 — register the callback URL”Set the GitHub OAuth App's Authorization callback URL to:
https://<your-tenant-url>/auth/callback/githubFor example https://banking-cymmetri.intelliauth.local/auth/callback/github. GitHub allows only one callback URL per OAuth App, so if you need separate dev and prod tenants, register two OAuth Apps.
Step 2 — connect it in IntelliAuth
Section titled “Step 2 — connect it in IntelliAuth”In the tenant admin console: Authentication → Social providers → GitHub. Paste the client ID and client secret. Save.
The connection is live immediately.
Step 3 — add the button in your app
Section titled “Step 3 — add the button in your app”const { loginWithRedirect } = useIntelliAuth()
<button onClick={() => loginWithRedirect({ connection: 'github' })}> Sign in with GitHub</button>connection: 'github' tells the SDK to skip the IntelliAuth-hosted picker and go straight to GitHub.
What ends up in the user record
Section titled “What ends up in the user record”GitHub's user info shape is slightly different from a strict OIDC provider, but IntelliAuth normalises it:
sub— the GitHub numeric user id (stable; usernames can change).email— the user's primary GitHub email if it is public. If not, IntelliAuth fetches it through the GitHub API using theuser:emailscope.email_verified— true only for GitHub-verified emails.name— the user's GitHub display name.picture—avatar_url.
The "private email" pitfall
Section titled “The "private email" pitfall”Many developers keep their primary email private on GitHub. By default GitHub's /user endpoint then returns no email. IntelliAuth's GitHub connection automatically requests the user:email scope, which lets it call the separate /user/emails endpoint and pick the verified primary email.
If your tenant policy strictly requires verified email, this works for users with at least one verified email on file. For users whose GitHub account has no verified email at all (rare, but possible), the sign-in flow will fail at the policy check; you can either relax the policy or block these users.
Org-restricted access
Section titled “Org-restricted access”GitHub OAuth Apps can be scoped to a GitHub organisation. If your tenant should only accept users from cymmetri org members, configure the OAuth App accordingly (Organization Access in the app settings) and surface the requirement in your sign-in copy. Users not in the org cannot complete the flow.
For finer-grained policy (only members of a specific team, only users with a specific role), put the check on your side — read the groups or teams claim from the user info and gate access in your app.
Scopes
Section titled “Scopes”By default, IntelliAuth requests read:user user:email from GitHub:
read:user— basic profile (name, avatar, public profile fields).user:email— verified email addresses.
You can ask for more by configuring the connection's "Additional scopes" — repo to read private repositories, admin:org for org administration, etc. Be sparing; GitHub shows users the exact list at consent time, and the broader your ask, the more likely they walk away.