JABSC logoJABSC

Authentication

All three platforms use the same authentication system. Browser-based sessions use email and password. Programmatic access uses long-lived API keys.

Session Authentication

Browser sessions are managed automatically. After signing in, the session refreshes silently before expiry. If a refresh fails — due to a network error or revoked session — the user is redirected to login.

Sessions time out after one hour of inactivity by default. Administrators can adjust this per organization.

API Keys

For integrations, CI/CD pipelines, and programmatic access, use API keys. Keys are long-lived and scoped to specific operations.

Key Format

1sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   (production)
2sk_test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   (testing)

Pass the key in the Authorization header on every request:

1Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxxxxxxxxx

API Key Scopes

Keys are scoped to specific operations. Request only the scopes you need:

| Scope | Description | |-------|-------------| | read:applications | Read application data | | write:applications | Upload and modify applications | | read:reviews | Read AI review results | | write:reviews | Trigger reviews | | read:campaigns | Read campaign data (Axis) | | write:campaigns | Create and modify campaigns (Axis) | | read:leads | Read lead data (Axis) | | write:leads | Import and modify leads (Axis) | | read:contracts | Read contract data | | write:contracts | Deploy and execute contracts | | admin | Full access (use sparingly) |

Creating API Keys

Via the Admin Panel:

  1. Navigate to Admin → API Keys
  2. Click Generate New Key
  3. Select only the scopes your integration requires
  4. Set an expiry date (recommended for all integration keys)
  5. Copy the key immediately — it will not be shown again

Rotating Keys

Keys can be rotated without downtime:

  1. Create a new key with the same scopes
  2. Update your integrations to use the new key
  3. Revoke the old key

Revoked keys are rejected immediately.

Data Isolation

All database tables enforce Row Level Security (RLS) at the database layer — not in application code. Even if an API key or session token is compromised, the attacker can only access data belonging to that organization. This isolation cannot be bypassed by application bugs.

Every organization's data is completely isolated:

  • Org A cannot read Org B's applications, campaigns, leads, or contracts
  • Org A's API keys cannot access Org B's endpoints
  • Admin users are scoped to their own organization

Security Best Practices

For API Keys:

  • Store in environment variables, never in code or version control
  • Use minimum required scopes
  • Set expiry dates for all integration keys
  • Rotate keys on a regular schedule
  • Monitor key usage in Admin → API Keys → Usage

For Sessions:

  • HTTPS is enforced by the platform
  • Re-authentication is required for sensitive operations
  • Force logout terminates all active sessions immediately

For Webhooks:

  • Verify HMAC-SHA256 signatures on every incoming webhook before processing
  • Use HTTPS endpoints only
  • Process webhooks idempotently — the same event may be delivered more than once

Error Responses

| Status | Code | Description | |--------|------|-------------| | 401 | unauthorized | Missing or invalid API key | | 401 | token_expired | Session token expired | | 403 | forbidden | Valid auth but insufficient scope | | 403 | org_mismatch | Resource belongs to a different organization | | 429 | rate_limit_exceeded | Too many requests |