Auth & RBAC

One Access Model. Every Endpoint.

One auth layer across every endpoint. JWT-based identity, org-scoped multi-tenancy, and hierarchical RBAC.

Authentication Flows

Two authentication paths, one token format. Users and robots both receive JWTs scoped to an organization.

User Login

Username + Password
Basic Auth header
POST /auth/login
+ X-Org-Id header
JWT Token
sub, org, user_uuid, org_uuid, exp

Robot Login

Username + API Key
eden_<64-hex-chars>
POST /auth/robots/login
+ X-Org-Id header
JWT Token
subject_type: "robot", org_uuid, exp
Both token types refresh via POST /auth/refresh with Bearer token

Two Identity Types

Human users and machine accounts. Different credentials, same RBAC model.

Users

Human operators with username/password credentials. Full access level range from SuperAdmin to Read.

  • SHA-256 hashed passwords with per-user salt
  • All five access levels (SuperAdmin → Read)
  • Self-service password updates
  • Admin-managed lifecycle (create, update, delete)
  • Only SuperAdmin can create other admins

Robots (Service Accounts)

Machine identities for agent systems, CI/CD pipelines, and inter-service communication.

  • API key format: eden_<64-hex-chars>
  • SHA-256(salt || key) — plaintext never stored
  • Limited to Read or Write access only
  • Key rotation via dedicated endpoint
  • Admin+ required to create and manage

Access Level Hierarchy

Five hierarchical levels. Each level inherits all permissions of the levels below it. Permission check: current_level <= required_level.

0
SuperAdmin

Full control — delete resources, manage all permissions, create admins

1
Admin

Manage permissions, grant/revoke access, add/remove writers and readers

2
Write

Modify resource settings and data, execute write operations

3
Read

View resources, execute read operations, connect to endpoints

4
None

No access — default for all subjects until explicitly granted

RBAC Model

Every permission is a triple: Subject has AccessLevel to Entity. Two-tier verification with organization-level and resource-level checks.

Subject
User or Robot
AccessLevel
0–4 hierarchy
Entity
Org, Endpoint, ...

Two-Tier Permission Verification

Incoming Request (Bearer JWT)
1. Organization Access
Check org-level permissions
pass → allow | fail ↓
2. Endpoint Access
Check resource-level permissions
pass → allow | fail → 401

Entity Types

Organizations

Top-level tenant boundary. Controls who can access the org and its resources.

Endpoints

Individual database, LLM, or API connections. Fine-grained access per resource.

Templates

Reusable endpoint configurations. Control who can instantiate or modify templates.

Workflows

Multi-step automation pipelines. Scoped access for orchestration.

Organization Multi-Tenancy

Complete isolation between organizations. Every request is scoped. Every query is bounded.

Org Alpha
Org Beta
Org Gamma
Complete Isolation

Users in Org A cannot see or access Org B resources. All database queries scoped by org UUID.

RBAC-Gated Authentication

Users and robots must have an active RBAC entry for the org. Deleted users cannot re-authenticate.

Header-Based Context

Every request requires X-Org-Id or X-Org-Uuid header. Organization context embedded in JWT claims.

Org-Scoped Credentials

Usernames are unique per organization. The same username can exist in multiple orgs as separate identities.

Unified Across Every Endpoint Type

One verify_rbac check for everything. No per-endpoint-type auth logic. Databases, LLMs, APIs, and functions share the same identity model.

verify_rbac
JWT · Organization · AccessLevel · Entity
Databases
PostgreSQL, MySQL, Redis, MongoDB, ...
LLMs
OpenAI, Anthropic, Ollama, OpenRouter
APIs
REST endpoints, webhooks
Functions
MCP tools, serverless

MCP Agent Authentication

MCP agents inherit the calling user's identity. No separate credentials, no elevated privileges. Agents operate exactly as the user who invoked them.

User Request
Bearer JWT with org + identity claims
Eve Gateway
Validates JWT, extracts user context
MCP Agent
Receives forwarded JWT + org context
Backend Endpoint
Authorization + X-Org-Id headers forwarded
JWT Forwarding

The user's JWT is extracted from the request and passed through to every MCP tool call and relay operation.

Same RBAC, Same Limits

Agents can only access endpoints the user has RBAC permissions for. No implicit privilege escalation.

Org Context Preserved

Organization UUID is forwarded on every backend call via headers. Multi-tenancy enforced end-to-end.

Session Isolation

Each MCP connection gets a unique session. Sessions are validated on every request to prevent cross-session access.

User-Registered MCP Endpoints

Users can register external MCP services with their own bearer tokens, stored securely and scoped to their identity.

Ownership Verification

Before granting tool access, Eden verifies the user owns the MCP endpoint and belongs to the correct organization.

Security Properties

Defense in depth across every layer of the auth stack.

HMAC-SHA256
JWT Signing

Tokens signed with HMAC-SHA256 for tamper-proof authentication

SHA-256 + Salt
Password Storage

Per-user random salt combined with SHA-256 hash — plaintext never stored

Never Stored
API Key Plaintext

Robot API keys hashed on creation. Plaintext returned once, then discarded

Configurable
Token Expiry

JWT expiration configurable per deployment. Default 1 hour with refresh support

Hierarchical
Permission Checks

Each level inherits all permissions below it. No privilege escalation possible

Redis + PG
Dual Storage

Redis for sub-millisecond lookups, PostgreSQL as source of truth

Ready to Secure Your Data Stack?

Unified auth and RBAC for every endpoint. Get started with Eve today.