NEAR Auth is the Web3 onboarding layer for NEAR dApps — Google, Apple, email, and passkey sign-in backed by a real NEAR account, non-custodial via MPC. No seed phrases, no extensions, no wallet popups. One Auth0-backed identity, shared across every dApp in the NEAR ecosystem that integrates NEAR Auth.
01 What is NEAR Auth
NEAR Auth is an account-abstraction layer for NEAR, powered by Auth0. Users sign in with the credentials they already have, and the same identity resolves to the same NEAR account in every dApp that integrates NEAR Auth.
Four sign-in methods, all routed through Auth0: Google and Apple first, plus email/password and passkeys. We provision a real NEAR account in the background — no seed phrase, no extension, no wallet popup. Whatever the user already trusts, that's how they sign in.
The user's MPC-controlled NEAR account is derived deterministically from their Auth0 identity. Sign into one NEAR Auth-integrated dApp, sign into the next with the same login — same account, same balance, no re-onboarding.
Your dApp pays gas through the NEAR Auth relayer. Users authenticate with whichever Auth0 method they chose, and the action lands on NEAR mainnet wrapped as a NEP-366 meta-transaction.
02 How it works
What the user sees, and what's happening on chain. From login to confirmed transaction — without the user ever holding a key.
The user logs in with email/password, a passkey, Google, or Apple. Auth0 returns a JWT whose sub claim uniquely identifies them. Every transaction reuses this login — a fresh JWT is issued for each one, with the action embedded in the payload.
The NEAR Auth contract routes the JWT to the matching guard (Auth0, Firebase, custom issuer) for cryptographic verification. On success it builds a deterministic path — {guard_id}#{sub} — and asks NEAR's MPC network to sign for it. The nodes derive the same key for the same identity every time, and produce the signature collaboratively. No single party ever holds the full key — and the user holds no key material at all.
The MPC signature wraps the user's action as a NEP-366 DelegateAction. Your dApp's relayer pays gas, the action is bound to the JWT's payload (so it can't be re-used), and the call lands on NEAR mainnet through the relayer.
03 For developers
React SDK or vanilla JS — pick your stack. The Auth0-backed JavaScript provider handles login; the NEAR Auth relayer pays gas. You write the dApp.
FastAuthProvider.Wrap your app once. useFastAuth exposes the client for login / logout; useSigner exposes the signer for transactions and gas-free delegate actions.import { FastAuthProvider } from "@fast-auth-near/react-sdk";
import { JavascriptProvider } from "@fast-auth-near/javascript-provider";
import { Connection } from "near-api-js";
// Start on testnet (no approval needed). Switch to "mainnet" once your
// app has been whitelisted and approved Auth0 credentials issued.
const connection = new Connection({
networkId: "testnet",
provider: { type: "JsonRpcProvider", args: { url: "https://rpc.testnet.near.org" } },
});
export default function App() {
const providerConfig = {
// Auth0 tenant — Google · Apple · Email/password · Passkey live here.
provider: new JavascriptProvider({
domain: "your-tenant.auth0.com",
clientId: "YOUR_AUTH0_CLIENT_ID",
audience: "https://your-api.example.com",
}),
};
return (
<FastAuthProvider
providerConfig={providerConfig}
connection={connection}
network="testnet"
>
<Wallet />
</FastAuthProvider>
);
}04 Live network
10,963,260
↑ 0 today307,505
12,716 active in 7d390,591
across 6 relayers—
last 24h05 FAQ
If you don't see what you're looking for, the docs go deeper. Or open an issue — we read all of them.
Google, Apple, email/password, and passkeys — all routed through Auth0. Because each user's NEAR account is derived deterministically from their Auth0 `sub` claim, the same login resolves to the same account in every NEAR Auth dApp. For providers Auth0 doesn't cover, you can deploy a custom guard contract or run a custom issuer service that issues JWTs verified on chain.
NEAR Auth is NEAR-native and non-custodial via MPC. Where embedded-wallet products like Privy, Reown (formerly WalletConnect), or Web3Auth rely on proprietary infrastructure (key shards held by the provider, MPC services bound to their stack, or session-key wallets), NEAR Auth derives a real NEAR named account directly inside NEAR's MPC network from the user's Auth0-verified identity — no single party ever reconstructs the full key. Transactions are dispatched as NEP-366 meta-transactions through an open relayer your dApp configures, and the JWT guard model lets you bring your own issuer if Auth0 doesn't fit. The result: same Google/Apple/email login UX, but on NEAR rails you can audit end-to-end.
NEAR Protocol mainnet. NEAR Auth is built and operated by Peersyst as a public-good account-abstraction layer for the NEAR ecosystem. Accounts are real NEAR named accounts you can inspect on nearblocks.io.
Through Auth0 — Google, Apple, email/password, or passkey. The user's MPC-controlled NEAR account is derived deterministically from their Auth0 identity, so the same login always resolves to the same account no matter which NEAR Auth dApp they sign into.
Auth0 is the identity layer. Each NEAR Auth-integrated dApp gets its own approved Auth0 credentials (domain, clientId, audience), but the user's `sub` claim deterministically derives the same MPC-controlled NEAR account across every dApp that uses the Auth0 guard — so the same login reaches the same wallet.
User signs in. Auth0 issues a JWT. The MPC network derives the user's key from their JWT. The NEAR Auth contract routes the JWT to the matching guard (Auth0, Firebase, custom issuer) for cryptographic verification. On success it builds a deterministic path — {guard_id}#{sub} — and asks NEAR's MPC network to sign for it. The nodes derive the same key for the same identity every time, and produce the signature collaboratively. No single party ever holds the full key — and the user holds no key material at all.
No single party holds the user's signing key. The key is derived inside NEAR's MPC network from the user's Auth0-verified identity each time a signature is needed — no node ever reconstructs the full key. The gating credential is the user's Auth0 login: every transaction requires a fresh, verified JWT, and NEAR Auth cannot sign without it.
Through the NEAR Auth relayer. When your dApp calls signAndSendDelegateAction, the relayer wraps the user's signed delegate action as a NEP-366 meta-transaction, pays gas on chain, and returns the result — the user pays nothing. The relayer URL is configured per-network in the SDK. For a regular (non-delegate) transaction, the user's account pays gas directly.
Build on testnet first — no approval required, free credentials. When you're ready for production, submit your application (name, description, expected volume, use case, contact) to the NEAR Auth team. Once approved, you receive production Auth0 credentials (domain, clientId, audience) and access to the mainnet NEAR Auth contracts. Mainnet usage is whitelisted to keep the shared infrastructure healthy.
Partially. The NEAR Auth contract, the JWT Guard Router, and NEAR's MPC network are shared infrastructure deployed on mainnet (fast-auth.near, jwt.fast-auth.near, v1.signer) — you integrate with them, you don't redeploy them. You can self-host the auth side: deploy your own guard contract that implements the JwtGuard trait, or run an off-chain issuer whose JWTs are verified by CustomIssuerGuard. Both extension points are documented.
Yes. The NEAR Auth smart contracts and signing infrastructure have been audited by Halborn, an independent security firm specializing in Web3. The full security report is publicly available.