Configure sign-in providers.
Redirect providers can share a canonical callback in your deployment, while each provider keeps its own credentials and protocol requirements.
Canonical callback
https://auth.example.com/auth/federated/callback
Scheme, host, path, port and trailing slash must match the URI registered in the upstream provider console. Replace the example hostname with your own public identity origin.
Provider matrix
| Provider | Protocol | Required server credentials |
|---|---|---|
| OIDC | GOOGLE_CLIENT_ID + secret | |
| GitHub | OAuth | GITHUB_CLIENT_ID + secret |
| X | OAuth | Client credentials required by your configured flow |
| Microsoft | OIDC | Client ID + secret + tenant issuer |
| Apple | OIDC | Services ID + client secret or signing key |
| OIDC | Client ID + secret | |
| Telegram | Provider-specific sign-in | Application credentials for your configured integration |
Non-redirect methods
Passkeys, EVM/SIWE, Farcaster, LDAPS and SAML use different ceremony and trust boundaries than redirect OAuth/OIDC providers.
Passkeys
Bind RP ID and origin to your public browser origin and keep WebAuthn ceremonies first-party.
EVM / SIWE
Signed challenges prove wallet control; smart-account RPCs are needed only when contract validation is required.
Farcaster
Verify the sign-in payload and the protocol-specific identity relationship required by your integration.
SAML / LDAPS
Enterprise federation keeps certificate, issuer, audience and transport validation at the protocol boundary.