<blockquote>
“I sat down to write a blog post. I found a systemic bug. While fixing it, I reopened the auth code, and the work circled back to the unfinished mechanism—suddenly I was migrating to OAuth 2.1.”
</blockquote>
This post consolidates the technical notes I’ve been jotting down over the last month. It outlines how I’m aligning a multi-tenant authentication layer with OAuth 2.1, the architectural decisions behind it, the practical pitfalls, and a short-term roadmap. Tools in the loop: Gemini, ChatGPT, and Cursor—what began as internal docs became the basis for this write-up.
<hr>
<h2>Where We Started and How We Got Here</h2>
<ul>
<li>Initial state: The system did not run on OAuth 2.0. It used a custom, dual-token flow.</li>
<li>Step 1 — Documentation pass: We first rewrote internal docs using OAuth 2.0 terminology (flows, scopes, redirect URIs, PKCE, etc.) to establish common ground.</li>
<li>Step 2 — Alignment: We then updated those docs to OAuth 2.1, adopting modern best practices (e.g., removal of implicit flow, PKCE by default).</li>
<li>Step 3 — Migration: Once the approach was clear, we kicked off the migration: BFF pattern, cookie-based sessions, moving admin modules to Next.js, and a thin adapter to keep RTK Query Codegen viable.</li>
</ul>
<hr>
<h2>Why OAuth 2.1</h2>
OAuth 2.1 consolidates scattered 2.0 best practices under a modern, opinionated baseline:
<ul>
<li>PKCE by default: Reduces token interception risk for public clients.</li>
<li>No implicit flow: Removes fragile browser token handling.</li>
<li>Standardized hygiene: Short-lived access tokens, refresh-token rotation, and scope discipline are treated as table stakes.</li>
<li>Clarity &gt; ambiguity: Fewer edge cases to interpret—especially helpful for multi-tenant boundaries.</li>
</ul>
<blockquote>
TL;DR: 2.1 turns many “optional but required in practice” 2.0 patterns into defaults, reducing attack surface and cognitive load.
</blockquote>
<hr>
<h2>Architectural Decision: BFF Is a Must</h2>
With OAuth 2.1, the Backend-for-Frontend (BFF) pattern became the obvious boundary:
<ul>
<li>Why: Avoid carrying access tokens in the browser; rely on HttpOnly, Secure, SameSite cookies and server-side session state to shrink XSS/CSRF exposure.</li>
<li>Impact: My Vite + React SPA templates no longer fit. I’m moving administrative surfaces to Next.js, centralizing auth/session in middleware that plays nice at the edge.</li>
</ul>
<blockquote>
BFF is not “just a proxy.” It’s a smart boundary that simplifies authorization decisions and keeps token lifecycles server-side.
</blockquote>
<hr>
<h2>Client Layer and RTK Codegen</h2>
<ul>
<li>Goal: Preserve the existing RTK Query Codegen loop.</li>
<li>Approach: Insert a thin adapter so the client speaks to BFF-exposed endpoints while Codegen remains blissfully unaware.</li>
<li>Risk: Silent breakage if the OpenAPI schema drifts. Mitigation: SemVer + automated contract tests in CI.</li>
</ul>
<hr>
<h2>Multi-Tenant Requirements (Recap)</h2>
<ol>
<li>Tenant-scoped authorization: Carry a <code>tenant_id</code> claim; resolve permissions (RBAC/ABAC) within tenant context.</li>
<li>Isolation: Track tokens, sessions, and rate limits per tenant.</li>
<li>Delegation: Provide auditable impersonation for tenant admins.</li>
<li>Self-service onboarding: Invites, domain verification, and billing hooks.</li>
<li>Observability: Central metrics for failures, flow distribution, MFA adoption, anomalies.</li>
</ol>
<hr>
<h2>Migration Plan</h2>
A. Preparation
<ul>
<li>Inventory existing env/secrets, proxies, and any 2.0-like assumptions.</li>
<li>Validate all clients and redirect URIs; enforce PKCE.</li>
<li>Turn on refresh-token rotation; shorten access-token TTLs.</li>
</ul>
B. BFF Layer
<ul>
<li>Session cookie: HttpOnly + Secure + SameSite=Lax/Strict.</li>
<li>CSRF protection: double-submit or equivalent.</li>
<li>Token exchange + session re-issue logic with robust logging.</li>
</ul>
C. Authorization
<ul>
<li>Simplify scope/permission mapping; include tenant-scoped claims.</li>
<li>Policy gates at the endpoint level (OPA/Cedar-style) or lean RBAC.</li>
</ul>
D. Client Adaptations
<ul>
<li>Move admin modules to Next.js; provide a lightweight SDK for SPA surfaces to call the BFF.</li>
<li>Keep RTK Codegen via the adapter; wire up contract tests.</li>
</ul>
E. Rollout / Gradual Cutover
<ul>
<li>Enable 2.1 flows for canary tenants first.</li>
<li>Watch error rates, mean login time, refresh success, and anomaly spikes.</li>
<li>Sunset legacy flows incrementally.</li>
</ul>
<hr>
<h2>Issues I Hit (and How I Addressed Them)</h2>
<ul>
<li>“No tokens in the browser—how do I authorize?” → Move the session to the BFF; the client talks only to session-bound endpoints.</li>
<li>“Will mixing CSR/SSR hurt?” → SSR/ISR for critical surfaces, CSR for the rest; lean on edge cache + short TTLs.</li>
<li>“Codegen keeps breaking.” → Contract tests + OpenAPI diff gates in CI.</li>
</ul>
<hr>
<h2>Personal Log: Code, Renovation, and Energy Management</h2>
The last month has been intense on code; what you’re seeing here is maybe 25% of it. I poked at Flutter, pushed auth/blog forward, and—oddly enough—spent a lot of time on home renovation. If you’re curious: <a href="https://www.instagram.com/reel/DPdo8FZjNND/" target="_blank" rel="noopener nofollow">Instagram Reels</a>.
<blockquote>
Over the last decade, I’ve invested a lot in tools (saws, drills, etc.). Still no workshop—yet. With the rains, renovation paused and I drifted back to code.
</blockquote>
Motivation fluctuates. I’ve been between jobs for a while; sometimes I over-engineer hoping the codebase will be ready if I find an investor—or maybe I’m just indulging myself. Honest developer diary stuff.
<hr>
<h2>Academic Track</h2>
I’m waiting on a decision for a journal submission. If graduation slips this term, the PhD chapter may close. A second paper was on deck—but energy is finite.
<hr>
<h2>Collaboration &amp; Work</h2>
I’m open to freelance contributions. Productization, multi-tenant architectures, Next.js BFF, OAuth 2.1 migrations, RTK Query/Codegen, and end-to-end delivery from design to deploy—if you need help, feel free to reach out.
<hr>
<h2>Short-Term Roadmap</h2>
<ul>
<li>[ ] Next.js BFF skeleton + session plumbing</li>
<li>[ ] Authorization Code with PKCE end-to-end</li>
<li>[ ] Refresh-token rotation + short TTLs</li>
<li>[ ] RTK Codegen adapter + contract tests</li>
<li>[ ] Tenant-scoped policy layer</li>
<li>[ ] Canary rollout + metrics dashboard</li>
</ul>
<hr>
<h2>Closing</h2>
“Before autumn fully sets in, I’m still a leaf in the wind.” Even so, the direction is clear: a secure, observable, product-ready identity layer. This post is a note to self—and hopefully a small guide for anyone setting off on a similar path.
P.S. This also marks my first year on daily.dev. I haven’t built much reputation there yet, but here’s to doing better over the next year. 🙂 Thanks for reading.

goker

A detailed technical account of migrating a multi-tenant authentication system from a custom dual-token flow to OAuth 2.1. Covers the rationale for adopting OAuth 2.1's modern security defaults (PKCE, no implicit flow, refresh-token rotation), implementing the Backend-for-Frontend (BFF) pattern with Next.js to keep tokens server-side, and maintaining RTK Query Codegen compatibility through adapters. Includes practical migration steps, multi-tenant requirements (tenant-scoped authorization, isolation, delegation), common pitfalls encountered, and a phased rollout strategy with canary testing.

Migrating Multi‑Tenant Auth to OAuth 2.1: Notes, Decisions, and a Pragmatic Roadmap