Authentication methods
Your application starts the same hosted authorization flow regardless of the chosen sign-in method. Oathvera presents the methods allowed by the workspace, application and organization policy and completes required verification before returning a code.
Choose a baseline
Section titled “Choose a baseline”Configure Authentication at workspace level. In an application’s Connections tab, inherit the workspace defaults or choose permitted methods and stronger requirements. Changing methods or policy can end existing sessions or pending sign-ins; plan changes around your users’ access.
| Method | Experience and requirements |
|---|---|
| Email + password | Password sign-in. Current password bounds are 15–128 characters. Registration and contact verification follow policy. |
| Username + password | An optional identifier for password sign-in when enabled; not a separate identity store. |
| Passkey | FIDO2/WebAuthn sign-in with a discoverable credential and required user verification. Depends on browser/device support and the authentication hostname. |
| Email OTP | A six-digit, single-use code, valid for five minutes, bound to the initiating browser flow. |
| Email magic link | A five-minute, browser-bound link with an explicit confirmation step. Opening the URL alone does not consume the proof. |
| Social login | Google, Microsoft, Apple or GitHub, after workspace provider configuration and application permission. |
| Enterprise SSO | SAML or enterprise OIDC through the application’s organization and connection. |
Email and provider methods require their delivery/provider configuration to work. Enabling a toggle is not proof that email delivery or provider sign-in has passed live acceptance. Compatibility records those boundaries.
MFA and recovery
Section titled “MFA and recovery”| Capability | Behavior |
|---|---|
| Authenticator app | TOTP second-factor codes. A successfully accepted time step cannot be reused as another proof. |
| Security key / device authenticator | A WebAuthn factor for MFA. A primary passkey does not count again as an independent second factor in the same sign-in. |
| Recovery codes | Ten single-use codes for controlled factor replacement after primary authentication. They do not replace proof of the primary identity. |
Optional MFA lets users enroll protection; it does not mean an enrolled factor can be skipped during normal sign-in. Required MFA makes enrollment/verification part of completing access. Recovery-code policy requires an available MFA method.
A recovery code authorizes the factor-replacement flow, followed by enrollment of a new usable factor. It is not a general passwordless login code, administrative bypass, or a way to recover a lost sole primary passkey. Preserve a usable recovery route before changing method policy.
Account lifecycle
Section titled “Account lifecycle”Users and factors are shared at workspace level; application access and organization membership remain separate. Do not create duplicate identities for each client. Do not automatically link a social or enterprise identity because an email matches an existing account.
Credential and factor replacement can invalidate sessions across applications. Removing application access affects that application’s authority. Applications must respond to revoked access with a fresh sign-in or a clear access-denied state, not silently re-create a revoked grant.
Use the hosted enrollment, sign-in and recovery screens. Internal /auth/... form endpoints, transaction cookies and private management routes are implementation details, not a public credential-collection API for embedding in your product.
Acceptance
Section titled “Acceptance”Exercise successful login, invalid proof, expiration, reuse, cancellation and recovery for each enabled method. For passkeys, include the actual production hostname, target browser/device and at least one recovery scenario. For email, verify delivery and confirmation in the browser that initiated the flow. Test application policy changes and workspace suspension against existing tokens, not only new sign-ins.
Passkey setup and account security
Section titled “Passkey setup and account security”A limited production rollout offers optional post-sign-in passkey setup, passkey naming, browser autofill where supported, and hosted Account Security. Confirm availability in the selected application quickstart. Browser/device acceptance and wider rollout remain pending. Existing passkeys remain tied to their enrollment hostname.
The Account Security guide explains session reuse, sensitive-action verification and return behavior. Password change, verified sign-in-email change and global sign-out are outside this version’s scope.