Security checklist

#Before going live

• client_secret lives only on your server, never in browser JavaScript or a mobile app.
• code_verifier and state are generated per flow from a CSPRNG and stored server-side, keyed by state.
• The callback consumes state once, compares it and iss in constant time, and rejects a second POST with the same state.
• The callback branches on error before it reads code.
• The exchange runs server-to-server, form-encoded, with a timeout, and never retries an invalid_grant.
• Your redirect URI is fixed and registered; you never take a redirect target, issuer or token endpoint from a request.
• privateKey is treated like the client secret: no logs, no URLs, no analytics, no third parties; encrypted at rest or memory-only.
• 401 from the API drops the bundle and offers to reconnect; nothing retries it.
• Your own pages set frame-ancestors 'none'; nothing on your side needs to allow open-banking.io in form-action — the relay is a form the consent page submits, governed by our policy, not yours.
• Your session cookie is not what the callback relies on (see callback).
• You request no more than accounts.read — it is the only scope, and being read-only is worth telling your users.
• Keys you no longer need are revoked with POST /oauth/revoke.

#Going live

• Create a separate production client on https://open-banking.io; staging clients, secrets and keys do not exist there.
• Switch ISSUER and re-run discovery; register your production redirect URIs on the production client.
• Pin your registered domain on your partner page: your redirect URL and the support and terms links must live under it.
• Confirm your Enable Banking application shows active on the partner page before the first user connects.
• Wire POST /oauth/revoke into your disconnect, and rotate the staging secret out of any shared config.