Anmeldeprovider konfigurieren.
Redirect-Provider können in Ihrer Bereitstellung einen kanonischen Callback teilen, während jeder Provider eigene Zugangsdaten und Protokollanforderungen behält.
Kanonischer Callback
https://auth.example.com/auth/federated/callback
Schema, Host, Pfad, Port und abschließender Slash müssen exakt mit der in der Upstream-Provider-Konsole registrierten URI übereinstimmen. Ersetzen Sie den Beispiel-Hostname durch Ihren öffentlichen Identity Origin.
Provider-Matrix
| Provider | Protokoll | Erforderliche Server-Zugangsdaten |
|---|---|---|
| OIDC | GOOGLE_CLIENT_ID + secret | |
| GitHub | OAuth | GITHUB_CLIENT_ID + secret |
| X | OAuth | Vom konfigurierten Flow benötigte Client-Zugangsdaten |
| Microsoft | OIDC | Client ID + Secret + Tenant Issuer |
| Apple | OIDC | Services ID + Client Secret oder Signing Key |
| OIDC | Client ID + secret | |
| Telegram | Providerspezifische Anmeldung | Anwendungszugangsdaten für die konfigurierte Integration |
Methoden ohne Redirect
Passkeys, EVM/SIWE, Farcaster, LDAPS und SAML verwenden andere Ceremony- und Vertrauensgrenzen als OAuth/OIDC-Redirect-Provider.
Passkeys
Binden Sie RP ID und Origin an Ihren öffentlichen Browser-Origin und halten Sie WebAuthn-Ceremonies First-Party.
EVM / SIWE
Signierte Challenges belegen die Kontrolle über die Wallet; Smart-Account-RPCs sind nur erforderlich, wenn Vertragsvalidierung notwendig ist.
Farcaster
Prüfen Sie den Sign-in-Payload und die von Ihrer Integration benötigte protokollspezifische Identitätsbeziehung.
SAML / LDAPS
Enterprise-Föderation hält Zertifikats-, Issuer-, Audience- und Transportvalidierung an der Protokollgrenze.