Going to production

Most launch problems are configuration: the wrong App ID, a return URL that still says localhost, a permission nobody registered. Work through this list before you announce your app. Each item links to the page that explains it.

The checklist

Environment and registration

• The app exists on the production server. Apps are per server: the test server's App ID does not work in production. Register the app in the console and use its App ID. See Testing and debugging.
• issuer is production, or left at the default. The default is https://api.unet.ovh/oidc. Remove any issuer that points at the test server.
• The production return URL is registered. It must equal redirectUri exactly: scheme, host, port, path, trailing slash. Add the production address in the console; remove localhost addresses you no longer need.
• The app has a name people recognise. It is shown on the permission screen.
• Website apps: the domain is verified. An app whose domain is not verified is marked as unverified on the permission screen.

Page and transport

• The whole site is served over HTTPS, and http redirects to it.
• A content security policy is in place and allows connect-src https://api.unet.ovh. See Security checklist.
• Storage is the one you meant. session is the default; local only with a strict policy. See Sessions and storage.
• The SDK version is pinned in your lockfile and noted in your release notes.

Permissions

• Scopes are the minimum. Every permission in scopes is used by a feature that exists. Registered permissions match scopes: a new app is held to what it registered. See Permissions.
• offline_access is requested only if the person should stay signed in beyond an hour.
• A missing permission is handled (InsufficientScope): the feature is hidden or asks for the permission.

Your server

• Tokens are verified on the server with verifyAccessToken or verifyIdToken, never trusted from the browser. See Verify on your server.
• Users are keyed by sub.
• The App Secret is only on the server, in your secret store, not in the repository.
• A thrown verification error answers 503, not 200 or 401 (it means "unknown").

Behaviour at the edges

• SessionExpired is handled as signed out, not logged as an error. People remove apps; sessions end. See Error handling.
• RateLimited is handled: no retry loops, a message to the person.
• AccessDenied is handled: someone who pressed Deny lands somewhere sensible.
• A refresh that fails because of the network does not sign people out. The SDK keeps the tokens; make sure your UI does not treat NetworkError as signed out.
• Text from UNET is escaped, and links built from it check the scheme. See Security checklist.

People and privacy

• Your privacy text says what you keep: the person's sub, username and display name, and anything else you store. UNET gives you no email address.
• You can delete a person's data when they ask, and when they remove your app.
• People know how to remove your app. They do it in their UNET settings under Connected apps. Removing it revokes your tokens at once.

Operations

• You can see problems. Count the rate of SessionExpired, RateLimited and ApiError by status, and the time sign-in takes. Do not log tokens or whole requests. If you use onTrace in production, record only sdk, status and ms.
• You know the limits that apply to your app and what happens when you reach them. See Call the UNET API.
• You know how to turn the app off and rotate the secret if you must. See Security checklist.

What changes between test and production

Keep the two App IDs in configuration and select by environment, so the same build cannot sign in against the wrong server.

After launch

• Watch the changelog. The SDK is 0.x. Read the changelog and the versioning policy before you upgrade, and upgrade in a branch with your tests.
• Add permissions deliberately. When a feature needs a new one, register it, request it with prompt: "consent", and expect that some people say no.

What next