Protocol overview

NEAR Auth lets users sign NEAR transactions with the Web2 identities they already have — Google, Apple, email, or passkeys — while their keys stay secured by a Multi-Party Computation network. This page introduces the architecture at a glance: the three layers that make it work and what each one is responsible for. Under the hood, an on-chain contract system verifies a signed JWT, an MPC network produces the signature from distributed key shares, and optional off-chain services stitch the pieces together for your app.

---

​

The three layers

NEAR Auth is composed of three cooperating layers. Only the first two are required; the third is optional and depends on your integration.

---

​

1. Smart contracts

The smart contracts are the core of NEAR Auth. They enable the interaction between the end user and the MPC network to sign transactions or payloads securely, and they are the only component that decides whether a signature is allowed. The contract system is designed with modularity in mind. Different identity providers plug in as interchangeable guard contracts, so the same core can support Auth0 today and other providers later without changing its trust model. This design gives you:

• Flexible authentication — support for multiple identity providers through interchangeable guard contracts.
• Secure signing — JWT verification followed by MPC-based signature generation.
• Decentralized key management — through an attestation contract and the MPC network.

The main pieces are the FastAuth contract (the entry point that coordinates authentication and MPC signing), the JwtGuardRouter (which routes each verification request to the right guard), and the guards themselves. On the Auth0 happy path, the Auth0 Guard performs the actual RS256 JWT verification — checking the issuer, the audience, and that the fatxn claim matches the transaction being signed.

---

​

2. MPC network

The MPC network is a distributed system that holds key shares and produces signatures without any single party having access to the full private key. This is what makes NEAR Auth non-custodial: no server, and no NEAR Auth operator, can unilaterally sign on a user’s behalf. Signing is deterministic per identity. Each user’s key is derived at the path {guard_id}#{user_subject}, so the same login always controls the same NEAR account. The network only signs after the smart contract layer has verified the JWT, which keeps authorization and key custody cleanly separated.

---

​

3. Off-chain services optional

Everything above runs on-chain. In practice, most integrations also lean on a few off-chain services to smooth out the user experience:

• A relayer submits the signed transaction — and can sponsor gas via delegate actions, so users transact without holding NEAR.
• A custom backend can implement bespoke authentication flows when the default Auth0 path is not enough.

These services never hold keys and never bypass on-chain verification; they only orchestrate requests around the contracts and the MPC network.

---

​

How the layers fit together

At a high level, the identity provider issues a JWT that embeds the encoded transaction, the smart contracts verify that JWT on-chain, and the MPC network signs. The building blocks that recur across all three layers are the JWT (the signed proof of identity and intent) and the MPC network (the source of every signature).

---

​

Going further

The Auth0 guard is the default path. NEAR Auth’s modular guard design also supports alternative providers and self-hosted infrastructure — plugging in your own custom OIDC issuer, attestation-based key management, or a custom backend. Those variants live under Protocol → Advanced.