What Your Application Receives

OIDC Web logins are deliberately data-minimal. A face verification does not read a document and does not look up a person. The result claims therefore describe the verification, not a personal profile:

Claim	Content
sub	The OIDC subject identifier. Unique per authentication session — it never repeats. Correlate users through the login_hint you supplied, not through sub.
acr / amr	The assurance signals: acr carries the verification level performed (see Verification Levels) and amr contains face. Always validate these.
login_hint	Echo of the identifier your application sent, binding the result to your user.
email, preferred_username	If the login_hint you sent is an email address, it is echoed back in these standard claims for convenience.
id.iproov:face_present	An audit claim with metadata about the verification: method, verifying server, and timestamp. The claim is bound to the state of this very authorization request, so a verification result can never be replayed into another login. Contains no personal data.
id.iproov:validation_portrait_present	(On request.) A portrait of the user captured during the liveness check, as a data-URI image. Dynamic Liveness yields a passport-style face crop; Express Liveness a wide-angle frame. Lets you run your own additional face-matching without sharing your reference photo with iProov.

Any other claim your application requests is ignored — there is no document or profile data to return. OIDC Web logins also issue no refresh tokens. The product's promise is that every authentication is a fresh live verification. We therefore provide no way to mint a new token without one.

Retries. A login request allows the user up to three attempts at the face scan. After the third failure (or if the user cancels), OIDC Web redirects the browser back to your application with a standard OIDC error response. Your application then decides what happens next: issue a fresh login request (granting new attempts), lock the account, or rate-limit the source.