Auth: migrate OAuth routes from /rest/v1/login to /rest/v1/auth/*

[northdpole]

Context

RFC merged in #876 (docs/rfc/user-auth-myopencre.md) proposes new auth routes at /auth/login, /auth/callback, /auth/logout. Existing Google OAuth already lives at:

• GET /rest/v1/login
• GET /rest/v1/callback
• GET /rest/v1/logout
• GET /rest/v1/user

Per maintainer review of #876, consolidate under the versioned API namespace:

Target routes:

• GET /rest/v1/auth/login
• GET /rest/v1/auth/callback
• GET /rest/v1/auth/logout
• GET /rest/v1/auth/user (or keep /rest/v1/user — decide during implementation)

Requirements

• Add /rest/v1/auth/* routes implementing the RFC TODO 1 session contract (session['user_id'], redirect on missing session)
• Keep /rest/v1/login, /rest/v1/callback, /rest/v1/logout as temporary aliases with deprecation headers or redirect to /rest/v1/auth/*
• Update frontend (useUser, Header) and any docs referencing old paths
• Update login_required to redirect to /rest/v1/auth/login?next=<url> (not 401 for browser flows)
• Consider separate behavior for API clients (Accept: application/json → 401 vs browser → 302)

Related

• RFC: docs/rfc/user-auth-myopencre.md TODO 1
• Add support for users #586 (MyOpenCRE online)
• feat(frontend): add reusable useUser hook and header auth UX #943 (frontend auth UX)
• feat(api): add GET /api/capabilities to expose myopencre feature flag #949 (capabilities API)

Acceptance criteria

• New routes work end-to-end with Google OAuth
• Old routes redirect or alias without breaking existing bookmarks
• Tests cover both old aliases and new canonical paths during migration window

[skypank-coder]

@northdpole I'd like to take this — it's TODO 1 of the RFC and builds directly on #943 and #949, so it's a natural next step for me.
My read on the approach:

Add the /rest/v1/auth/* routes implementing the TODO 1 session contract (session['user_id'], redirect on missing session), with the old /rest/v1/login|callback|logout kept as aliases during the migration window so existing bookmarks don't break.
Migrate login_required to redirect browser flows to /rest/v1/auth/login?next=, while keeping a 401 for API clients (Accept: application/json) — matching the content-negotiation point in the requirements.
Update useUser/Header to the new paths.

One decision to confirm before I start: for the user endpoint, I'd lean toward moving it to /rest/v1/auth/user for namespace consistency, keeping /rest/v1/user as an alias — but happy to keep it at /rest/v1/user if you'd rather minimize surface change. Any preference?
Will keep the PR scoped to the migration + alias + tests covering both old and new paths, per the acceptance criteria.

[northdpole]

Thanks for volunteering on this, @skypank-coder — really appreciate the clear read on the RFC and how you've mapped this to TODO 1, building on #943/#949. We're glad to have you on the auth work.

Assignment: You're assigned to #963. Please treat this as yours to drive; ping us anytime if something is unclear or blocked.

User endpoint: Go with your preference — move the canonical route to /rest/v1/auth/user, and keep /rest/v1/user as an alias during the migration for namespace consistency with the rest of /rest/v1/auth/*.

Scope (confirmed):

• Add the new /rest/v1/auth/* routes
• Keep the old login / callback / logout paths as aliases for now
• login_required: browser clients → redirect; JSON API clients → 401
• Update useUser / Header (and related frontend touchpoints) accordingly

Sequencing: Land #963 first. Once the session check is in place, #966 (CSV import auth-wrap) can follow.

Your plan looks right — proceed when ready. Questions welcome at any point.