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.

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.