Security Posture
Six properties define OIDC Web's security posture:
| Property | What it means |
|---|---|
| Verified, not asserted | A successful OIDC Web login reflects a real live-face verification, not a self-asserted credential. The standard acr/amr signals carry the assurance. The audit claim binds the verification to the specific login request, so your application can enforce its own policy and rule out replay. |
| Phishing-resistant by construction | There is no code, password, or approval prompt for an attacker to phish. The factor is the user's live face, checked for genuine presence. |
| Data minimization | The result describes the verification, not the person. A liveness-only login shares no personal data at all. |
| No shared secrets required | Signed-request and public-client configurations let you integrate without a long-lived shared secret, removing a common leak vector. |
| Resource-abuse resistance | Signed requests and PAR ensure that only your legitimately registered application can initiate the expensive verification step, protecting both availability and cost (see Why We Prefer Signed Authorization Requests). |
| Token theft resistance | DPoP and mTLS-bound tokens ensure that a leaked access token cannot be replayed by an attacker who lacks the corresponding key. |
OIDC Web is not a substitute for your application's own session management, authorization rules, or transport security. OIDC Web authenticates that a live person verified at one moment in time. With a profile, the login also proves the same person returned. What the user may then do remains your application's responsibility.
For step-by-step integration instructions, worked examples, the user-management API reference, and the recommended signed-request implementation, see the Integration & User Guide.