Go Live¶
Use this page before real users depend on your SigID workspace.
Going live means the business settings, support process, and developer integration are ready together. Do not treat sign-in as ready until users can start in the real app, complete SigID sign-in, and return to the app.
Production Checklist¶
Verify each row: Billing (owner, plan, invoicing path confirmed), Support (users know where to get help for login, recovery, and account questions), Domains (production domains, redirect URLs, and allowed origins registered exactly), Branding (name, logo, consent prompts users recognize), Login methods (every enabled choice tested), Secrets (client and webhook secrets outside browser code), Tokens (backend validation checks issuer, audience, tenant, expiry, scopes, and subject type), Webhooks (signature verification and safe retries, if used), SSO (enterprise login and fallback tested, if used), Audit (operators can review important events), Recovery (expectations documented).
Billing confirmation requires the human billing owner - flag it for them rather than checking it yourself.
Report any unverified row as a launch blocker.
| Area | Check |
|---|---|
| Billing | Billing owner, plan, and invoicing path are confirmed. |
| Support | Users know where to get help for login, recovery, and account questions. |
| Domains | Production domains, redirect URLs, and allowed origins are registered exactly. |
| Branding | App name, logo, and consent prompts match what users recognize. |
| Login methods | Passkeys, passwords, magic links, MFA, and SSO choices are tested. |
| Secrets | Client secrets and webhook secrets are stored outside browser code. |
| Tokens | Developers confirm backend token validation checks issuer, audience, tenant, expiry, scopes, and subject type. |
| Webhooks | Receivers verify signatures and handle retries safely, if events are used. |
| SSO | Enterprise login and fallback process are tested, if SSO is used. |
| Audit | Operators can review important identity and access events. |
| Recovery | Account recovery expectations are documented. |
Launch Sign-Off¶
Run one complete test as each audience: an individual starts from the app, signs in with SigID, and returns to the app; a business operator updates a user, app, or organization setting; a developer verifies the backend rejects an invalid token; an SSO user completes SSO, if applicable; support explains what to do when login or recovery fails.
Every applicable test must pass - a single failure blocks sign-off.
Final sign-off is the launch owner's decision; present them the results.
Before launch, run one complete test as each audience:
- an individual starts from the app, signs in with SigID, and returns to the app
- a business operator updates a user, app, or organization setting
- a developer verifies the backend rejects an invalid token
- an SSO user completes SSO, if applicable
- support can explain what to do when login or recovery fails
Rollback Plan¶
Draft a rollback plan covering each listed area: sign-in method changes, redirect URL mistakes, SSO misconfiguration, app branding mistakes, bad scopes or consent prompts, webhook receiver failures, and backend token validation errors.
Include the user message: if launch fails, users return to the original app or support channel instead of trying random SigID links.
Have the launch owner review and approve the plan before go-live.
Keep a rollback plan for:
- sign-in method changes
- redirect URL mistakes
- SSO misconfiguration
- app branding mistakes
- bad scopes or consent prompts
- webhook receiver failures
- backend token validation errors
If launch fails, tell users to return to the original app or support channel instead of trying random SigID links.