docs: recommend bounded retry/backoff for token exchange failures

Update integration guidance to avoid tight retry loops during transient token endpoint failures by using bounded backoff strategies.
This commit is contained in:
Andy Dixon
2026-02-26 11:48:40 +00:00
parent 60f6989595
commit 7bb919a0a0
+1
View File
@@ -140,6 +140,7 @@ try {
- Avoid printing tokens in production pages. - Avoid printing tokens in production pages.
- Expect `429 Too Many Requests` from provider control endpoints under abuse protection; implement backoff/retry instead of tight loops. - Expect `429 Too Many Requests` from provider control endpoints under abuse protection; implement backoff/retry instead of tight loops.
- Apply the same backoff strategy for provider `userinfo` calls that return `429 Too Many Requests`. - Apply the same backoff strategy for provider `userinfo` calls that return `429 Too Many Requests`.
- For token exchange and refresh, apply bounded retry/backoff on transient provider failures instead of immediate repeated retries.
- If you call provider WebAuthn login challenge/verify endpoints directly, use `POST` only. - If you call provider WebAuthn login challenge/verify endpoints directly, use `POST` only.
- Configure OAuth client redirect URIs as HTTPS in production; reserve HTTP for localhost loopback testing only. - Configure OAuth client redirect URIs as HTTPS in production; reserve HTTP for localhost loopback testing only.
- Rotate client secrets for confidential clients. - Rotate client secrets for confidential clients.