Skip to main content
The React SDK is the fastest way to add NEAR Auth to a React app. It ships a single <FastAuthProvider> that wires up a relayer-backed FastAuthClient, plus a set of hooks (useFastAuth, useSigner, useIsLoggedIn, usePublicKey) that manage loading and error state for you. Under the hood the client and signer delegate to an auth provider — JavascriptProvider on web, ReactNativeProvider on mobile — for the Auth0 login and signature flow.
This SDK re-exports the framework-agnostic core (FastAuthClient, FastAuthSigner, FastAuthSignature) documented in the Browser SDK. The React variants add automatic per-network contract configuration and relayer support, so you rarely touch the classes directly — the hooks do it for you.

Installation

The SDK requires React 19 and near-api-js as peer dependencies. Install it alongside near-api-js and the auth provider for your platform.
Then add the web auth provider (@fast-auth-near/javascript-provider) or the mobile one (@fast-auth-near/react-native-provider) depending on your target. See Choose your SDK if you are unsure which one fits your stack.

<FastAuthProvider>

Wrap your app once, near the root. The provider constructs a FastAuthClient from your auth provider, NEAR connection, and target network, then exposes it to the tree via context. Every hook in this SDK must be rendered inside it.
App.tsx

Props

providerConfig

Some providers ship their own React context. reactProvider lets you mount it without leaving FastAuthProvider. On React Native, wrap the tree in Auth0Provider so ReactNativeProvider can reach the native SDK:
App.tsx

Network defaults

The network prop is the single source of truth for which contracts NEAR Auth talks to. You never wire contract ids by hand in the React SDK.
Make sure network matches the network you passed to your auth provider and the networkId of your Connection. Mixing testnet and mainnet across the three will produce signatures against the wrong contracts.

Hooks

All hooks read from FastAuthProvider’s context, so they only work inside the provider. Each data hook (useSigner, useIsLoggedIn, usePublicKey) follows the same shape: it returns the resolved value plus isLoading, error, and a refetch function, and by default fetches automatically once the client is ready. Pass false to the auto-fetch flag to fetch manually via refetch.

useFastAuth

The root hook. It returns the client and a ready flag; every other hook is built on top of it. Throws if rendered outside a FastAuthProvider.

useIsLoggedIn

Checks the current authentication status through the client’s provider, tracking loading and error state.
On web, isLoggedIn() also processes the Auth0 callback parameters when the user is redirected back to your app. Call refetch after a redirect completes so the UI reflects the freshly established session.

useSigner

Resolves a relayer-backed FastAuthSigner from the client. The signer requires an authenticated user — the client throws USER_NOT_LOGGED_IN otherwise, which surfaces as error.

usePublicKey

Derives the user’s NEAR public key from the signer for the requested algorithm. It composes useSigner, so it becomes available as soon as a signer is ready.
Call the hook once per algorithm — the keys are independent, so each identity has both an ed25519 and a secp256k1 public key.

Client & signer

The hooks hand you a FastAuthClient and a FastAuthSigner. Both share their surface with the Browser SDK classes, but the React variants are pre-wired: the client resolves contract ids from network, and the signer is created with relayer support so it can submit transactions on the user’s behalf.

FastAuthClient

Access it from useFastAuth. It orchestrates login state and produces the signer.

FastAuthSigner

Access it from useSigner. In the React SDK the signer is relayer-backed, which unlocks two high-level, one-call methods that request the signature, relay it, and submit the result to NEAR for you. Submitting a delegate action requires a relayer to sponsor gas — see NEAR’s meta-transactions guide for how relayers work. signAndSendTransaction accepts the transaction plus an optional algorithm; its remaining fields are forwarded to the provider’s signature request. The MPC algorithm defaults to "eddsa".
Prefer signAndSendDelegateAction when you want users to transact without holding NEAR — the relayer covers gas. Use signAndSendTransaction when the user’s account pays its own gas. See Sign transactions for the end-to-end pattern.

Next steps

Authenticate users

Wire up login, logout, and session handling with the hooks.

Sign transactions

Request signatures and relay transactions, gasless or not.

Browser SDK

The framework-agnostic FastAuthClient and FastAuthSigner.

JavaScript provider

The Auth0 web provider you pass to providerConfig.