Server-to-Server Authentication
The api_secret auth method is designed for server-to-server integrations where your backend controls the authentication flow. Instead of relying on a third-party auth provider, your backend authenticates directly with the Privacy Boost API using a client_id and client_secret pair — similar to OAuth 2.0 client credentials.
This is the right choice when:
- Your backend already manages user authentication and you don’t use a third-party auth provider
- You need programmatic access (scripts, bots, automated systems)
- You want full control over who can authenticate without depending on an external JWKS endpoint
How It Works
Setup
1. Get API Credentials
Contact the Privacy Boost team to configure your app with the api_secret auth method. You’ll receive:
- App ID — Your application identifier (e.g.,
app_abc123xyz)
- Client ID — A unique identifier for your credentials (e.g.,
pb_cred_abc123xyz...)
- Client Secret — A secret key for authenticating requests
Store your client_secret securely. It should never be exposed in client-side code, committed to version control, or logged. Use environment variables or a secrets manager.
2. Store Credentials Securely
Client-Side Integration
If this runs in a browser, set keyVault.mode to local before passing a tokenProvider; the default browser iframe vault intentionally does not accept host-page token callbacks.
Implement a Token Provider
Your token provider routes the SDK’s login payload through your backend:
Backend Endpoint
Your backend endpoint receives the SDK’s login payload, adds your API credentials, and forwards to Privacy Boost:
Credential Management
Rotation
API credentials can be rotated without downtime:
- Request a new credential from the Privacy Boost team
- Update your backend to use the new
client_id and client_secret
- Revoke the old credential
Expiry
Credentials can optionally have an expiry date. If your credential expires, requests will fail with invalid_credentials. Request a new credential before the current one expires.
Security Best Practices
- Never expose credentials in client-side code. The
client_id and client_secret must only exist on your backend.
- Use environment variables or a secrets manager. Don’t hardcode credentials.
- Rotate credentials periodically. Treat them like passwords.
- Authenticate your own users first. Your backend endpoint should verify the caller’s identity (session token, JWT, etc.) before forwarding to Privacy Boost. Otherwise, anyone who discovers your endpoint can authenticate.
- Use HTTPS only. All communication between your backend and Privacy Boost must be over HTTPS.
Next Steps
Continue with setup:
Or explore other auth methods:
- Custom JWT — For Auth0, Firebase, Supabase, Clerk, or OIDC providers
- Privy — For Privy social login and embedded wallets