Security
Ringnity has several credentials because each one protects a different boundary. The safest integration keeps public bootstrap values in client code, secret keys in backend code, and OAuth/OIDC tokens only for identity login flows.
Credential boundaries
| Credential | Used for | Lives in | Rule |
|---|---|---|---|
| Public slug / install key | Browser and website bootstrap | Public website code | Public identifier only. |
| Runtime token | SDK runtime for chat, calls, AI, and reports | Browser or mobile app | Short-lived and scoped. |
| Server API key | Backend token exchange, contacts, reports, webhooks | Customer backend only | Secret and never shown to frontend/mobile. |
| Owner session | First-party Ringnity dashboard access | HttpOnly browser cookie | Issued only after primary login and any required MFA challenge. |
| OAuth/OIDC token | Login with Ringnity identity and SSO | External app backend or trusted OIDC plugin | Proves user identity, not SDK runtime access. |
Owner login and TOTP MFA
Password and Google are primary owner sign-in methods. When TOTP is enabled, primary authentication creates a short-lived HttpOnly challenge instead of an owner session. The owner session is issued only after a valid authenticator or one-time recovery code is submitted. TOTP setup secrets and recovery codes must never be logged or stored in browser storage.
An owner may start from Ringnity or enter the owner email on the workspace login page. Both surfaces authenticate the same owner account, require TOTP when enabled, and exchange the owner session for a single-use workspace entry token. The staff login endpoint remains reserved for admin, supervisor, and agent usernames; Ringnity never stores a second owner password on the agent record.
Backend token guide
Create short-lived runtime tokens from a customer backend without exposing Server API keys.
Login with Ringnity
Use OAuth2/OIDC when an external app needs Ringnity identity login or SSO.