RFC: Block Use of Session Cookies for API Calls

### Which OpenObserve functionalities are relevant/related to the feature request?

login

### Description

Problem

Currently, browser session cookies can be copied and reused to make direct API calls (via curl, Postman, etc.).
This is an anti-pattern because:

It bypasses proper API authentication (Authorization headers with Basic/Bearer tokens).

It breaks auditability: logs attribute API calls to user sessions rather than integrations.

It weakens security: stolen cookies grant full API access.

It confuses usage boundaries: cookies should be for UI, tokens for APIs.

### Proposed solution

## Proposal

Enforce a strict separation between **UI session cookies** and **API access**.

### Changes

1. **Middleware enforcement**

* Add middleware at Actix layer for all `/api/*` routes.
* If a request contains a session cookie, reject with `401 Unauthorized`.
* Require presence of `Authorization` header (Basic or Bearer) for API calls.

2. **Cookie hardening**

* Ensure UI session cookies are always set with:

* `Secure`
* `HttpOnly`
* `SameSite` (default `Lax`, configurable to `Strict`)
* Use existing flags (`ZO_COOKIE_SECURE_ONLY`, `ZO_COOKIE_SAME_SITE_*`) with possible extension for `Strict`.

3. **Deployment guidance**

* Recommend serving UI at `app.example.com` and API at `api.example.com`.
* Scope cookies to `app.*` only, preventing accidental API use.

4. **CSRF protection**

* Add CSRF tokens to state-changing UI requests (`POST`, `PUT`, `PATCH`, `DELETE`).

5. **Audit logging**

* Log and expose a metric `auth.session_cookie_on_api_request` whenever cookies are detected on API paths.
* Optionally rate-limit repeated offenders.

6. **Documentation update**

* API docs must explicitly state:

> Session cookies are **not valid** for API access. Use `Authorization` headers (Basic/Bearer tokens or service accounts).
* Point users to \[service accounts / token exchange flows] for automation.

## Migration

* **Users of UI**: No change. Session cookies continue to work for web login flows.
* **Users of API**: If anyone currently copies cookies for API calls, they must migrate to:

* Basic auth (`Authorization: Basic …`)
* Service accounts (preferred)
* OIDC token exchange where enabled

## Rollout

1. Add middleware behind feature flag `ZO_API_REJECT_SESSION_COOKIE`.
2. Default to `true` in new deployments.
3. After one release cycle, remove flag and enforce globally.

## Benefits

* Closes security gap (no cookie replay on APIs).
* Preserves **clear separation**:

* Cookies → Browser UI sessions
* Headers (Basic/Bearer) → API integrations
* Improves audit and compliance reporting.
* Aligns behavior with OpenObserve’s own documentation.

### Alternatives considered

Reducing the Session timeout could just help but still that can be bypassed through a headless automation and cookiee stealing

Further more some alternatives could be
* RATE LIMIT logins / X times
* Device Fingerprinting per login , if many changes force re-auth
* push tokens as primary model for API access , Human access patterns requires auth and if automation is identified we need invalidate old sessions