Auth: hbf-data-manager

How this service handles authentication. Full flows: docs/architecture/auth-flows.md

Tokens This Service Accepts

Token type	Endpoints	Guard	Validation
User JWT (or CORE_TOKEN)	GET /orgs/:orgId/interactions, GET /orgs/:orgId/events/:id/interactions, GET /orgs/:orgId/events/:id/session-variables	HBFGuard	Calls hbf-core GET /users/me; also checks org-level role on orgId param
DM JWT	DELETE /chat-sessions/:sessionId/interactions, POST /chat-sessions/interactions/bulk-delete	DMJwtGuard	Local HS256 verification using DM_AUTH_JWT_SECRET; no call to hbf-core

Tokens This Service Sends

None. hbf-data-manager does not call other services at request time.

Tokens This Service Issues

None. hbf-data-manager does not issue tokens.

Roles / Scopes Enforced

Endpoints	Guard	Required role
GET /orgs/:orgId/**	HBFGuard	Any of: HBF_ORG_ADMIN, HBF_ORG_EDITOR, HBF_ORG_VIEWER, HBF_ORG_LIVECHAT_ADMIN, HBF_ORG_LIVE_AGENT for the given orgId; or isModerator = true
DELETE /chat-sessions/**	DMJwtGuard	Valid DM JWT (any payload); no role claim enforced

Auth Notes

• The dual-guard pattern is intentional: read endpoints are user-facing (console or service-to-service via CORE_TOKEN, validated through hbf-core), while delete endpoints are called exclusively by internal daemons (hbf-data-retention or similar) using a shared secret.
• DM_AUTH_JWT_SECRET is a symmetric HS256 secret shared between hbf-data-manager and any caller that needs to invoke the delete endpoints. It is independent of all hbf-core secrets.
• The delete endpoints are not in the .env.sample — DM_AUTH_JWT_SECRET must be added to the deployment environment manually.
• DMJwtGuard does not enforce any specific claims beyond a valid signature. The caller's identity is available on request.user after verification but is not checked further.