How to Read This Guide

iProov OIDC Web is a standards-compliant OpenID Provider (OP) whose login is a live face verification in the user's browser. If you've integrated an OpenID Connect (OIDC) provider before, the mechanics here will feel familiar. The endpoints, parameters, and tokens are all plain OIDC and OAuth 2.0.

Your integration makes exactly three decisions, and this guide is organized around them:

1. Which verification level — selected by the scope (see Enabling OIDC Web: The faceauth Scopes).
2. What the face is compared against — selected by login_hint (see Choosing the Authentication Mode).
3. Which OIDC flow carries the request — covered in Auth Code Flow through CIBA with one principle throughout:

Starting a login is expensive. Every authorization request that reaches the verification stage consumes a real iProov verification credit. Each request also counts against your rate-limited allowance. Unlike a password form, you can't afford to let unauthenticated parties trigger logins against your account. Use signed authorization requests (JAR), ideally with Pushed Authorization Requests (PAR). Signing is the single most important recommendation in this guide.

We show the unsigned Authorization Code flow first (see Auth Code Flow) because it's the clearest way to learn the moving parts. We then show how to upgrade it to the recommended signed flow (see JAR), which is a small mechanical change on top. For production, implement JAR.

Conventions used in examples:

• $BASE is the base URL of your OIDC Web environment (see Environments).
• $CLIENT_ID is your registered client identifier.
• Shell examples use curl; we add short Python/JavaScript snippets where the logic isn't obvious from curl alone.
• Wherever an example hardcodes an endpoint, that's for readability only. In real code, read endpoints from the discovery document (see Environments).