Security Flaw: Auth Endpoints Expose Tokens in JSON Response, Undermining httpOnly Cookie Protection

A significant security design flaw has been identified in the authentication system, where critical access and refresh tokens are being unnecessarily exposed in plain JSON responses. The registration and login endpoints (`src/api/routes/auth.py:103,155`) return these tokens in the response body via a `TokenResponse` model, even as they are simultaneously set as secure httpOnly cookies. This dual-channel exposure fundamentally undermines the primary security benefit of using httpOnly cookies in the first place, creating a redundant and dangerous vector for token theft.

The core issue is that while the httpOnly flag correctly prevents client-side JavaScript from directly accessing the cookies, the tokens remain fully accessible to any JavaScript code that can read the JSON response body from the login or registration API calls. This means that any Cross-Site Scripting (XSS) vulnerability present in the frontend application could potentially intercept these fetch responses and exfiltrate the tokens. Notably, the frontend's `OAuthCallbackPage.tsx` does not use these body tokens, relying correctly on the cookies, and the OAuth callback endpoint itself only sets cookies without a JSON body—highlighting that the exposure is isolated to the email/password authentication flow.

This flaw represents a medium-risk vulnerability that erodes the application's defense-in-depth strategy. It reintroduces the risk that the httpOnly cookie was designed to mitigate. If any part of the frontend code, a third-party library, or a browser extension inadvertently stores, logs, or transmits the response body, the authentication tokens become as vulnerable as if they were stored in `localStorage`. The exposure is not theoretical; it is a live, active leakage of credentials every time a user logs in or registers, waiting to be exploited by a sufficiently advanced client-side attack.