# next-firebase-auth-edge: Firebase Auth that runs where Next.js actually deploys > next-firebase-auth-edge replaces the Node-only firebase-admin path with Web Crypto and jose so Firebase Authentication works in the Edge runtime, with middleware-based session cookies and no custom API routes. It suits Next.js teams on App Router and Vercel, and it commits you to a cookie session model rather than a stateless token model. **awinogrodzki/next-firebase-auth-edge** — Next.js Firebase Authentication for Edge and Node.js runtimes. Compatible with latest Next.js features. - Repository: https://github.com/awinogrodzki/next-firebase-auth-edge - Website: https://next-firebase-auth-edge-docs.vercel.app/ - Stars: 665 · Forks: 56 - Language: TypeScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/awinogrodzki-next-firebase-auth-edge ## The problem firebase-admin creates on the Edge The stated reason this library exists is specific and technical. The official firebase-admin library depends heavily on Node.js internal crypto, which is not available in the Next.js Edge Runtime. A team that wants Firebase Authentication in an App Router project, deployed to a runtime that has no Node.js crypto, hits that wall directly. The library's answer is to handle the creation and verification of Custom ID Tokens with the Web Crypto API, which works in Edge runtimes. The Web Crypto API is the Web Platform subset of cryptographic primitives that edge isolates expose, so the same code path runs in a Vercel edge function, a Cloudflare worker or a Node server without a separate implementation. That portability is the substance of the project, and everything else in it is engineering around that constraint. The audience is therefore not general Firebase users. It is Next.js developers who have already chosen Firebase Authentication, want to use the latest Next.js features, and need auth to work in the place their code actually executes. The README points at a step by step guide for people new to either Firebase or Next.js, and at a working demo whose source lives in the examples directory, so there is a path for beginners as well as for people who already have an auth setup to migrate. ## Middleware owns the session, so you do not write API routes The setup story is the second differentiator. The key features list describes minimal setup: unlike other libraries, you do not need to create your own API routes or modify your next.config.js, and everything is handled by middleware. Session handling therefore lives in one place in your application, the middleware, rather than spread across a login route, a refresh route and a logout route that each need to agree on cookie names and formats. The recent release notes show this middleware surface growing. A new enableTokenRefreshOnExpiredKidHeader option in authMiddleware refreshes user tokens when Google's public certificates expire instead of throwing an error, which is a genuine operational fix rather than a convenience, since a rotating signing certificate set is exactly the kind of thing that breaks a live app on a weekend. A privatePaths option was added to the redirectToLogin helper, so you can exempt routes from the login redirect. A Metadata feature stores custom data inside the session cookies. A removeServerCookies method handles logout from inside a Server Action, which removes the need for a dedicated logout endpoint. There is also an experimental_createAnonymousUserIfUserNotFound option that creates an anonymous user when none was found. The experimental prefix is worth noticing, since it signals an API that may change shape between minor versions. ## Session cookies, rotating keys and jose The security story is described in one line: the library uses jose for JWT validation and signs user cookies with rotating keys to prevent cryptanalysis attacks. Two things follow from that. First, JWT validation is handled by a dedicated library rather than by hand-written verification code, and jose is written in standards-first JavaScript that runs in both Node and edge runtimes, which is the same portability constraint that drove the whole design. Second, this is a stateful model. The user session lives in a cookie, which means the server has to read it on every request and the session survives independently of the Firebase ID token lifetime. That is the right trade for a Next.js app where the server renders authenticated pages, and it is the wrong trade for a mobile client or a third party API consumer that wants to present a bearer token it obtained itself. The README does not document a stateless verification path, and given the middleware-centred design it is unlikely one exists. Rotating keys are also an operational commitment rather than a one-time setting. A key that never rotates is a long-lived secret that has to be stored and protected indefinitely, and a key that rotates on a schedule requires that the previous key stays valid long enough for in-flight cookies to be verified, and that a scheduled rotation exists in your deployment. The documentation at next-firebase-auth-edge-docs.vercel.app is the place to find the exact options, and the cookie names and lifetimes are worth reading before the first deploy rather than after the first incident. ## The Firebase Emulator path removes the project setup tax Full Firebase Emulator Support is listed among the recent additions, and the project says it lets you run your development app without needing to create a Firebase Project. The starter example README is the reference for the details. For a team that wants to develop auth locally without provisioning cloud resources, this is the feature that removes the last argument against adopting the library, since the usual reason to avoid a new auth wrapper is the ceremony of setting up a real project, its credentials and its billing before you can log anyone in. The installation itself is one command, taken from the three the documentation offers: ```bash npm install next-firebase-auth-edge ``` The same package installs with yarn add next-firebase-auth-edge or pnpm add next-firebase-auth-edge. After it is in your dependencies, the wiring the feature list describes still applies: the session is handled by middleware rather than by routes you write, and the .env.dist file in the repository root is the template for the environment variables your project needs, including the emulator host the starter example uses. The repository layout supports the point. The .env.dist file at the top level is the environment template, examples/ holds both a next-typescript-minimal and a next-typescript-starter example, and the root jest.config.js, jest.setup.ts and a dedicated test tsconfig show the library is tested with Jest rather than merely type checked. The example directory is also the fastest way to read the intended architecture. The minimal example shows the smallest working shape, and the starter is the one the documentation points to for emulator setup. Between them, they are more informative than the API reference, because the API surface of an auth library is mostly obvious once you see the middleware file and the cookie options in context. ## Package shape, exports and the multi-runtime build The package manifest is published as version 1.12.1 in this state of the repository, with the files field limited to lib, browser and esm trees of JavaScript and type definitions, and sideEffects set to false. That sideEffects flag is what allows a bundler to drop unused exports, and it is consistent with the zero bundle size claim in the feature list, since the code that runs on the server does not reach the browser bundle at all. The exports map is the interesting part for anyone with an unusual deployment target. The root export maps to the browser build for bun, deno, browser, worker and workerd conditions, with separate import and require entries pointing at the esm and lib trees respectively. The same pattern repeats for the ./app-check and ./auth subpath exports, and an ./auth/error subpath is also declared. So the package is explicitly built for Deno, Bun and workerd style workers, not only for Next.js on Vercel, even though that is the primary use case. The README also lists support for ESM, Browser and Node.js imports for better tree-shaking, support for Node.js 24 and NPM 11, support for Next.js 16 and support for React 19. Multiple tsconfig files at the root, tsconfig.base.json, tsconfig.browser.json, tsconfig.esm.json, tsconfig.json and tsconfig.test.json, mirror that split. The custom token support is now optional and enabled with an enableCustomToken option, which is a change worth noting for anyone upgrading, since custom token handling used to be part of the default behaviour. The project is MIT licensed, which is the least restrictive obstacle here. The repository is not archived, and the last push was on 2026-08-06 alongside a v1.13.0-canary.1 tag, with v1.12.1 on 2026-07-31 and v1.12.0 on 2026-02-26. The canary tag in the release list suggests pre-release builds of the next minor, and the presence of a v1.12.0 to v1.12.1 to v1.13.0 line means minor version bumps can carry behaviour changes worth reading in the CHANGELOG before you upgrade a production app. ## Where this library is the wrong choice The stateless case is the clearest miss. If a native mobile client, a CLI or a third party service needs to verify a Firebase ID token on its own, it will not be carrying your session cookie, and a middleware cookie library does not help it. The official firebase-admin is the right tool there, on a Node runtime, where the crypto dependency is not a problem. The second miss is the size of the project. A Next.js app with one login form and no server rendered personalisation does not need a session middleware. Adding it means every request goes through your auth layer, and the key rotation, the cookie attributes and the token refresh behaviour all become things you own. The third is scope. This library handles custom token creation and ID token verification and session cookies. It is not a user management system, it does not send email, and it does not implement password reset flows or multi factor enrolment. Firebase Authentication still has to be configured in the console, and anything you want beyond the login session is work you do with the Firebase Admin SDK or the client SDK, which brings back the Node dependency the library was built to avoid, unless you keep that work on a separate Node route. The alternative worth comparing is a stateless design: keep the Firebase ID token on the client, verify it on the server with the Web Crypto API yourself, and let each server component decide what an unauthenticated request means. That design has no cookie, no rotation schedule and no middleware, and it is more work per request and more work in every page that needs the user. The trade is real, and it flips depending on whether your application is a server rendered session app or a token carrying API. ## Conclusion next-firebase-auth-edge is the right fit when your Next.js app runs on the Edge runtime and you want Firebase Auth without standing up your own token exchange routes. It is the wrong fit if you need stateless bearer token verification in third party clients, if you cannot accept session cookies in your auth model, or if you need Firebase Admin features beyond custom token creation and ID token verification. Before adopting it, try the Firebase Emulator support to run the whole flow without a Firebase project, confirm the middleware pattern matches your route layout, and read the cookie security settings in the documentation since the library signs user cookies with rotating keys and the rotation schedule is your operational responsibility. ## FAQ ### Why does next-firebase-auth-edge exist instead of using firebase-admin? The official firebase-admin library depends heavily on Node.js internal crypto, which is not available in the Next.js Edge Runtime. This library handles creation and verification of Custom ID Tokens with the Web Crypto API instead, so it works in edge runtimes. ### How do I install next-firebase-auth-edge? Run npm install next-firebase-auth-edge, or the yarn add or pnpm add equivalent. The package ships lib, browser and esm builds and resolves separate entry points for bun, deno, browser, worker and workerd conditions. ### Do I need to create my own API routes for auth with next-firebase-auth-edge? No. The library states that unlike other libraries you do not need to create your own API routes or modify next.config.js, because session handling is handled by middleware. ### Can I develop next-firebase-auth-edge without a Firebase project? Yes. The library fully supports the Firebase Emulator, which lets you run your development app without creating a Firebase Project, with details in the starter example README. ### What licence is next-firebase-auth-edge under? The library is MIT licensed. The repository is not archived and the last push was on 2026-08-06, with a v1.13.0-canary.1 tag published the same day and v1.12.1 on 2026-07-31. ## Sources - [awinogrodzki/next-firebase-auth-edge on GitHub](https://github.com/awinogrodzki/next-firebase-auth-edge) - [License: MIT](https://github.com/awinogrodzki/next-firebase-auth-edge/blob/main/LICENSE) - [Project website](https://next-firebase-auth-edge-docs.vercel.app/) - [README](https://github.com/awinogrodzki/next-firebase-auth-edge/blob/main/README.md) - [Releases](https://github.com/awinogrodzki/next-firebase-auth-edge/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/awinogrodzki-next-firebase-auth-edge