Dual-Key Authentication
Smooven uses a Dual-Key authentication paradigm that separates public client-side identity from private server-side operations. This design ensures that even if your frontend code is inspected, your notification infrastructure remains secure.
How it works
Section titled “How it works”Every Smooven project is assigned two keys:
| Key | Purpose | Where to use |
|---|---|---|
App ID (app_live_...) | Identifies your project. Used for player registration and SDK initialisation. | Client-side code, mobile apps, web frontends |
Secret Key (sk_live_...) | Authenticates privileged operations. Used for sending notifications and managing data. | Server-side only. Never expose in client code. |
Why two keys?
Section titled “Why two keys?”The problem with single-key models
Section titled “The problem with single-key models”Many notification platforms use a single API key for everything. This forces a choice: embed the key in your frontend (insecure) or proxy every request through your backend (complex).
The Smooven approach
Section titled “The Smooven approach”With Dual-Key auth, your frontend SDK can register devices and identify users using the public App ID. The Secret Key never leaves your server. Notification sending, player data access, and template management all require the Secret Key.
This means:
- Frontend registration is safe. The App ID can only register players, not send messages.
- Server-side operations are protected. The Secret Key controls all privileged actions.
- Compromise is contained. If the App ID is exposed, an attacker can register fake players but cannot send notifications or access data.
Quantum-resistant key derivation
Section titled “Quantum-resistant key derivation”Both keys are derived using quantum-resistant key derivation functions (KDFs). Even if one key is compromised, it is computationally infeasible to derive the other. See Quantum-Safe Encryption for technical details.
Key rotation
Section titled “Key rotation”Rotate your Secret Key at any time from the Smooven dashboard. The previous key remains valid for 24 hours, giving you time to update your servers. App IDs are permanent and cannot be rotated.
Best practices
Section titled “Best practices”- Store the Secret Key in environment variables, not in source code.
- Use separate projects for development, staging, and production.
- Monitor API usage in the dashboard for unusual patterns.
- Rotate keys immediately if you suspect a compromise.