Zum Hauptinhalt springen
Didit stellt einen OpenID Connect-Autorisierungsserver bereit, der speziell für die delegierte Identitätsverifizierung entwickelt wurde. Er implementiert den Vertrag, den das „Bring your own identity verification vendor“-Framework (BYO IDV) von Okta erwartet: Pushed Authorization Requests (PAR, RFC 9126), den Authorization Code Flow mit PKCE und ein ID-Token, das ein OpenID Connect verified_claims-Objekt enthält. Dieselben Endpoints funktionieren für jede Relying Party, die dieses Profil unterstützt, einschließlich Auth0 Post-Login Actions.

Endpoints

Jeder Endpoint befindet sich unter der Basis-URL der Identitätsverifizierungs-Bridge. Produktion und Sandbox verwenden dieselben Endpoints. Die Anwendung, die mit Ihren Client-Anmeldedaten verknüpft ist, bestimmt die Umgebung. Verwenden Sie separate Client-Anmeldedaten und einen Workflow, der zur entsprechenden Anwendung gehört, für jede Umgebung. Siehe Sandbox und Testdaten für simulierte Verifizierungsergebnisse. Das Discovery-Dokument unter {base}/.well-known/openid-configuration führt sie alle auf: Die Client-Authentifizierung verwendet client_secret_basic oder client_secret_post. Der Authorization Code Flow erfordert PKCE mit code_challenge_method=S256. ID-Tokens werden mit RS256 signiert; überprüfen Sie diese anhand des JWKS-Endpoints.

Flow

  1. Die Relying Party sendet den Authorization Request an POST /par, einschließlich der PKCE-Challenge, state, nonce, ihrer registrierten redirect_uri, den Scopes openid profile identity_assurance und den Claims, die verifiziert werden sollen. Didit gibt eine einmalig nutzbare request_uri zurück, die für 60 Sekunden gültig ist.
  2. Die Relying Party leitet den Browser des Benutzers zu GET /authorize?request_uri=... weiter. Didit erstellt eine Verifizierungssitzung und leitet den Benutzer in den gehosteten Verifizierungs-Workflow.
  3. Wenn der Benutzer den Vorgang abschließt, wertet Didit die Verifizierungsentscheidung aus, gleicht die extrahierte Identität mit den per Push übermittelten Claims ab und leitet den Benutzer mit einem Einmal-code und dem ursprünglichen state zur redirect_uri der Relying Party zurück.
  4. Die Relying Party tauscht den Code an POST /token mit ihrem code_verifier aus und erhält ein signiertes ID-Token.

Claims anfordern

Senden Sie die abzugleichenden Claims innerhalb des standardmäßigen OpenID Connect-Parameters claims des PAR-Requests. Sowohl given_name als auch family_name werden unterstützt, und beide werden stets fehlertolerant abgeglichen. verified_claims ist ein Array, passend zum BYO-IDV-Profil von Okta und der unten dargestellten ID-Token-Antwort.

Das ID-Token

Das ID-Token enthält ein verified_claims-Array. assurance_level ist nur dann VERIFIED, wenn die Verifizierungssitzung genehmigt wurde und jeder angeforderte Claim mit dem verifizierten Dokument übereinstimmt. Andernfalls lautet der Wert FAILED.
verification_process ist die Sitzungs-ID von Didit, sodass Sie die Verifizierung in der Konsole oder über die Sitzungs-API nachschlagen können.
Betrachten Sie den Benutzer nur dann als verifiziert, wenn trust_framework gleich IDV-DELEGATED und assurance_level gleich VERIFIED ist. Jede andere Kombination bedeutet, dass die Verifizierung nicht erfolgreich war.

Okta konfigurieren

Bitten Sie Didit darum, die Identitätsverifizierung für Ihre Produktions- und Sandbox-Anwendungen zu aktivieren, jede mit ihrem jeweiligen Verifizierungs-Workflow zu verknüpfen und die genaue Callback-URL für jeden Okta-Tenant zu registrieren. Eine bestehende Anwendung oder ein API-Schlüssel allein aktiviert diese Integration nicht. Fügen Sie in der Okta Admin Console einen benutzerdefinierten Anbieter für Identitätsverifizierung hinzu und tragen Sie die unten stehenden Werte ein. Okta erstellt die Integration als Identitätsanbieter vom Typ IDV_STANDARD mit dem Protokoll ID_PROOFING. Anschließend verweisen Sie in einer Regel der Account Management Policy darauf. Konfigurieren Sie Produktion und Sandbox als separate Identitätsverifizierungs-Integrationen mit den jeweiligen Anmeldedaten. Verwenden Sie die oben genannten Endpoints für beide. Das Client Secret ist erforderlich, obwohl der Flow zusätzlich PKCE verwendet. Ein separat erstellter benannter API-Schlüssel kann den primären API-Schlüssel der Anwendung für diese Integration nicht ersetzen. Teilen Sie Didit Ihre Callback-URL mit, damit diese für Ihren Client registriert werden kann. Okta setzt diese als {yourOktaOrgUrl}/idp/identity-verification/callback zusammen.

Auth0 konfigurieren

Auth0 verfügt über keinen nativen IDV-Anbieter-Slot, sodass die Verifizierung über eine Post-Login Action ausgeführt wird, die den Benutzer in denselben Flow weiterleitet. Hinterlegen Sie DIDIT_IDV_BASE, DIDIT_CLIENT_ID und DIDIT_CLIENT_SECRET als Action Secrets und registrieren Sie https://{yourAuth0Domain}/continue als Redirect-URI bei Didit.
Auth0 hängt seinen eigenen state an die Weiterleitung zu /authorize an, um den Login fortsetzen zu können. Didit übernimmt diesen state und gibt ihn an /continue zurück. Dadurch kann Auth0 die Transaktion abschließen – Sie müssen den Auth0-State nicht im PAR-Body übergeben (er wird erst bei der Weiterleitung generiert).
Speichern Sie den PKCE-code_verifier pro Login-Transaktion (mit event.transaction.id als Schlüssel) und nicht in einem einzelnen app_metadata-Feld. Wenn ein Benutzer einen erneuten Versuch startet oder ein paralleler Login gestartet wird, wird ein einzelnes gemeinsames Feld überschrieben und der Token-Austausch schlägt mit invalid_grant fehl.

Fehler

Fehler folgen RFC 6749 und RFC 9126. Eine fehlgeschlagene Client-Authentifizierung gibt 401 mit {"error": "invalid_client"} zurück; ein abgelaufener oder wiederverwendeter request_uri oder Autorisierungscode gibt 400 mit invalid_request oder invalid_grant zurück. Autorisierungscodes, request_uri-Werte und Verifizierungssitzungen sind alle nur einmalig verwendbar.
Zuletzt geändert am 7. November 2026