Understand the integration
Oathvera hosts sign-in and verifies your users. Your application receives a verified identity, creates its own session, and decides what that person can do in your product.
The shortest useful path
Section titled “The shortest useful path”Your app → Oathvera sign-in → your callback → your dashboard.
- A user opens your application. Your backend starts a sign-in transaction.
- Oathvera shows the methods your workspace and application allow, including any required verification.
- Oathvera returns a short-lived code to your registered callback.
- Your backend validates the response, exchanges the code, and establishes an application session.
- Your product uses that session and current Oathvera authority to protect access.
Start with a real Sandbox login. Add API permissions, providers and custom domains when you need them.
Who handles what?
Section titled “Who handles what?”| Oathvera handles | Your application handles today |
|---|---|
| Hosted credential entry, authentication policy and MFA | Login/callback/logout routes and secure session middleware |
| Identity, factors and hosted recovery | Mapping (issuer, subject) to your product’s user |
| Token issuance, rotating refresh and revocation authority | Protected token storage, refresh coordination and live session checks |
| Hosted Account Security in enabled environments | Its launch button, backend handoff and pending storage |
| Authentication infrastructure and hosted domains | Product accounts, organizations, billing and record-level access |
You do not need Oathvera’s database credentials or hosting account. The infrastructure you configure belongs to your application.
Choose the right client
Section titled “Choose the right client”| Your architecture | Start here |
|---|---|
| A web app with a backend that can keep a secret | Server web application |
| Cloudflare Workers backend | First login, then Workers integration notes |
| Browser-only or native application | Public-client sign-in |
| A backend service calling an API without a person | Machine-to-machine |
An application can have more than one client. Use the client ID from the selected integration, not the application ID.
What is ready to copy?
Section titled “What is ready to copy?”The Node.js reference bundle can complete a local login and logout. Its storage is in memory, and it does not implement production refresh or ongoing session checks. The Account Security helper connects to your existing authentication and storage code.
There is currently no published Oathvera production SDK or setup CLI. The production integration guide explains the additional implementation required. Completing a demo does not complete that work.
Three identities to keep separate
Section titled “Three identities to keep separate”- Workspace administrator: configures Oathvera in the dashboard.
- Application user: signs into your product through hosted login.
- Product account or membership: created or linked by your application’s own rules.
An administrator does not automatically become an application user. A successful login does not automatically create a paid account or organization membership in your product.
Sandbox first, then Production
Section titled “Sandbox first, then Production”Each environment has its own users, applications, credentials and issuer. Use a real Sandbox user for the walkthrough. Production setup is a separate registration and verification step; it does not copy Sandbox users.