Skip to main content
Work through this checklist before your app goes live. Each section is one rule for the Client Secret, OAuth tokens, webhook signatures, logging or user data, and names the Builder SDK helper that implements it if you use the SDK. It assumes your app already signs users in through OAuth. Fanvue secures the platform and the OAuth flow. You secure your app, your server, and the credentials and tokens you hold.

Protect your client secret

The Client Secret lets your app exchange authorisation codes for access tokens. Treat it like a password.
Keep the Client Secret on your server only. A secret in client-side code, a browser, a mobile binary or a public repository lets anyone obtain tokens as your app.
  • The secret is shown once, at creation. Store it in a secrets manager or an environment variable, never in source control.
  • If it leaks, click Reset secret on the Authentication tab. That issues a new secret and invalidates the old one at once, so deploy the new value in the same change. See Managing your OAuth client secret.

Use OAuth, don’t roll your own

Fanvue authenticates users through OAuth 2.0 with PKCE, a proof step that stops an intercepted authorisation code from being reused, so your app never sees a user’s Fanvue password. Don’t build your own login against Fanvue; use the flow in Authentication overview.

Request the least scope you need

Request only the scopes your features use; a read-only reporting app has no need for write:* scopes. Narrow scopes limit the damage if a token is compromised, and they shorten the consent screen. See Scopes.

Handle tokens carefully

  • Keep access tokens and refresh tokens server-side. Don’t expose them to the browser.
  • Access tokens are short-lived. Refresh them with the refresh token rather than sending the user back through login.
  • Refresh tokens are single-use and rotate on every refresh, so store the new one every time; see Refresh tokens rotate and are single-use.
  • Store tokens encrypted at rest, keyed to the user they belong to. The SDK’s createFanvueCrypto seals and opens token strings with a current key and optional previous keys, so you can rotate the encryption key without re-authorising users. See SDK storage and security.
  • Give the SDK session signer a SESSION_SECRET of at least 32 characters; it refuses a shorter one.

Verify every webhook

Verify X-Fanvue-Signature on every delivery before you act on it; without the check, anyone who finds your webhook endpoint can send you fabricated events. In the SDK, verifyWebhookHmac with fanvueSignatureContract() does the check, and Verify webhook signatures explains the scheme.

Handle user data responsibly

  • Read and store only the data your scopes and your feature need.
  • Never log tokens, secrets or personal data. The SDK’s createSafeLogFields keeps only allowlisted log keys, and createSentryScrubber redacts values under keys that match authorization, cookie, token, secret, password, email, phone and similar names before an error report leaves your process.
  • Show users a generic error message and log the detail server-side.
  • Serve your app over HTTPS so tokens and data are encrypted in transit.