Anmeldemethoden: Passkeys, Codes, Social Login, SSO

Aktivieren Sie eine Methode mit PUT methods/{name}/ und {"enabled": true} über die Authentifizierungsverwaltungs-API Ihrer Anwendung oder in der Konsole. Die gehostete Anmeldung zeigt nur die Methoden, die Sie aktiviert haben. Jeder JSON-Aufruf unten beginnt mit einer transaction aus POST authorize/. Diese Transaktion ist 10 Minuten gültig. Eine erfolgreiche Anmeldung gibt {code, redirect_uri, state} zurück. Tauschen Sie den Code innerhalb von 60 Sekunden bei POST token/ ein (siehe Token und JWKS). Anstelle eines Codes kann ein Anmeldeaufruf einen dieser Schritte zurückgeben. Schließen Sie den Schritt ab, dann erhalten Sie den Code.

​

Passwort

POST password/ nimmt transaction, email und password entgegen.

• Ein Passwort muss Ihre password_min_length erfüllen (8, 10, 12 oder 14 Zeichen; standardmäßig 10). Gängige und rein numerische Passwörter werden mit password_policy abgelehnt. Ist die Prüfung auf kompromittierte Passwörter aktiv, wird ein bekanntermaßen kompromittiertes Passwort mit password_breached abgelehnt.
• Nur Personen mit einer verifizierten E-Mail-Adresse können sich mit einem Passwort anmelden.
• Ein falsches Passwort, eine unbekannte E-Mail-Adresse, eine nicht verifizierte E-Mail-Adresse, ein gesperrtes Konto und ein blockiertes Konto liefern dieselbe Antwort: 400 {"error": "invalid_credentials"}. Ihre Oberfläche kann nicht erkennen, welcher Fall vorliegt, und ein Angreifer ebenso wenig.

​

Registrierung

Die Registrierung verifiziert zuerst die E-Mail-Adresse. Rufen Sie POST email/start/ mit purpose: "signup", email und password auf, danach POST email/complete/ mit dem Code. Das Konto wird mit einer verifizierten E-Mail-Adresse angelegt.

• signup_policy legt fest, wer sich registrieren kann: anyone, invited (nur mit einem Einladungslink) oder allowed_domains.
• Bei allow_subaddresses: false (Standard) wird eine Adresse mit + im lokalen Teil abgelehnt.
• Wenn Ihr Branding Links zu Nutzungsbedingungen oder Datenschutzerklärung festlegt, fordert das gehostete Registrierungsformular die Person auf, diese zu akzeptieren.

​

E-Mail-Code

POST email/start/ nimmt transaction, purpose (login oder signup) und email entgegen und gibt 202 {challenge, expires_in: 600} zurück. Die Person erhält einen 6-stelligen Code, der 10 Minuten gültig ist. POST email/complete/ nimmt transaction, purpose, challenge und code entgegen. Sie haben 5 Versuche. Danach muss die Person einen neuen Code anfordern. Die gehostete Seite bietet nach 30 Sekunden einen neuen Code an. Ein Anmeldecode für eine Adresse ohne Konto legt ein Konto an, wenn Ihre signup_policy das zulässt. Das ist eine passwortlose Registrierung.

​

Magic Link

Die gehostete Seite sendet einen Anmeldelink, der 15 Minuten gültig ist. Er bleibt an die ursprüngliche PKCE-Transaktion gebunden, daher funktioniert der Link nur in dem Ablauf, der ihn gestartet hat. Die Person bestätigt die Anmeldung auf der Seite, die sich mit dem Link öffnet. Für Magic Links gibt es keinen JSON-Endpoint.

​

Telefoncode

POST phone/start/ nimmt transaction, phone und optional channel (sms, Standard, oder whatsapp) entgegen. Die Nummer wird nach E.164 normalisiert. Die Antwort ist 202 {challenge, expires_in: 600}. POST phone/complete/ nimmt transaction, challenge und den 6-stelligen code entgegen. Sie haben 5 Versuche.

• Telefoncodes werden über die Telefonverifizierung von Didit zugestellt. Aktivieren Sie die Methode mit der workflow_id eines Workflows, der eine Telefonverifizierung enthält.
• Eine erste Anmeldung per Telefon legt nur dann ein Konto an, wenn signup_policy den Wert anyone hat.
• Schlägt die Zustellung fehl, gibt der Aufruf 503 {"error": "delivery_unavailable"} zurück.

​

Passkeys

Passkeys nutzen WebAuthn. Die vertrauende Partei ist der Anmelde-Ursprung Ihrer Anwendung. Didit fordert eine auffindbare Anmeldeinformation (Resident Key) an und verlangt immer eine Benutzerverifizierung, etwa per Fingerabdruck, Gesichtserkennung oder Geräte-PIN. Didit fordert keine Attestierung an.

• Eine Passkey-Challenge ist 5 Minuten gültig.
• Zum Hinzufügen eines Passkeys wird eine Sitzung benötigt, die in den letzten 5 Minuten erstellt wurde. Andernfalls gibt der Aufruf 403 {"error": "reauthentication_required"} zurück. Melden Sie die Person zuerst erneut an.
• Eine Anmeldung mit Passkey zählt als Multi-Faktor-Authentifizierung.
• Nach der Registrierung bietet die gehostete Seite an, einen Passkey hinzuzufügen (passkeys/setup/begin/ und passkeys/setup/complete/).
• Android-Apps, die für die Anwendung registriert sind, können dieselben Passkeys verwenden.

​

Social-Login

Google, Microsoft, Apple und GitHub verwenden Ihre eigenen OAuth-App-Zugangsdaten, die Sie mit PUT methods/{provider}/ und credentials: {client_id, client_secret} festlegen. Der Callback des Anbieters befindet sich auf Ihrem Anmelde-Origin. Beim ersten Anmelden mit einem Anbieter bestätigt die Person außerdem mit einem Code, dass sie die E-Mail-Adresse besitzt (POST social/email/start/ und POST social/email/verify/). Spätere Anmeldungen mit diesem Anbieter überspringen diesen Schritt. GitHub kann keine kürzlich erfolgte Anmeldung nachweisen. Deshalb wird GitHub nicht angeboten, wenn Sie prompt=login oder max_age senden.

​

Organisations-SSO

Organisations-SSO ermöglicht es dem Unternehmen eines Kunden, sich über seinen eigenen SAML- oder OIDC-Identity-Provider anzumelden. Konfigurieren Sie es pro Kundenorganisation unter organizations/{id}/sso/ mit protocol (saml oder oidc), enabled und config.

• Sie können dem IT-Team des Kunden einen Einrichtungslink senden, der 7 Tage gültig ist.
• Ihre SAML-Service-Provider-Metadaten werden unter {origin}/sso/saml/metadata/ veröffentlicht.
• Die gehostete Anmeldung findet die Verbindung anhand der verifizierten E-Mail-Domain der Person oder anhand von organization=<slug> in der Anmelde-URL.

​

Didit ID Wallet

Personen, die sich bereits bei Didit verifiziert haben, können sich mit ihrer Didit ID Wallet anmelden. Diese Methode ist immer aktiv. Das verified_identity-Feld der Sitzung enthält dann die Angaben, die die Person freigegeben hat.

​

MFA

Der zweite Faktor ist eine Authenticator-App (TOTP) mit Wiederherstellungscodes oder ein Passkey.

• mfa_policy legt fest, wer MFA verwenden muss: optional, everyone oder organization_admins (Standard). Wer einen Authenticator registriert hat, muss ihn immer verwenden.
• Um einen Authenticator zu registrieren, rufen Sie POST mfa/enroll/ mit einer neuen Sitzung auf (innerhalb der letzten 5 Minuten erstellt). Die Antwort enthält {challenge, uri}. Zeigen Sie die uri als QR-Code an. Senden Sie dann den ersten Code an POST mfa/confirm/. Die Antwort enthält 10 nur einmal verwendbare Wiederherstellungscodes. Zeigen Sie sie nur einmal an.
• Bei der Anmeldung senden Sie einen TOTP- oder Wiederherstellungscode zusammen mit der challenge an POST mfa/complete/. Sie erhalten 5 Versuche. Um stattdessen einen Passkey zu verwenden, rufen Sie POST mfa/passkey/begin/ und POST mfa/passkey/complete/ auf.
• Codes verwenden 30-Sekunden-Schritte. Ein Code, der bereits akzeptiert wurde, kann nicht erneut verwendet werden.
• SMS- und E-Mail-Codes sind nicht als zweiter Faktor verfügbar.

​

Passwort vergessen und zurücksetzen

POST password-reset/start/ nimmt email entgegen und gibt 202 {"status": "sent", "expires_in": 1800} zurück. Die Antwort ist dieselbe, unabhängig davon, ob die Adresse ein Konto hat. Der Reset-Link ist 30 Minuten gültig. POST password-reset/complete/ nimmt token und password entgegen und gibt {"status": "password_changed"} zurück. Außerdem:

• hebt es eine Sperre auf,
• beendet es alle Sitzungen, wenn revoke_on_password_change aktiviert ist (Standard),
• macht es andere ausstehende Codes und Links für diese Person ungültig.

​

Einladungen

Mit signup_policy: "invited" können sich nur eingeladene Personen registrieren. Ein Einladungslink ist 7 Tage gültig und öffnet die gehostete Seite /invite. Fahren Sie mit Tokens und JWKS fort oder lesen Sie Bot-Schutz für Sperren und Challenges.