@auth/core
Authentication for the Web.
About
Authentication for the Web.
What detecting @auth/core tells you about a site
@auth/core is the framework-agnostic engine behind Auth.js, the rebranded and generalised successor to NextAuth, so finding it signals a modern authentication setup that has moved beyond the Next.js-only era toward the framework-portable Auth.js core. Its presence means the app handles login, sessions and OAuth provider flows through this shared runtime, typically via a thin framework adapter on top. It reads as a current, deliberately up-to-date auth choice and usually implies server-side session handling rather than a third-party hosted identity widget.
Why the exact @auth/core version matters
@auth/core is still pre-1.0 and evolving, so its version is genuinely significant: the provider configuration, callbacks and adapter contracts have shifted across releases during the NextAuth-to-Auth.js transition. Because this is the security-critical heart of authentication, the exact version also matters for which fixes and provider behaviours are present, making it worth dating carefully.
@auth/core in a real-world stack
When you find @auth/core in a bundle, it rarely travels alone. A framework adapter such as next-auth (v5+) or @auth/sveltekit, plus database adapters from @auth/*-adapter.
Quick facts
npm install @auth/coreCommon pairings
Packages this one expects to find in the same project. Each is also a Sourcemap Explorer detection target.
What @auth/core pulls in
@auth/core declares 5 direct dependencies — each one also rides into any bundle that ships @auth/core, so they are detection targets too. Reading them is a quick way to understand the package's real footprint .
How Sourcemap Explorer detects @auth/core
@auth/core ships as v0.41.3, published 2026-07-20 and carries 5 direct dependencies, 3 peer dependencies (nodemailer, @simplewebauthn/server, @simplewebauthn/browser), 112 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when @auth/core rides inside a deployed bundle — here is how the detection works.
We catch @auth/core from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/@auth/core/ paths inside the JavaScript sourcemap's sources[] array — that's the canonical signal. When the matching package.json is also captured in sourcesContent[], we read the exact version field — patch number included. No regex guessing, no version inference.
- 1
Confirm the site exposes sourcemaps
In DevTools Network, check the response headers of any application script for `SourceMap` or `X-SourceMap`. Failing that, fetch the script's last 4 KB and look for a `//# sourceMappingURL=` comment — that map is where the `@auth/core` paths live.
- 2
Find the package in the bundle
Open DevTools → Network → reload. Click any application script and look at its sourcemap. Inside, search `sources[]` for entries matching `node_modules/@auth/core/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/@auth/core/package.json` gives you the exact installed version.
- 3
Read the version directly from package.json
Run `jq -r '. as $m | $m.sources | to_entries[] | select(.value | endswith("node_modules/@auth/core/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.
Recent security advisories for @auth/core
The 3 most recent advisories affecting some versions of @auth/core, aggregated from OSV.dev (GitHub Advisory + CVE data). A listing here doesn't mean the version a given site ships is affected — each advisory applies to a specific version range. Sourcemap Explorer reads the exact bundled version so you can check it against these ranges.
Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers
Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
Recent versions
@auth/core README
Live mirror of the GitHub README, for reference. Updated whenever the repo's default branch changes.
Auth.js
Authentication for the Web.
Open Source. Full Stack. Own Your Data.
Auth.js is a set of open-source packages that are built on standard Web APIs for authentication in modern applications with any framework on any platform in any JS runtime.
Auth js is now part of Better Auth. We recommend new projects to start with Better Auth unless there are some very specific feature gaps (most notably stateless session management without a database).
Features
Flexible and easy to use
- Designed to work with any OAuth service, it supports 2.0+, OIDC
- Built-in support for many popular sign-in services
- Email/Passwordless authentication
- Passkeys/WebAuthn support
- Bring Your Database - or none! - stateless authentication with any backend (Active Directory, LDAP, etc.)
- Runtime-agnostic, runs anywhere! (Docker, Node.js, Serverless, etc.)
Own your data
Auth.js can be used with or without a database.
- An open-source solution that allows you to keep control of your data
- Built-in support for MySQL, MariaDB, Postgres, Microsoft SQL Server, MongoDB, SQLite, GraphQL, etc.
- Works great with databases from popular hosting providers
Secure by default
- Promotes the use of passwordless sign-in mechanisms
- Designed to be secure by default and encourage best practices for safeguarding user data
- Uses Cross-Site Request Forgery (CSRF) Tokens on POST routes (sign in, sign out)
- Default cookie policy aims for the most restrictive policy appropriate for each cookie
- When JSON Web Tokens are used, they are encrypted by default (JWE) with A256CBC-HS512
- Features tab/window syncing and session polling to support short-lived sessions
- Attempts to implement the latest guidance published by Open Web Application Security Project
Advanced configuration allows you to define your routines to handle controlling what accounts are allowed to sign in, for encoding and decoding JSON Web Tokens and to set custom cookie security policies and session properties, so you can control who can sign in and how often sessions have to be re-validated.
TypeScript
Auth.js libraries are written with type safety in mind. Check out the docs for more information.
Security
If you think you have found a vulnerability (or are not sure) in Auth.js or any of the related packages (i.e. Adapters), we ask you to read our Security Policy to reach out responsibly. Please do not open Pull Requests/Issues/Discussions before consulting with us.
Acknowledgments
Auth.js is made possible thanks to all of its contributors.
Contributing
We're open to all community contributions! If you'd like to contribute in any way, please first read our Contributing Guide.
License
ISC
FAQ
What is @auth/core used for?
Authentication for the Web.
How can I tell if a website is using @auth/core?
Open the page in Chrome with the Sourcemap Explorer extension installed and read the Stack tab. We catch `@auth/core` from two complementary signals: `node_modules/@auth/core/` paths inside the JavaScript sourcemap, and the embedded `package.json` we read for exact-version detection. Without the extension you can do the same lookup manually in DevTools — the steps are listed in the "How Sourcemap Explorer detects" section above.
How do I find out which version of @auth/core a website is running?
Read it straight from the site's JavaScript sourcemap. When a build ships source maps, the bundled `@auth/core/package.json` carries the exact `version` string — Sourcemap Explorer extracts it in one click on the Stack tab, and you can do it by hand in DevTools by opening the `.map` file and searching for `node_modules/@auth/core/package.json`. That is far more reliable than inferring the version from an asset-hash or a `?ver=` query string, which is all surface-level detectors have to go on. The current npm release is 0.41.3, but real deployments frequently run an older pinned version — which is exactly why reading the bundled number matters.
What is the latest version of @auth/core?
0.41.3, as published on the npm registry. The "Recent versions" table on this page lists the most recent 8 releases with their release dates. Sourcemap Explorer reports the version actually bundled into a site, which can lag the latest release by months on real-world deployments.
Is @auth/core actively maintained?
Very actively maintained — the last release shipped within the past three months. The last published release was 2026-07-20. Source code: https://github.com/nextauthjs/next-auth.
Does @auth/core have known security vulnerabilities?
3 recent advisories affecting some versions of @auth/core are listed in the "Recent security advisories" section above, aggregated from OSV.dev (GitHub Advisory + CVE data). Whether a particular site is exposed depends entirely on the exact version it ships — each advisory applies to a specific version range, not to the package as a whole. That is why the precise bundled version matters: Sourcemap Explorer reads the version a site actually runs, so you can check it against the affected ranges instead of assuming the latest release is what's deployed.
Where can I read more?
Project homepage: https://authjs.dev. Source code: https://github.com/nextauthjs/next-auth. Published on npm: https://www.npmjs.com/package/@auth/core. Licensed as ISC.
Keep reading on Sourcemap Explorer
Practical guides
Detected by Sourcemap Explorer
When a bundle ships sourcemaps, we read the embedded package.json for @auth/core and report the precise version (the registry's latest is v0.41.3, published 2026-07-20; the bundled copy is often older). Without sourcemaps, an import / require in the page's scripts is enough to flag it.