DeadArk Integration Security Checklist

How to use this checklist

These are the security requirements for a sound Sign in with DeadArk integration. Most map directly to doing the standard OAuth 2.1 flow correctly — the failures come from skipping steps, not from exotic attacks. Treat each item as a gate before you ship.

Authorization flow

• Use Authorization Code with PKCE. Always generate a fresh code_verifier/code_challenge per request and use code_challenge_method=S256. Never use the implicit flow.
• Verify `state`. Generate a random, per-request state, store it in the session, and reject any callback whose state does not match. This is your CSRF protection.
• Match redirect URIs exactly. Register precise redirect URIs and rely on exact matching. Do not use wildcards or build redirect targets from untrusted input.

Token handling

• Exchange the code server-side. The token exchange and any client secret must live on your server, never in the browser.
• Validate tokens. For OIDC ID tokens, validate the signature, issuer, audience, and expiry before trusting any claim.
• Store tokens securely. Keep tokens server-side, scoped to the session; never expose them to client-side code that does not need them.
• Handle expiry and revocation. Refresh appropriately and stop honoring sessions when tokens are revoked or the user signs out.

Scopes and data

• Request minimal scopes. Ask only for what your app needs. Over-scoping is a liability you gain nothing from.
• Store the portable profile ID as the user key. Key account records on the stable profile identifier; do not depend on mutable display data, and do not expect a private account UUID.
• Minimize what you persist. Store the identity link and what you genuinely need — not a copy of everything userinfo returns.

Operational hygiene

• Never log secrets or tokens. Keep code, code_verifier, access tokens, and any client secret out of logs and error reports.
• Protect your client credentials. Store any secret in a secret manager, rotate it if exposed, and keep it out of source control.
• Use HTTPS everywhere. Every redirect URI and endpoint your flow touches must be TLS-protected.
• Fail closed. On any verification failure — bad state, invalid token, mismatched redirect — reject the sign-in rather than degrading to a weaker path.

The short version

Do the standard flow correctly: PKCE, verified state, exact redirect URIs, server-side exchange, validated tokens, minimal scopes, and the portable profile ID as your user key — and never log secrets.