Going live

An integration that works on your laptop has not yet met the things that go wrong in production: a refused request, a rate limit, a clock that has drifted, a refresh token that is reused, a person who says no. This section is the preparation for those. It has one checklist and three pages on the failures that a checklist cannot explain in a line.

It is for developers about to send real traffic through identity, and for whoever reviews that integration. It is worth reading again whenever your registration or deployment changes.

Three kinds of thing can go wrong. A request can be refused because it is wrong, and the answer names an OAuth error you must handle. A request can be limited because it was sent too fast, and the answer is a 429 that asks you to wait. A request can fail because of time, because short lifetimes are comparisons against a clock and your clock is off. A good integration treats the three differently: fix the first, wait for the second, synchronise for the third.

refused   -> read the error, do not retry unchanged   (error handling)limited   -> wait for Retry-After, add jitter, cap    (rate limits and retries)too early / too late -> synchronise the clock          (clock skew)all of it -> tick the list once before launch           (checklist)

I am launching tomorrow.

1. Going-live checklist: work through it once, from registration to your API.
2. Clock skew: confirm your servers synchronise time.
3. Error handling: decide what each failure shows the person.

We started getting 429 responses.

1. Rate limits and retries: what a refusal looks like and what to do.
2. 429 Too Many Requests: the symptom page.

Good requests are being refused and I cannot see why.

1. Clock skew: the checks that use your clock.
2. invalid_dpop_proof and use_dpop_nonce: proof refusals.
3. invalid_grant: code and refresh failures.

Going-live checklist groups items under registration, keys and secrets, environment, the sign-in flow, tokens and sessions, your API, and behaviour when things fail. Each item says why it matters and where to read more. An item you cannot tick is a decision to make on purpose. It ends with a last question to ask yourself.

Error handling says where errors arrive (the redirect back, a JSON body from the endpoints, the userinfo challenge header), what each OAuth error means and what to do, how the SDK reports them, what to show the person, what to log, and when to retry.

Rate limits and retries says that a refusal is a 429 with a Retry-After header, that no limit numbers are published, what a well-behaved client does and which requests are safe to repeat. It notes that the SDK never retries a 429 or a server error. Its one retry is the DPoP nonce challenge.

Clock skew lists the checks that depend on your server's clock and how much each forgives (for example a DPoP proof is accepted 60 seconds either way), the symptoms, how to measure the difference and the fix, which is to run time synchronisation on every server.

A working sign-in, from the Quickstart, and a registered client. If you protect an API, finish Protect your API too.

What should I do on a 429? Wait for Retry-After, add jitter and cap retries. See Rate limits and retries.

Where do I find the limit numbers? They are not published. See Rate limits and retries.

What if my refresh fails with invalid_grant? Sign the person out of your application and start a new sign-in. See Going-live checklist.

Does the SDK retry for me? Only for the DPoP nonce challenge. See Rate limits and retries.

How wrong can my clock be? It depends on the check. See Clock skew.

It does not explain each OAuth flow, which is in Flows, or the exact answer of each endpoint, which is in Endpoints. The full list of error codes is in the Reference, and the symptom-first pages are in Troubleshooting.