Skip to main content

Overview

The VIGIA API uses JWT (JSON Web Token) based authentication with role-based access control (RBAC) and multi-tenancy support. All authenticated endpoints require a valid bearer token in the Authorization header.

Authentication Flow

  1. Login: Send credentials to /api/v1/auth/login to receive a JWT token
  2. Token Storage: Store the token securely on the client side
  3. API Requests: Include the token in the Authorization header for all protected endpoints
  4. Token Refresh: Tokens expire after 480 minutes (8 hours) by default

Multi-Tenant Architecture

VIGIA supports multi-tenant authentication using the X-Tenant header. Each tenant has isolated data and users.
If no X-Tenant header is provided, the system falls back to the legacy tenant mode.

Tenant Header

X-Tenant: customer-subdomain
The tenant identifier is embedded in the JWT token and validated on each request.

Token Structure

JWT tokens issued by VIGIA contain the following claims:
ClaimTypeDescription
substringUser ID (string representation)
uidintegerUser ID (numeric)
usernamestringUsername
emailstringUser email address
rolestringPrimary role (e.g., “admin”, “qf”)
rolesarrayAll assigned roles
tenantstringTenant identifier
tracestringRequest trace ID for logging
expintegerExpiration timestamp

Available Roles

VIGIA uses a predefined set of roles for access control:
  • admin: Full system access, administrative privileges
  • qf: Qualified Person (Farmacovigilancia)
  • responsable_fv: Pharmacovigilance Manager
  • qa: Quality Assurance
  • direccion_tecnica: Technical Director
  • legal: Legal Department
  • soporte: Support/Help Desk
Users must have at least one role assigned to authenticate successfully. The system automatically selects “admin” as the primary role if present, otherwise uses the first role in the list.

Security Headers

Required Headers for All Authenticated Requests

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-Tenant: customer-subdomain

Optional Headers

X-Request-ID: unique-request-identifier
X-Trace-ID: trace-identifier-for-logging

Token Expiration

Tokens expire after 480 minutes (8 hours) by default. When a token expires, clients receive a 401 Unauthorized response and must re-authenticate.

Password Requirements

  • Minimum length: 6 characters
  • Stored using bcrypt hashing algorithm
  • Password changes require current password verification

Error Responses

All authentication endpoints return standard error responses:

401 Unauthorized

{
  "detail": "Credenciales inválidas"
}
Returned when:
  • Invalid credentials provided
  • Token is invalid or malformed
  • User not found

403 Forbidden

{
  "detail": "Usuario inactivo"
}
Returned when:
  • User account is inactive
  • User has no roles assigned

422 Unprocessable Entity

{
  "detail": "Usuario y contraseña requeridos"
}
Returned when:
  • Required fields are missing
  • Password is too short (< 6 characters)

Rate Limiting

Implement rate limiting on the client side to prevent account lockouts. Excessive failed login attempts may trigger security measures.

Best Practices

  1. Store tokens securely: Use httpOnly cookies or secure storage mechanisms
  2. Never expose tokens: Don’t log tokens or include them in URLs
  3. Use HTTPS: Always use encrypted connections in production
  4. Implement token refresh: Refresh tokens before expiration for seamless UX
  5. Handle 401 responses: Redirect to login when tokens expire
  6. Validate tenant context: Always include the correct X-Tenant header

Next Steps

Login Endpoint

Learn how to authenticate and obtain JWT tokens

Permissions

Understand role-based access control

Build docs developers (and LLMs) love