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
- Die Relying Party sendet den Authorization Request an
POST /par, einschließlich der PKCE-Challenge,state,nonce, ihrer registriertenredirect_uri, den Scopesopenid profile identity_assuranceund den Claims, die verifiziert werden sollen. Didit gibt eine einmalig nutzbarerequest_urizurück, die für 60 Sekunden gültig ist. - 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. - 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-
codeund dem ursprünglichenstatezurredirect_urider Relying Party zurück. - Die Relying Party tauscht den Code an
POST /tokenmit ihremcode_verifieraus und erhält ein signiertes ID-Token.
Claims anfordern
Senden Sie die abzugleichenden Claims innerhalb des standardmäßigen OpenID Connect-Parametersclaims 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 einverified_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 TypIDV_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 SieDIDIT_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 gibt401 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.