User Service
User Service is the NestJS service that manages authentication, authorization, and user management for the RAGA platform. It is the central issuer of the JWTs used across RAGA services (including API Tarantula), and owns the RBAC (Role-Based Access Control) model that is synced to OPA (Open Policy Agent) whenever a role or policy changes.
Tech Stack
| Component | Technology |
|---|---|
| Framework | NestJS 10 (TypeScript) |
| Database | PostgreSQL 16 via TypeORM |
| Cache / Session | Redis / Dragonfly (ioredis + Bull) |
| Object Storage | MinIO (user profile photos) |
| Search / Index | Elasticsearch (user activity logs) |
| Authentication | JWT (@nestjs/jwt) + bcrypt |
| Secret Management | Infisical |
Full version, environment variable, and folder structure details are on the Technical page.
Domain Model
RBAC in User Service is built from five core entities:
| Entity | Relation | Description |
|---|---|---|
User | ManyToOne to Role | User account; one user has one role |
Role | Connected to many Policy and ShortcutAcl entries | Access level (has a level field for hierarchy) |
Feature | OneToMany to Subfeature | Major module/feature in the platform |
Subfeature | ManyToOne to Feature | Granular access unit (has method + url) within a feature |
Policy | Links Role ↔ Feature ↔ Subfeature | RBAC rule row: whether a role may access a given subfeature (status: boolean) |
ShortcutAcl is a fast path: one shortcut ACL maps a role directly to a set of subfeatures without composing policies one by one — used for frequently reused access presets.
Module Map
| Domain | Modules |
|---|---|
| Authentication | auth, redis, mail |
| User Management | user (+ MinIO for profile photos) |
| RBAC | role, features, subfeatures, policies, shortcut-acls, opa |
| Support | open-api, activity-log, infisical, health, utils |
Authentication Flow
Login verifies credentials against PostgreSQL, signs a JWT, then stores the access & refresh tokens in Redis/Dragonfly with a TTL — the token entries in Redis are the source of truth for both validation and invalidation (logout deletes the key). Every role/policy change triggers a call to opa-data to keep OPA rules in sync. The full sequence diagram is on the Technical page.
External Integrations
| Service | Description |
|---|---|
opa-data (OPA) | Receives a sync trigger whenever a role/policy changes, then pulls fresh data via the open-api endpoints (role-users, role-grants) |
| API Tarantula | Receives a user name sync whenever user data is updated |
| License API | Platform license validation |
| Infisical | Source of all runtime secrets |
| Telegram Bot | Error-level log alerting |
Authentication & Access
Unlike API Tarantula, which separates an Open API surface (app_key) from an internal one, every User Service endpoint uses a single scheme: a JWT issued by the auth module, validated against the entry stored in Redis (not just the JWT signature) — so logout genuinely invalidates a token rather than relying on natural expiry alone.
Summary
User Service is RAGA's identity and access source of truth: it issues and manages the JWT lifecycle through Redis, stores the RBAC structure (role → policy → feature/subfeature), and keeps OPA in sync whenever the access structure changes — making it a core dependency for any other service that needs to decide "who can do what."