Secrets & access tokens
Beyond your warehouse and Git credentials, a Zingle deployment relies on a small set of platform secrets.
Platform secrets
| Secret | Purpose |
|---|---|
| Encryption key | Fernet key used to encrypt credentials and tokens at rest. Shared by the services that need to decrypt them. |
| JWT signing keys | An RSA key pair (RS256) used to sign and verify session tokens. |
| OAuth state secret | Protects the Git OAuth handshake against CSRF. |
| Metadata store password | Credential for the platform's own database. |
| Email provider key | Used to send login (one-time code) emails. |
| LLM provider credentials | AWS (for Bedrock) or a model-provider API key. |
How secrets are provided
Secrets are supplied to the services through environment configuration at deploy time. In a Customer VPC deployment, all secrets live inside your environment.
Session tokens
- Signing in issues a session token (a signed JWT) that the web app presents on each request.
- Tokens carry the user's organization and role and are validated on every protected request.
- Tokens have a limited lifetime and can be invalidated by signing out.
Protecting secrets
- Credentials and tokens are encrypted at rest.
- Secrets are not written to application logs.
- The encryption key must be kept safe and consistent across the services that share it; rotating it requires re-encrypting stored credentials.