Skip to content

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.

Hosted access is private beta. Agree on the intended launch, service availability, support expectations, and commercial terms with Udibo. This checklist does not imply a production SLA or certification.

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 and the package's environment guide.

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 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 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

  • Verify email delivery and recovery with real test inboxes

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.

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

  • Verify webhook signatures 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 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 to isolate the boundary before changing configuration.

Last verified 2026-09-06.