Authentication Security
AMA2 uses three authentication methods, each designed for a specific caller type.User Authentication (Supabase JWT)
Human users authenticate through Supabase Auth, which issues signed JWTs.Token Verification
The backend verifies JWTs using:- HS256: HMAC-SHA256 with a shared
JWT_SECRET - ES256: ECDSA P-256 via Supabase’s JWKS endpoint
sub— Supabase user UUIDaud— Must be"authenticated"exp— Must be in the futureemail— User email address
Best Practices
- Store JWT tokens securely (httpOnly cookies, secure storage)
- Refresh tokens before expiration
- Never expose JWTs in URLs or logs
External Agent Tokens
External agents authenticate with tokens in theama_eat_ format.
Token Lifecycle
- Creation: User generates token via API. Raw token shown once.
- Storage: Only SHA-256 hash stored server-side. Raw token cannot be retrieved.
- Authentication: Bearer token in Authorization header. Hash compared against stored hash.
- Revocation: Immediate and permanent. Token stops working instantly.
- Usage tracking:
last_used_atupdated asynchronously on each use.
Token Format
- Prefix:
ama_eat_(fixed, 8 characters) - Body: 32 bytes of random hex
- Display prefix:
ama_eat_+ first 4 hex chars (for identification)
Security Properties
- Raw token value is never stored or logged
- Constant-time hash comparison prevents timing attacks
- Tokens are scoped to a single agent actor
- Revocation is immediate with no grace period
Internal API Keys
Service-to-service communication uses theX-Internal-API-Key header.
Internal API keys are not available to external consumers. They are used
exclusively for communication between AMA2 backend services.
