Authmap

See your Next.js auth flow at a glance — and catch the bugs that hide in it.

Authmap is a VS Code extension that maps out how authentication actually works across your Next.js app: which routes are protected, which are public, which are ambiguous, and where your middleware might be lying to you. It starts with first-class support for Better Auth.

The problem

In a Next.js app, "is this route protected?" is a question whose answer is scattered across three different files that never talk to each other:

• middleware.ts (or proxy.ts on newer Next.js versions) — defines which routes middleware even runs on, via the matcher config
• your auth config — defines how a session is checked
• the route/page file itself — may or may not read the session on its own

Nothing cross-references these for you. So bugs like these ship quietly and get found in production:

• 🔁 A matcher accidentally covers your login page too → infinite redirect loop
• 🕳️ A route reads the session, assuming it's protected — but no matcher actually covers it → silently public
• 🐢 A matcher is broader than intended and fires on every asset request → middleware runs on every .js chunk and favicon
• 🧩 Session/cookie settings drift out of sync with what middleware assumes

Authmap reads your actual code and tells you which of these you have, before your users find them for you.

What it shows you

🗺️ Route tree, grouped by confidence

Every page, layout, and route handler in your app/ directory, tagged and grouped so the things that need your attention show up first:

• 🔒 Protected — covered by a middleware matcher and an actual session check
• 🌐 Public — no matcher coverage, no session read — intentionally open
• ⚠️ Ambiguous / Needs Review — something doesn't add up (reads session with no coverage, matcher covers it but nothing checks anything, etc.)

Click any route to jump straight to the file.

➡️ Request flow strip

A quick visual: Request → middleware.ts/proxy.ts → Session check → Render, showing matcher count and whether a session check was actually found — so you can tell at a glance whether your middleware is doing real work or just... existing.

⚠️ Inline warnings

Findings show up as real VS Code diagnostics — squiggles in your editor, entries in the Problems panel — not just a separate panel you have to remember to check. Run Authmap: Explain This Warning from the Command Palette for the full reasoning behind any finding, including how to fix it.

🔌 OAuth providers panel

Shows which social providers (Discord, Google, GitHub, etc.) are declared in your Better Auth config, so you don't have to go hunting through it to remember what's wired up.

How it works

Authmap is entirely static — it reads your source files, it doesn't run your app or your dev server. It:

1. Parses middleware.ts/proxy.ts for the matcher config, using the same pattern-matching logic Next.js itself uses under the hood — not a regex guess.
2. Parses your Better Auth config for providers and session settings.
3. Walks app/ and checks each route for session reads.
4. Cross-references all of it to classify every route and surface anything that doesn't line up.

Nothing leaves your machine — there's no network call, no telemetry, no uploading your code anywhere.

Getting started

1. Install Authmap from the Marketplace.
2. Open a Next.js project with a middleware.ts/proxy.ts and a Better Auth config.
3. Click the Authmap icon in the Activity Bar.
4. That's it — it scans automatically on open, and re-scans on save.

If nothing shows up, check that your middleware/proxy file and auth config are in one of the conventional locations (project root, src/, or lib/). Run Authmap: Rescan Project from the Command Palette any time.

Requirements

• Next.js App Router (app/ directory)
• Better Auth for session management
• TypeScript route/middleware files

Known limitations (v1)

Authmap is intentionally static-analysis-only for now — it won't catch a bug that only shows up when your app is actually running, and it can't see values that come from another file it wasn't able to resolve (e.g. providers imported from elsewhere, matchers built dynamically at runtime). It's built to catch the common, structural bugs — not to replace testing.

Support for auth libraries beyond Better Auth, and runtime-aware checks, are on the roadmap.

Feedback

Found a false positive, a bug pattern Authmap should catch but doesn't, or something that just looks wrong? Open an issue — this is early, and real usage is what makes the ruleset better.

License

MIT