Move an integration to Production
A working local callback proves the initial protocol wiring. Prepare the following before your product sends real customers through the integration.
Register the Production integration
Section titled “Register the Production integration”Select Production in the dashboard and create or select its application and client. Copy its exact issuer, client ID and secret into separate Production configuration. Register the deployed HTTPS callback and, if needed, a signed-out destination. Review the selected environment’s authentication methods, admission rules, saved branding and API grants.
Sandbox and Production have separate identity stores, clients, credentials and users. Changing a callback or an environment label does not migrate them. Oathvera operates the dedicated identity storage and routing; a new customer does not provision D1s or deploy Oathvera Workers. Configure your own backend’s persistence and secrets using your deployment platform.
Start with the generated authentication hostname. A custom domain is optional and should be accepted with its complete issuer before use. Changing an existing issuer or client requires an identity/session migration plan; see branding and domains.
Verify the consumer application
Section titled “Verify the consumer application”| Area | Required outcome |
|---|---|
| Entry and callback | No-session navigation opens hosted login directly; exact state/issuer/nonce/audience/PKCE checks reject substitutions and replay. |
| Identity | Unique (iss, sub) mapping; verified-email requirements enforced; duplicate first-login requests do not create multiple owners. |
| Secrets | Present in the deployed server’s allowed secret bindings, absent from frontend bundles and logs; expiry/rotation owner assigned. |
| Session store | Shared, bounded, expiring storage; encrypted server tokens; Secure/HttpOnly cookies; atomic refresh and transaction consumption. |
| Current authority | Revoked, expired, suspended or unavailable authority cannot load protected data. Online session results are not cached as an allow decision. |
| Authorization | Correct user admission, client grants, user roles, API resource and record ownership; wrong tenant/client/organization denies. |
| Lifecycle | Registration, required verification/MFA, returning sign-in, refresh, own-session logout, administrative revocation and recovery exercised as applicable. |
| Failure handling | Provider timeout, malformed responses, missing configuration and cancelled login produce actionable errors without redirect/retry loops. |
| Browser delivery | Fresh browser and installed/offline shell follow the same routing; no protected/auth response served from an offline cache. |
| Operations | Safe stage timings, error codes and correlation references; deployment version and rollback owner recorded. |
On Workers, check that configured secret names are actually included in any deployment secret allowlist; saving a secret alone does not prove your deployed handler receives it. Bound both outbound duration and response-body size. Use explicit redirect refusal for credentialed back-channel requests: handle a manual redirect response as failure and never forward Basic or Bearer credentials to its destination. See Cloudflare’s Fetch documentation.
Review performance guidance before adding retries or raising timeouts. Retry discovery within bounds; an ambiguous code redemption or rotating refresh must not be retried blindly.
Existing accounts require a separate decision
Section titled “Existing accounts require a separate decision”Inventory the old identities, sessions, owners, invitations and integrations. Choose an explicit migration strategy with ownership proof, or leave old accounts inactive. Do not automatically link them using email, keep temporary founder bypasses, or restore retired login endpoints during rollback.
Preserve stable Oathvera identifiers and issuers during ordinary application updates. Stage a cutover with a recoverable application release and clear failure triggers. A code rollback must not resurrect revoked sessions or undo identity ownership decisions.
Record acceptance
Section titled “Record acceptance”Record environment, application release, client type, browser/platform, date, result and sanitized evidence for each applicable case. Mark scenarios not exercised as NOT RUN. A successful password login does not establish social-provider, enterprise, refresh, global-logout or recovery acceptance.
Record the results using the integration checklist and follow your product’s release process before routing customer traffic.