Authentication

The Authentication module contains two core endpoints: POST /v1/auth/login and POST /v1/auth/logout. Login works for every UserType (INDIVIDUAL, ORGANIZATION, MORIA) with one DTO and sets the access_token cookie (httpOnly) plus the Token header. The shape of data on the login response varies by user type (e.g. organization users receive extra organization fields).

Property	Value
Base URL	{HOST}/v1
Auth	Bearer JWT (header Authorization) or cookie access_token
Content-Type	application/json
Error envelope	{ "message": string | string[], "statusCode": number, "error": string }
Validation	Global ValidationPipe · whitelist: true, forbidNonWhitelisted: true · unknown fields → 400
Related modules	Users, Organizations, Onboarding, Security

Summary

The FE starts a session with POST /v1/auth/login using email + password. The server validates credentials via LocalAuthGuard and issues a JWT through three channels at once: the httpOnly cookie access_token, the response header Token, and (for clients that manage their own) the data field. Logout requires a still-valid token — the server clears the cookie and ends the backend session.

Method	Path	Auth	Description
POST	/v1/auth/login	public	Universal login (INDIVIDUAL / ORGANIZATION / MORIA)
POST	/v1/auth/logout	bearer	End the active session and clear cookie

Auth notes

• Cookie access_token is set with HttpOnly, Secure, SameSite=Strict, Path=/, and Max-Age=3600 (1 hour).
• Header Token is exposed via CORS so the web FE can read the JWT directly for subsequent Bearer requests.
• The global validation pipe rejects fields outside the DTO (forbidNonWhitelisted) — send only email and password.
• Logout requires a valid Bearer/cookie. If the token is already expired, the FE should still clear local storage defensively.

---

POST /v1/auth/login public

Authenticate a user via email + password. The endpoint covers every UserType — the response data shape varies by user type. The server sets the access_token cookie and the Token response header containing the JWT.

Request body — UsersLoginDto

Field	Type	Required	Notes
email	string	yes	IsEmail — valid email format
password	string	yes	IsNotEmpty — user password

Example request

{
  "email": "admin@moriafund.com",
  "password": "Password@123"
}

Response — 200 OK

{
  "status": "success",
  "statusCode": 200,
  "message": "login successful",
  "data": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "email": "admin@moriafund.com",
    "user_type": "organization",
    "first_name": "Anas",
    "last_name": "Malik",
    "phone_number": "+628156489101",
    "current_login_user_id": "550e8400-e29b-41d4-a716-446655440000",
    "organization_id": "660e8400-e29b-41d4-a716-446655440111",
    "name": "Moria Fund",
    "org_email": "ops@moriafund.com",
    "org_phone_number": "+628123456788",
    "status": "active",
    "accounts": [
      {
        "id": "770e8400-e29b-41d4-a716-446655440222",
        "name": "Main Business Account",
        "balance": 10000.5,
        "currency": "IDR",
        "owner_type": "ORGANIZATION"
      }
    ]
  }
}

For user_type === 'individual' or 'moria', the organization fields (organization_id, name, org_email, org_phone_number, status, accounts) are not sent — only BaseUserData properties. The access_token cookie and Token header are always set on success.

Errors

Status	When
400 Bad Request	Unknown fields, invalid email format, or empty password
401 Unauthorized	Wrong credentials (email/password mismatch)
404 Not Found	Organization account not yet activated, or deactivated

Side effects

• Sets the httpOnly cookie access_token for 3600 seconds.
• Sends the Token (JWT) header on the response.
• Backend records the login event for audit.

---

POST /v1/auth/logout bearer

Log out the authenticated user. The server clears the access_token cookie (clearCookie with the same flags as set) and ends the backend session.

Response — 200 OK

{
  "status": "success",
  "statusCode": 200,
  "message": "logout successful",
  "data": {}
}

After this call, the FE must clear any local JWT storage and redirect the user to the login screen.

Errors

Status	When
401 Unauthorized	No valid Bearer/cookie (e.g. expired token)
403 Forbidden	Access denied by guard

Side effects

• Cookie access_token is removed on the response (Set-Cookie with Max-Age=0).
• The backend session is marked ended for the related user.

---

Reference

Enum: UserType

• moria — platform superadmin
• organization — organization admin / member
• individual — end user

Success response envelope

The global response interceptor wraps the controller return as:

{
  "status": "success",
  "statusCode": 200,
  "message": "...",
  "data": { }
}

Standard error envelope

{
  "message": "Invalid credentials",
  "statusCode": 401,
  "error": "Unauthorized"
}

message may be a string or an array of strings (multi-field validation error).

Common HTTP codes

• 400 — body validation
• 401 — wrong credentials / invalid token
• 403 — access denied by guard
• 404 — organization not yet active
• 500 — internal — show a generic toast