Skip to main content
This guide explains how to use Definable’s security dependencies to protect your API endpoints with authentication and role-based access control (RBAC). These FastAPI dependencies provide a clean, declarative way to enforce security policies across your application.

Overview

Definable provides two main security dependencies:
  1. JWTBearer: Validates JWT tokens (both Stytch session tokens and API keys)
  2. RBAC: Enforces role-based permissions on protected resources
These dependencies work together to provide a complete authentication and authorization solution.

Architecture

JWTBearer Dependency

The JWTBearer class validates JWT tokens and extracts user identity.

Location

File: src/dependencies/security.py

Implementation

Using JWTBearer

Basic Authentication

Protect an endpoint by requiring a valid JWT token:

Accessing User Information

The JWTBearer dependency returns a dictionary with user information:

RBAC Dependency

The RBAC class enforces role-based permissions on resources.

Implementation

Using RBAC

Use the dependencies parameter for cleaner code when you don’t need the user context:

Method 2: Direct Dependency

Use as a direct dependency when you need the user context:

Permission Patterns

Standard Permissions

Resource Types

Common resources in Definable:
  • kb - Knowledge bases
  • conversation - Conversations/chats
  • agent - AI agents
  • tool - Tools
  • organization - Organization settings
  • user - User management
  • role - Role management
  • api_key - API key management

Action Types

Common actions:
  • read - View/list resources
  • write - Create/update resources
  • delete - Delete resources
  • admin - Full administrative access
  • execute - Execute/run resources (agents, tools)

Combining Dependencies

Both Authentication and Authorization

Most endpoints need both:

Multiple Permission Checks

For endpoints requiring multiple permissions:

WebSocket Authentication

WebSockets require special handling since they can’t use the Authorization header.

WebSocket Token Passing

Pass the JWT token as a query parameter:

Protecting WebSocket Endpoints

WebSocket with RBAC

Error Handling

Authentication Errors

401 Unauthorized - Token is invalid or missing:
Common causes:
  • Token expired
  • Invalid token signature
  • Malformed token
  • Token from wrong environment (test vs live)

Authorization Errors

403 Forbidden - User lacks required permission:
Common causes:
  • User doesn’t have the required role
  • User’s role lacks the required permission
  • User is not a member of the organization
  • User’s membership is not active

Custom Error Responses

Testing Protected Endpoints

Unit Testing with Mocked Dependencies

Integration Testing with Real Tokens

Best Practices

1. Always Use Dependencies

Don’t manually parse tokens or check permissions:

2. Specific Permissions

Use specific permissions instead of wildcards when possible:

3. Organization Context

Always pass org_id for RBAC checks:

4. Consistent Error Messages

Use consistent error messages for security:

5. Logging

Log authentication failures for security monitoring:

Performance Considerations

Database Queries

The RBAC dependency performs database queries to check permissions. For high-traffic endpoints, consider:
  1. Caching: Cache role-permission mappings
  2. Connection Pooling: Use proper database connection pools
  3. Indexes: Ensure proper indexes on organization_members, roles, and permissions tables

Token Validation

  • JWKS Caching: Stytch public keys are cached for 10 minutes
  • Connection Reuse: HTTP connections to Stytch are reused
  • Local Validation: Most JWT validation happens locally

Next Steps