The authentication claim
Digital authentication verifies that a claimant controls one or more authenticators bound to a subscriber account. A verifier checks the authentication protocol output. A relying party uses the result to establish or continue an authenticated session. The result identifies an account at a stated assurance. It does not grant access to every resource.
Roles and flow
A credential service provider enrolls the subscriber and binds authenticators. The claimant uses an authenticator. The verifier validates the response and relevant context. The relying party consumes the result. One organization can operate several roles, but the security responsibilities remain distinct.
Authentication and authorization
Authentication answers whether the current claimant controls the account's required authenticators. Authorization answers whether the resulting principal may perform an action on a resource in the current context. Keep the decisions and evidence separate.
Failure and residual risk
Strong authentication cannot correct a false enrollment, unsafe recovery, stolen authenticated session, wrong relying-party binding, or excessive authorization. Phishable authenticators can produce a valid result for an attacker. Session security matters after the ceremony completes.
Pomerium boundary
Pomerium relies on an OpenID Connect identity provider to authenticate users. It creates a local Pomerium session from the verified provider result and then applies separate route authorization. The application still owns permissions for its records and operations.
Evaluation checklist
- Which party enrolled the account and bound its authenticators?
- What does the verifier prove, and at which assurance level?
- Is the result bound to the intended relying party and session?
- Which separate authorization decision follows authentication?
- Can recovery or session theft bypass the normal ceremony?
