fix(gateway): accept the __Secure- prefixed NextAuth session cookie - #475

I have read the CONTRIBUTING.md file.

YES

What kind of change does this PR introduce?

Bug fix.

What is the current behavior?

On a self-hosted instance running multi-user mode (NEXTAUTH_SECRET set) and served over HTTPS, every browser call to the gateway returns 401. That covers vault pair/status, pending approvals, approval decisions, and cache invalidation — so the 1Password and Bitwarden panels, the approvals UI, and the 1Password value picker are all unusable, while the rest of the dashboard works normally.

validate_oauth reads the session cookie by exact name:

let token = parse_cookie(cookie_header, "authjs.session-token")

Auth.js prefixes that cookie with __Secure- whenever it considers the deployment secure, which it derives from the scheme of the resolved AUTH_URL / NEXTAUTH_URL. A self-hosted instance cannot avoid this: OAuth providers require an https redirect URI for anything other than localhost (Google documents the rule explicitly), so the single variable that makes login work also renames the cookie. The gateway then never finds it and logs oauth auth: session token cookie not found.

Local-mode installs are unaffected, because validate_local never inspects the cookie — which is likely why this has gone unnoticed.

Controlled reproduction

Same request, same (fabricated) JWT, only the cookie name differs:

$ curl -H "Cookie: authjs.session-token=eyJhbGciOiJIUzI1NiJ9.fake.sig"          .../me
$ curl -H "Cookie: __Secure-authjs.session-token=eyJhbGciOiJIUzI1NiJ9.fake.sig" .../me

WARN onecli_gateway::auth: oauth auth: JWT decode failed error=InvalidSignature   # bare name: found, decoded
WARN onecli_gateway::auth: oauth auth: session token cookie not found             # prefixed name: never seen

And the same instance, over HTTPS, confirming which name a browser is actually sent:

$ curl -sD - https://<instance>/api/auth/csrf | grep -i set-cookie
set-cookie: __Host-authjs.csrf-token=...
set-cookie: __Secure-authjs.callback-url=...

What is the new behavior?

The lookup accepts either spelling, via a small helper:

fn session_token_from_cookies(cookie_header: &str) -> Option<&str> {
    parse_cookie(cookie_header, "authjs.session-token")
        .or_else(|| parse_cookie(cookie_header, "__Secure-authjs.session-token"))
}

The bare name is checked first, so http/localhost installs keep their existing single-comparison path and behaviour is unchanged for them. Four unit tests cover the bare name, the __Secure- prefixed name, precedence when both are present, and neither present.

Additional context

Found while running a self-hosted instance behind a reverse proxy with TLS and an external IdP. It is reachable from any edition that can run in oauth mode over HTTPS, and it becomes considerably easier to hit alongside #430, which lets self-hosters use a non-Google IdP and so brings more TLS deployments into multi-user mode.

#474 would also resolve this, by having the web app attach an API key so the gateway never falls through to the cookie. The two are complementary rather than competing: this change makes the documented session path work as intended and is a few lines, while #474 additionally closes the local-mode trust gap in #263. Happy to close this if #474 is the preferred direction.

Verification

Run against apps/gateway (musl toolchain, matching docker/Dockerfile):

• cargo fmt --check — clean
• cargo clippy --all-targets — no new warnings
• cargo test auth:: — 7 passed (3 pre-existing, 4 new), 0 failed

Also verified on a live deployment: with the fix in place, a browser request carrying __Secure-authjs.session-token reaches JWT validation instead of being rejected as missing.

It does not, on its own, make session auth work — see the correction in the comments. Auth.js issues an encrypted (JWE) session token, while validate_oauth decodes with jsonwebtoken under Algorithm::HS256, which expects a signed JWS, so validation fails one step later with Base64 error: Invalid symbol 46. That is a second, independent problem on the same path and out of scope here. This PR fixes the cookie lookup only, which is a prerequisite either way.

No TypeScript is touched, so pnpm check / pnpm build are unaffected by this change.