Authentication and Authorization

auth-service (auth-service_v2)

The auth service is the identity gateway for the Jeen platform. It authenticates users against external identity providers, issues its own JWT tokens, manages sessions via Redis, and delegates user record creation to user-service.

Supported Identity Providers

Provider	Method
Firebase	Firebase Admin SDK -- email/password auth, token verification
ZITADEL	OAuth2 -- token introspection, JWKS validation

Auth Flow

1. Client sends credentials to POST /api/v1/iam/exchange (login) or POST /api/v1/iam/register (register)
2. Auth service validates credentials against the identity provider (Firebase or ZITADEL)
3. On success, auth service looks up or creates the user in user-service via HTTP
4. Auth service issues its own JWT access token (RS256) and refresh token
5. Tokens are returned in HTTP-only cookies and response body
6. Subsequent requests include the JWT in the Authorization: Bearer <token> header

Endpoints

Method	Path	Auth	Description
POST	/api/v1/iam/exchange	Public	Login -- authenticate with provider, issue tokens
POST	/api/v1/iam/register	Public	Register -- create account with provider + user-service
POST	/api/v1/iam/token/refresh	Public	Refresh tokens using refresh token cookie
POST	/api/v1/iam/logout	JWT	Invalidate refresh token, clear session, clear cookies
POST	/api/v1/iam/zitadel/exchange	Public	ZITADEL token exchange -- validate ZITADEL tokens, create session

Session Management

• Sessions stored in Redis with key pattern: zitadel/{provider}/{orgId}/{userId}
• Refresh tokens stored in an in-memory token store (planned migration to Redis)
• Sessions can be extended or invalidated

Inter-Service Calls

Target	Call	Purpose
user-service	GET /user/by-email?email=	Look up user during login
user-service	POST /user	Create user during registration
user-service	GET /user/zitadel/:id	Find user by ZITADEL ID
user-service	POST /user/zitadel	Create user from ZITADEL data

RBAC System (admin-base-ms)

Authorization is managed by admin-base-ms, which provides a full RBAC implementation:

• Roles -- assigned per organization, support hierarchy via parentId and level
• Permissions -- link actions to modules and features, with optional conditions
• Role-Permissions -- many-to-many mapping of roles to permissions
• Modules / Features / Actions -- define the permission structure

user-service uses CASL (Attribute-Based Access Control) to enforce permissions at the BFF layer by fetching role-permission data from admin-base-ms.