Security checklist

• The API key lives only in your backend's secret store: never in a browser bundle, a mobile app or a repository.
• Every access token is verified on every request: algorithm, key, audience, issuer and expiry.
• Refresh tokens are kept server-side or in HttpOnly cookies, and replaced on every refresh.
• Only your exact callback URLs are registered, all https:// in production.
• Connection tokens are exchanged from your backend, once, straight away; your callback page doesn't log or forward its URL.
• Services that only check tokens verify them with your app's public keys (RS256), never hold an API key, pin the algorithm and check aud.
• You have a rotation plan: generate a new key, deploy it to the servers that call Identise, revoke the old one.
• Tokens, codes and API keys are kept out of your logs.
• You check password strength in your own sign-up form; Identise only requires 8 to 256 characters.
• You forward X-Client-Ip and User-Agent so users can recognise their sessions.

Found a security problem in Identise itself? Tell the Identise team privately rather than opening a public issue.