# Get ready for production

A successful local login is the starting point. Before inviting real users,
verify the deployed application can preserve sessions, refuse unauthorized
requests, and recover when a credential expires or a dependency fails.

**This checklist does not imply a production SLA or certification.** Agree on
the intended launch, service availability, support expectations, and commercial
terms with Udibo before you go live.

## Separate the environments

- [ ] Create a production application registration with an exact HTTPS callback
- [ ] Keep development and production client secrets separate
- [ ] Decide whether test users and policy need their own tenant
- [ ] Set the issuer, callback, audience, and application origin from trusted
      deployment configuration
- [ ] Test through your real domain, TLS termination, and reverse proxy

See
[application configuration](https://www.udibo.com/docs/identity/applications)
and the package's
[environment guide](https://www.udibo.com/docs/oauth2/guides/deploy-across-environments).

## Make sessions durable

- [ ] Replace every in-memory user, session, token, and application-data store
      that your chosen integration uses
- [ ] Share pending-login encryption keys and session storage across instances
- [ ] Keep application cookies HttpOnly, secure in production, and appropriately
      scoped; retain the BFF's CSRF protection
- [ ] Test callback requests landing on a different instance from the login
      request
- [ ] Prove a revoked or expired session cannot be recreated by an in-flight
      refresh
- [ ] Define what signing out means for both the app session and tenant session

Run the package's persistent-store contract tests against your implementation. A
stateless encrypted cookie has different revocation properties from a stored
session; do not promise immediate revocation of a copied cookie without a
mechanism that enforces it. The
[deployment guide](https://www.udibo.com/docs/oauth2/guides/production-deployment)
covers the app-owned pieces in detail.

## Test authorization with the wrong user

- [ ] Reject invalid, expired, wrong-issuer, and wrong-audience credentials
- [ ] Refuse a signed-in user who lacks the required scope or permission
- [ ] Refuse access to another user's record and another organization's data
- [ ] Resolve resource ownership from trusted application records
- [ ] Test a role being granted and revoked while the user remains signed in
- [ ] Account for JWT expiry and any introspection caching in freshness promises
- [ ] Keep dashboard administrator credentials out of application request paths

Use [permissions and roles](https://www.udibo.com/docs/identity/permissions) for
organization and resource checks. Some management operations require
administrator credentials and are not available to a machine application in your
tenant. Confirm the supported provisioning path before automating invitations,
assignments, or resource grants.

## Exercise the account lifecycle

- [ ] Configure sign-up mode deliberately: open, waitlisted, or closed
- [ ] Check the user-facing sign-in, sign-up, recovery, and verification paths
- [ ] Test each enabled social provider with its production callback
- [ ] Test MFA enrollment and recovery under the intended tenant policy
- [ ] Check branding and the support destination on the hosted pages
- [ ] List the
      [cookies the hosted pages set](https://www.udibo.com/docs/identity/cookies)
      in your privacy or cookie notice
- [ ] Verify email delivery and recovery with real test inboxes
- [ ] Review both senders' monthly and daily
      [email hard limits](https://www.udibo.com/docs/identity/usage-limits) and
      confirm an alert recipient before email-dependent sign-in goes live

The managed service owns its hosted pages. If you chose to run authentication
yourself, you also own credential storage, email delivery, rate limiting,
lockout, and the MFA lifecycle. Use the package's
[hardening checklist](https://www.udibo.com/docs/oauth2/guides/hardening-checklist).

Email hard limits also stop codes, magic links, and password resets. Check the
effective values on your tenant's **Billing** page; the public pricing
calculator estimates costs and does not set those limits.

## Prepare operations and rollback

- [ ] Monitor authentication failures and recovery requests without logging
      passwords, codes, tokens, or complete callback query strings
- [ ] Record enough context to correlate an application failure with the
      tenant's [audit log](https://www.udibo.com/docs/identity/audit-log)
- [ ] Verify [webhook signatures](https://www.udibo.com/docs/identity/webhooks)
      against the raw request body, deduplicate deliveries, and store work
      before acknowledging it
- [ ] Test secret rotation and the application's response to a temporary issuer
      or storage outage
- [ ] Back up the application-owned data and rehearse restoring it
- [ ] For migrations, rehearse the
      [rollback plan](https://www.udibo.com/docs/identity/migrate) with accounts
      created or changed after cutover

**Ready for the first cohort:** sign-in, renewal, sign-out, recovery, and
cross-user refusals all behave as promised in the deployed environment. If
something fails, use the
[troubleshooting guide](https://www.udibo.com/docs/identity/troubleshooting) to
isolate the boundary before changing configuration.

_Last verified 2026-10-02._