Skip to main content
The authentication service wraps Auth0 so the mobile and web clients never talk to Auth0 directly. All routes live under /api/v1/auth unless otherwise noted.
Testing locally? Run npx serve -l 3000 from the project root and open http://localhost:3000/test-google-token.html to generate a real Google ID token for testing. See the Google OAuth docs for details.

Prerequisites

  • Auth0 tenant with the database connection enabled and client credentials set in .env (AUTH0_DOMAIN, AUTH0_CLIENT_ID, etc.).
  • Front-channel URLs registered in Auth0 for GET /login/google and GET /callback/google.
  • Exotel credentials for OTP routes and a verified sender ID.
  • Bearer token (Auth0 access token) when hitting any protected route such as /api/v1/auth/me. Use POST /signin or /google to obtain one.

Email + password

Requirements:
  • Password must be ≥8 chars and include uppercase, lowercase, and a digit
    (signupRequestSchema in src/services/auth/types/auth-schemas.ts).
  • Successful signup/signin returns { accessToken, idToken, refreshToken, expiresIn, user }.
POST /signin takes the same body (email + password) and returns the same envelope. Tokens are Auth0-issued JWTs referenced throughout the API.

Google OAuth

1. Token exchange (mobile/native)

Mobile clients obtain the Google ID token via the platform SDK and exchange it server-side. Try it via the POST /api/v1/auth/google panel.

2. Redirect flow (web)

  1. GET /api/v1/auth/login/google → redirects to Auth0’s hosted login page (optional state query param supported).
  2. GET /api/v1/auth/callback/google → handles the authorization code, fetches user info, syncs MongoDB via userSyncService, and forwards the tokens plus the original state back to the frontend.
Both flows call authOrchestrationService.googleAuth() and return the standard token envelope.

Token lifecycle

Refresh

POST /api/v1/auth/refresh with body { "refreshToken": "<token>" } returns { accessToken, idToken, expiresIn }. No Bearer token required—the refresh token is validated via Auth0 (tokenService.refreshAccessToken).
Use the Refresh Access Token playground to verify your refresh tokens are wired correctly.

Signout

POST /api/v1/auth/signout accepts an optional refreshToken. When provided, the backend revokes it via Auth0; when omitted, the call simply returns { success: true, message: "Successfully signed out" } so clients can clear local state.

Profile (GET & PATCH /me)

The /me endpoint is the unified profile endpoint that replaces the old /profile route.

Get Profile

GET /api/v1/auth/me requires Authorization: Bearer <Access Token>. Returns the full profile overview including user data, usage statistics, and profile context:
If the user does not exist locally, the controller auto-creates it based on the Auth0 payload before responding.

Update Profile

PATCH /api/v1/auth/me accepts partial updates for fullName or preferences (language, theme, notifications), and supports avatar upload via multipart form data. Returns the updated profile overview. JSON Request (no avatar):
Multipart Request (with avatar):
Delete Avatar:
Supports JPEG, PNG, GIF, and WebP images. Large images are automatically compressed.

Phone OTP (Exotel)

Phone OTP authentication via Exotel SMS. All routes are under /api/v1/auth.

Required Headers

Send OTP

Kicks off an Exotel SMS and enforces cooldowns via otpOrchestrationService.sendOTP.

Resend OTP

Respects OTP_RESEND_COOLDOWN_SECONDS (default 60s) before dispatching another SMS.

Verify OTP

On success, returns the standard auth envelope with Auth0 tokens:
The accessToken can be used with all authenticated endpoints just like email/password tokens.

Webhooks (server-to-server)

Both routes use auth0JwtMiddleware and are not intended for client apps.

Health

GET /api/v1/auth/health returns the provider info and the exported endpoints, useful for monitoring or smoke tests.

Error format

All controllers extend BaseController and emit the shared error envelope: