Authentication: OAuth support and refresh

[Ayush8923]

Is your feature request related to a problem?
Current authentication methods are limited to username/password and API keys, without support for OAuth-based login or token refresh. Users must manually re-authenticate when JWTs expire, leading to a poor user experience.

Describe the solution you'd like

1. Implement POST /api/v1/auth/google to verify Google ID tokens and issue a JWT access token + refresh token as HTTP-only cookies.

   • Auto-embed org/project in JWT for single org/project users.
   • Include requires_project_selection: true for multiple org/project users with an available_projects list.
   • Issue a user-only JWT for users without org/projects.

2. Add POST /api/v1/auth/select-project to allow multi-project users to select a project_id for a new JWT pair.

3. Introduce POST /api/v1/auth/refresh to validate and issue new access + refresh tokens using the refresh_token cookie.

4. Implement POST /api/v1/auth/logout to clear access_token and refresh_token cookies.

5. Update get_auth_context to support three auth methods by priority:

   • X-API-KEY header
   • Authorization: Bearer <token> header
   • access_token cookie (new)

Ensure JWT tokens populate AuthContext with org_id and project_id, matching API key auth behavior, and reject refresh tokens on regular API calls.

Add User in corresponding to org/project

1. Need to create the API Endpoint where superadmin can add the more user in the corresponding to Org/Project.
2. Create the one table where we have the mapping of user corresponding to their org and project for tracking.
3. Mark the user active after google login and when super admin add the new user in corresponding to any project then mark the user active false.

Original issue

Describe the current behavior
Authentication is currently supported via two methods:

1. Username/password login (POST /api/v1/login/access-token): returns a JWT access token
2. API Key (X-API-KEY header): used for programmatic access, embeds user + organization + project context

The frontend relies on API keys for accessing project-scoped endpoints. There is no OAuth-based login, no cookie-based session management, and no token refresh mechanism, when a JWT expires, the user must re-authenticate manually.

Describe the enhancement you'd like

1. POST /api/v1/auth/google- Accepts a Google ID token from the frontend, verifies it via google.oauth2.id_token, looks up the user by email, and issues a JWT access token + refresh token as HTTP-only cookies.

   • If the user has exactly 1 org/project (via API key records), it is auto-embedded in the JWT — making it work identically to API key auth.
   • If the user has multiple org/projects, the response includes requires_project_selection: true with available_projects list.
   • If the user has no org/projects, a user-only JWT is issued.

2. POST /api/v1/auth/select-project- For multi-project users, accepts a project_id and issues a new JWT pair with the selected org/project embedded.

3. POST /api/v1/auth/refresh - Reads the refresh_token cookie, validates it, and issues a new access + refresh token pair. This allows silent re-authentication without requiring the user to log in again.

4. POST /api/v1/auth/logout — Clears both access_token and refresh_token cookies.

5. Updated auth dependency (get_auth_context) — Now supports three auth methods in priority order:

   • X-API-KEY header (existing)
   • Authorization: Bearer <token> header (existing)
   • access_token cookie (new)

JWT tokens with org_id and project_id claims now populate AuthContext with organization and project, matching the behavior of API key auth. Refresh tokens are rejected on normal API calls.