verified_claims object.
The same endpoints work for any relying party that speaks this profile, including Auth0 post-login Actions.
Endpoints
Every endpoint lives under the identity verification bridge base URL.| Environment | Base URL |
|---|---|
| Production | https://apx.didit.me/auth/idv |
| Sandbox | https://apx.staging.didit.me/auth/idv |
{base}/.well-known/openid-configuration advertises all of them:
| Purpose | Endpoint |
|---|---|
| Pushed Authorization Request | POST {base}/par |
| Authorization | GET {base}/authorize |
| Token | POST {base}/token |
| JWKS | GET {base}/jwks |
| Discovery | GET {base}/.well-known/openid-configuration |
client_secret_basic or client_secret_post.
The authorization code flow requires PKCE with code_challenge_method=S256.
ID tokens are signed with RS256; verify them against the JWKS endpoint.
Flow
- The relying party pushes the authorization request to
POST /par, including the PKCE challenge,state,nonce, its registeredredirect_uri, the scopesopenid profile identity_assurance, and the claims it wants verified. Didit returns a single-userequest_urithat is valid for 60 seconds. - The relying party redirects the user’s browser to
GET /authorize?request_uri=.... Didit creates a verification session and sends the user into the hosted verification flow. - When the user finishes, Didit evaluates the verification decision, compares the extracted identity against the claims that were pushed, and returns the user to the relying party’s
redirect_uriwith a one-timecodeand the originalstate. - The relying party exchanges the code at
POST /tokenwith itscode_verifierand receives a signed ID token.
Requesting claims
Send the claims to compare inside the standard OpenID Connectclaims parameter of the PAR request.
Both given_name and family_name are supported, and both are always compared fuzzily.
verified_claims is an array, matching Okta’s BYO IDV profile and the ID token response below.
The ID token
The ID token carries averified_claims array. assurance_level is VERIFIED only when the verification session was approved and every requested claim matched the verified document.
Otherwise it is FAILED.
verification_process is the Didit session id, so you can look the verification up in the console or through the sessions API.
Treat the user as verified only when
trust_framework is IDV-DELEGATED and assurance_level is VERIFIED.
Any other combination means the verification did not succeed.Configure Okta
In the Okta Admin Console, add a custom identity verification vendor and fill in the values below. Okta creates the integration as an identity provider of typeIDV_STANDARD with protocol ID_PROOFING, and you then reference it from an Account Management Policy rule.
| Field | Value |
|---|---|
| Issuer | https://apx.didit.me/auth/idv |
| PAR request URL | https://apx.didit.me/auth/idv/par |
| Authorize URL | https://apx.didit.me/auth/idv/authorize |
| Token URL | https://apx.didit.me/auth/idv/token |
| JWKS URL | https://apx.didit.me/auth/idv/jwks |
| Scopes | openid, profile, identity_assurance |
| Client ID / Client secret | Provided by Didit |
{yourOktaOrgUrl}/idp/identity-verification/callback.
Configure Auth0
Auth0 has no native IDV vendor slot, so verification runs from a post-login Action that redirects the user into the same flow. StoreDIDIT_IDV_BASE, DIDIT_CLIENT_ID and DIDIT_CLIENT_SECRET as Action secrets, and register https://{yourAuth0Domain}/continue as the redirect URI with Didit.
Auth0 appends its own
state to the /authorize redirect so it can resume the login. Didit adopts that state and echoes it back to /continue, which is what lets Auth0 complete the transaction - you don’t thread Auth0’s state through the PAR body (it isn’t generated until the redirect).Store the PKCE
code_verifier per login transaction (keyed by event.transaction.id), not in a single app_metadata field.
If a user retries or runs an overlapping login, a single shared field gets overwritten and the token exchange fails with invalid_grant.Errors
Errors follow RFC 6749 and RFC 9126. Failed client authentication returns401 with {"error": "invalid_client"}; an expired or replayed request_uri or authorization code returns 400 with invalid_request or invalid_grant.
Authorization codes, request_uri values, and verification sessions are all single use.