Steadybase
Security & Trust

Authentication

JWT authentication, invite codes, and planned SSO/MFA implementations.

Authentication

Steadybase uses JWT-based authentication with invite codes for user onboarding. This page covers the current implementation and planned enhancements.

Current Implementation

Invite Code Authentication

New users authenticate using invite codes — randomized, role-specific codes:

RoleFormatAccess Level
AdminSB-ADMIN-XXXXXXXXFull read/write access to all endpoints
ViewerSB-VIEW-XXXXXXXXRead-only access to dashboards and data

Invite codes are:

  • Randomized (no default or guessable codes)
  • Role-scoped (each code maps to a specific role)
  • Server-side validated

JWT Tokens

After successful invite code validation, the server issues a JWT token:

  • Expiration: 24 hours
  • Storage: httpOnly cookie (primary), localStorage (fallback)
  • Validation: Checked on every /api/* request via auth middleware
POST /auth/login
{ "inviteCode": "SB-ADMIN-XXXXXXXX" }

→ 200 OK
Set-Cookie: token=eyJ...; HttpOnly; Secure; SameSite=Strict
{ "token": "eyJ...", "role": "admin" }

Auth Middleware

All API routes pass through auth middleware that:

  1. Extracts the JWT from the cookie or Authorization header
  2. Validates the signature and expiration
  3. Attaches the user context to the request
  4. Enforces role-based access for protected operations

WebSocket Authentication

WebSocket connections require a valid JWT:

const ws = new WebSocket('wss://app.steadybase.io/ws', {
  headers: { 'Authorization': `Bearer ${token}` }
});

Unauthenticated WebSocket connections are rejected.

Known Limitations

:::warning These limitations are documented transparently and are being addressed. :::

LimitationRiskMitigation Plan
localStorage fallbackXSS can steal tokensRemove fallback, use httpOnly cookies exclusively
No CSRF protectionCross-site request forgeryAdd CSRF token validation
No MFASingle factor onlyPlanned in Phase 3 (TOTP/WebAuthn)
No SSONo enterprise identity provider integrationPlanned in Phase 3 (SAML/OIDC)
No session revocationCan't invalidate active tokensAdd token blacklist or short-lived tokens + refresh

Planned Enhancements

Phase 2: Hardened Auth

  • Remove localStorage token storage
  • Implement CSRF protection
  • Add token refresh mechanism
  • Implement session revocation

Phase 3: Enterprise Auth

  • SSO — SAML 2.0 and OIDC support for enterprise identity providers
  • MFA — TOTP (Google Authenticator) and WebAuthn (hardware keys)
  • EdDSA Signing — Upgrade JWT signing from HMAC to EdDSA (Ed25519)
  • AWS Cognito — Full integration with AWS Cognito for user management

Rate Limiting

Auth endpoints have stricter rate limits than general API endpoints:

Endpoint TypeLimitWindow
Auth (/auth/*)10 requests15 minutes
General (/api/*)300 requests15 minutes

This prevents brute-force attacks on invite codes and login endpoints.

On this page