Provider Behavior
The mock IDP does not flatten providers into one generic OAuth shape — each provider type replicates the real provider’s wire behavior: which tokens are issued, the exact token response fields, the profile endpoints, and the ID token claim set. An app tested against a mock github client exercises the same code paths it would against real GitHub, so there is no protocol gap to discover in production.
The OAuth Flow page describes the shared authorization code flow; each provider page below describes how that provider type differs:
- Google — OIDC with Google’s fixed ID token claim set
- GitHub — plain OAuth2 with GitHub-shaped profile endpoints
- Facebook — plain OAuth2 with a Graph-style
GET /meprofile - Apple — OIDC with Apple’s form POST and privacy quirks
- Custom — the OIDC baseline provider, and the only one with custom claims support
Provider behavior matrix
Section titled “Provider behavior matrix”| GitHub | Apple | Custom | |||
|---|---|---|---|---|---|
| Protocol | OIDC | OAuth2 (no OIDC) | OAuth2 (no OIDC) | OIDC | OIDC |
id_token issued | Yes (scope openid) | Never | Never | Always for code flow | Yes (scope openid) |
| Custom claims | No | No | No | No | Yes |
token_type | "Bearer" | "bearer" (lowercase) | "bearer" | "Bearer" | "Bearer" |
expires_in in token response | Yes | Omitted (GitHub app tokens don’t expire) | Yes | Yes | Yes |
| PKCE | Optional S256 | Ignored (GitHub web flow has none) | Ignored | Optional S256 | Optional S256 |
| Profile endpoint | /oauth/userinfo | GET /user, GET /user/emails (GitHub-shaped) | GET /me | /oauth/userinfo | /oauth/userinfo |
| Token exchange | POST | POST | GET or POST (Graph uses GET) | POST | POST |
Cross-provider notes
Section titled “Cross-provider notes”Two behaviors apply across every provider type:
- Custom claims are a custom-provider feature — only
customclients accept the identityclaimsmap; create and update requests that setclaimson agoogle,github,apple, orfacebookclient are rejected with a400. See Custom. emailVerified,isActive, and the profile fields (username,name,avatarUrl) work on all provider types — see Clients & Identities.