AIRBNB
FRONTEND GUIDE FOR AI CODING AGENTS - PART 2 - Authentication Management
This document covers the authentication features of the airbnb project: registration, login, logout, and session management. The project introduction, API conventions, base URLs, home page, and multi-tenancy setup were covered in the previous introductory prompt — make sure those are implemented before proceeding.
All auth APIs use the auth service base URL with the /auth-api prefix (e.g., https://airbnb3.mindbricks.co/auth-api).
FRONTEND_URL
The FRONTEND_URL environment variable is automatically set on the auth service from the project’s frontendUrl setting in Basic Project Settings. It contains the base URL of the frontend application for the current deployment environment (e.g., http://localhost:5173 for dev, https://myapp.com for production). Defaults if not configured:
| Environment | Default |
|---|---|
| dev | http://localhost:5173 |
| test | https://airbnb3.prw.mindbricks.com |
| stage | https://airbnb3-stage.mindbricks.co |
| prod | https://airbnb3.mindbricks.co |
This variable is used by the auth service for:
- Social login redirects — after OAuth processing, the auth service redirects to
FRONTEND_URL + /auth/callback(the frontend must have a page at this route; see the Social Login prompt for details) - Email notification links — verification, password reset, and other links in emails point back to the frontend
You can customize FRONTEND_URL per environment by configuring the frontendUrl field in your project’s Basic Project Settings (e.g., when using a custom domain).
Registration Management
User Registration
User registration is public in the application. Please create a simple and polished registration page that includes only the necessary fields of the registration API.
Using the registeruser route of the auth API, send the required fields from your registration page.
The registerUser API in the auth service is described with the request and response structure below.
Note that since the registerUser API is a business API, it is versioned; call it with the given version like /v1/registeruser.
Register User API
This api is used by public users to register themselves
Rest Route
The registerUser API REST controller can be triggered via the following route:
/v1/registeruser
Rest Request Parameters
The registerUser api has got 6 regular request parameters
| Parameter | Type | Required | Population |
|---|---|---|---|
| avatar | String | false | request.body?.[“avatar”] |
| password | String | true | request.body?.[“password”] |
| fullname | String | true | request.body?.[“fullname”] |
| String | true | request.body?.[“email”] | |
| preferredLanguage | String | false | request.body?.[“preferredLanguage”] |
| bio | Text | false | request.body?.[“bio”] |
| avatar : The avatar url of the user. If not sent, a default random one will be generated. | |||
| password : The password defined by the the user that is being registered. | |||
| fullname : The fullname defined by the the user that is being registered. | |||
| email : The email defined by the the user that is being registered. | |||
| preferredLanguage : User’s preferred language for the application interface | |||
| bio : User’s biography or profile description |
REST Request To access the api you can use the REST controller with the path POST /v1/registeruser
axios({
method: 'POST',
url: '/v1/registeruser',
data: {
avatar:"String",
password:"String",
fullname:"String",
email:"String",
preferredLanguage:"String",
bio:"Text",
},
params: {
}
});
REST Response
{
"status": "OK",
"statusCode": "201",
"elapsedMs": 126,
"ssoTime": 120,
"source": "db",
"cacheKey": "hexCode",
"userId": "ID",
"sessionId": "ID",
"requestId": "ID",
"dataName": "user",
"method": "POST",
"action": "create",
"appVersion": "Version",
"rowCount": 1,
"user": {
"id": "ID",
"email": "String",
"password": "String",
"fullname": "String",
"avatar": "String",
"roleId": "String",
"emailVerified": "Boolean",
"preferredLanguage": "String",
"bio": "Text",
"isActive": true,
"recordVersion": "Integer",
"createdAt": "Date",
"updatedAt": "Date",
"_owner": "ID"
}
}
After a successful registration, the frontend code should handle any verification requirements. Verification Management will be given in the next prompt.
The registration response will include a user object in the root envelope; this object contains user information with an id field.
Login Management
Login Identifier Model
The primary login identifier for this application is the email address. Users register and log in using their email and password. No mobile field is stored in the user data model. The login page should include an email input and a password input.
Login Flow
After successful registration and completing any required verifications, the user can log in. Please create a minimal, polished login page as described above. Note that this page should respect the deployment (environment) selection option made in the home page to set the base URL. If the user reaches this page directly skipping home page, the default production deployment will be used.
The login API returns a created session. This session can be retrieved later with the access token using the /currentuser system route.
Any request that requires login must include a valid token. When a user logs in successfully, the response JSON includes a JWT access token in the accessToken field. Under normal conditions, this token is also set as a cookie and consumed automatically. However, since AI coding agents’ preview options may fail to use cookies, ensure that each request includes the access token in the Bearer authorization header.
If the login fails due to verification requirements, the response JSON includes an errCode. If it is EmailVerificationNeeded, start the email verification flow; if it is MobileVerificationNeeded, start the mobile verification flow.
After a successful login, you can access session (user) information at any time with the /currentuser API. On inner pages, show brief profile information (avatar, name, etc.) using the session information from this API.
Note that the currentuser API returns a session object, so there is no id property; instead, the values for the user and session are exposed as userId and sessionId. The response combines user and session information.
The login, logout, and currentuser APIs are as follows. They are system routes and are not versioned.
POST /login — User Login
Purpose: Verifies user credentials and creates an authenticated session with a JWT access token.
Access Routes:
Request Parameters
| Parameter | Type | Required | Source |
|---|---|---|---|
username |
String | Yes | request.body.username |
password |
String | Yes | request.body.password |
Behavior
- Authenticates credentials and returns a session object.
- Sets cookie:
projectname-access-token[-tenantCodename] - Adds the same token in response headers.
- Accepts either
usernameoremailfields (if both exist,usernameis prioritized). Themobilefield is also accepted when the user has a mobile number on file.
Example
axios.post("/login", {
email: "user@example.com",
password: "securePassword"
});
Success Response
{
"sessionId": "e81c7d2b-4e95-9b1e-842e-3fb9c8c1df38",
"userId": "d92b9d4c-9b1e-4e95-842e-3fb9c8c1df38",
"email": "user@example.com",
"fullname": "John Doe",
//...
"accessToken": "ey7....",
"userBucketToken": "e56d....",
"sessionNeedsEmail2FA": true,
}
Note on bucket tokens: The
userBucketTokenis for the external bucket service (used for general file uploads like documents and product images). User avatars do not use the external bucket service — they are uploaded via database buckets (dbBuckets) built into the auth service using the regularaccessToken. See the Profile or Bucket Management sections for dbBucket avatar upload details.
Two-Factor Authentication (2FA): When the login response contains
sessionNeedsEmail2FA: true, the session is not yet fully authorized. TheaccessTokenis valid but all protected API calls will return403until 2FA is completed. Do not treat this login as successful — instead, store theaccessToken,userId, andsessionId, and navigate the user to a 2FA verification page. The 2FA flow details are covered in the Verification Management prompt.
Error Responses
401 Unauthorized: Invalid credentials403 Forbidden: Email/mobile verification or 2FA pending400 Bad Request: Missing parameters
POST /logout — User Logout
Purpose: Terminates the current session and clears associated authentication tokens.
Behavior
- Invalidates the session (if it exists).
- Clears cookie
projectname-access-token[-tenantCodename]. - Returns a confirmation response (always
200 OK).
Example
axios.post("/logout", {}, {
headers: { "Authorization": "Bearer your-jwt-token" }
});
Notes
- Can be called without a session (idempotent behavior).
- Works for both cookie-based and token-based sessions.
Success Response
{ "status": "OK", "message": "User logged out successfully" }
GET /currentuser — Current Session
Purpose Returns the currently authenticated user’s session.
Route Type
sessionInfo
Authentication Requires a valid access token (header or cookie).
Request
No parameters.
Example
axios.get("/currentuser", {
headers: { Authorization: "Bearer <jwt>" }
});
Success (200)
Returns the session object (identity, tenancy, token metadata):
{
"sessionId": "9cf23fa8-07d4-4e7c-80a6-ec6d6ac96bb9",
"userId": "d92b9d4c-9b1e-4e95-842e-3fb9c8c1df38",
"email": "user@example.com",
"fullname": "John Doe",
"roleId": "user",
"tenantId": "abc123",
"accessToken": "jwt-token-string",
"...": "..."
}
Note that the currentuser API returns a session object, so there is no id property, instead, the values for the user and session are exposed as userId and sessionId. The response is a mix of user and session information.
Errors
-
401 Unauthorized — No active session/token
{ "status": "ERR", "message": "No login found" }
Notes
- Commonly called by web/mobile clients after login to hydrate session state.
- Includes key identity/tenant fields and a token reference (if applicable).
- Ensure a valid token is supplied to receive a 200 response.
After you complete this step, please ensure you have not made the following common mistakes:
- The
/currentuserAPI returns a mix of session and user data. There is noidproperty —useuserIdandsessionId. - Note that any API call to the auth service should use the
/auth-apiprefix after the application’s base URL.
After this prompt, the user may give you new instructions to update your output or provide subsequent prompts about the project.