サインインプロバイダーを設定する。
redirect provider はデプロイ内で canonical callback を共有できますが、各 provider は固有の credential とプロトコル要件を保持します。
Canonical callback
https://auth.example.com/auth/federated/callback
完全一致が重要です
scheme、host、path、port、trailing slash は、上流 provider console に登録した URI と完全一致する必要があります。例の hostname は自分の public identity origin に置き換えてください。
プロバイダーマトリクス
| プロバイダー | プロトコル | 必要な server credential |
|---|---|---|
| OIDC | GOOGLE_CLIENT_ID + secret | |
| GitHub | OAuth | GITHUB_CLIENT_ID + secret |
| X | OAuth | 設定した flow が必要とする client credential |
| Microsoft | OIDC | Client ID + secret + tenant issuer |
| Apple | OIDC | Services ID + client secret または signing key |
| OIDC | Client ID + secret | |
| Telegram | Provider 固有のサインイン | 設定済み統合用の application credential |
redirect を使わない方式
Passkey、EVM/SIWE、Farcaster、LDAPS、SAML は、redirect 型 OAuth/OIDC provider とは異なる ceremony と trust boundary を使用します。
⌁
Passkeys
RP ID と origin を公開 browser origin に結び付け、WebAuthn ceremony は first-party として扱ってください。
Ξ
EVM / SIWE
署名済み challenge はウォレット制御を証明します。smart-account RPC が必要なのは contract validation が必要な場合だけです。
F
Farcaster
sign-in payload と、統合に必要なプロトコル固有の identity relationship を検証してください。
◇
SAML / LDAPS
Enterprise federation は certificate、issuer、audience、transport の検証をプロトコル境界に保持します。