Authentication
Two auth contexts
| Context | Users | Method |
|---|---|---|
| Staff (ops.ikamet.com) | Ikamet team members | JWT + HTTP-only cookie |
| Customer (app.ikamet.com) | Customers | JWT + HTTP-only cookie |
Staff authentication
Staff log into ops.ikamet.com using their Ikamet staff credentials. Authentication is handled by the /crm/auth/ endpoints.
Token storage
Tokens are stored as HTTP-only cookies — they cannot be accessed by JavaScript. The getAuthHeaders() function in app-admin reads the cookie and adds the Authorization: Bearer <token> header to all API requests.
Session lifetime
Staff sessions expire after inactivity. The frontend detects a 401 response and redirects to the login page.
Staff roles
Staff members have roles that determine their access level:
| Role | Access |
|---|---|
ADMIN | Full access |
AGENT | Customer workspace, tasks, communications |
SUPPORT | Read-only customer data |
Customer authentication
Customers authenticate via app.ikamet.com. Customer auth is separate from staff auth — a staff member cannot use a customer token to access ops endpoints, and vice versa.
API key auth (server-to-server)
Internal server-to-server calls (e.g., cron jobs calling /ops/renewals/refresh) use API key authentication via the X-API-Key header. API keys are stored in environment variables.
Security rules
- Never expose JWT secrets in source code or logs
- Always use HTTPS — Cloudflare enforces this
- HTTP-only cookies prevent XSS token theft
- All auth decisions are server-side — client-side “is logged in” checks are UI-only, not security boundaries
- Failed auth attempts are logged and rate-limited by Cloudflare WAF