repository·master·Indexed 43 days ago
https://github.com/supertokens/supertokens-auth-reactA client-side library (version 0.51.3) that enables React applications to integrate SuperTokens authentication services, providing ready-to-use login functionality and session management.
This example demonstrates how to use SuperTokens for EmailPassword and Social Login authentication in a Next.js application while integrating with Supabase to manage user-specific data.
userId.The demo application follows this structure to integrate a React frontend with a Node.js Express backend on Vercel:
src folder.api/index.js.vercel.json file is used to instruct Vercel to proxy all requests starting with /api to the backend server (api/index.js).This pattern implements a sign-in flow for CLI clients where the authentication happens in a web browser. It leverages the SuperTokens Passwordless recipe and a magic link flow.
getmagiclink GET API. The backend returns a magic link containing two tokens: preAuthSessionId and linkCode.linkCode: A one-time use, secret token consumed via the consumetoken POST API.preAuthSessionId: A non-secret token used to associate metadata (like the user's identity) with the login process.consumetoken API immediately.localStorage, redirects the user to the login flow, and then sends the tokens to the consumetoken API after successful login.consumetoken API verifies the session, then uses Passwordless.consumeCode to validate the linkCode.preAuthSessionId to the userId. In this demo, the UserMetadata recipe is used for this mapping (though a database with TTL is recommended for production)./waitforlogin API using the preAuthSessionId.This pattern allows you to verify a user's email address before they establish a permanent password.
The Workflow:
When using SuperTokens with Electron, you must account for how Electron handles cookies and the Window API. This demo implements the following patterns to ensure compatibility:
SuperTokens.init in src/renderer.tsx. The implementation logic for these handlers is located in src/cookieHandler.ts and src/windowHandler.ts.HashRouter from react-router-dom because social providers and file protocols used by Electron do not support standard browser routing.supertokens-demo) to handle Magic Link redirects. You can change this by updating deeplinkProtocol in both src/renderer.tsx and api-server/index.js.HashRouter or file protocol URLs, the app uses the apiDomain for redirect URLs. The backend (api-server/index.js) provides two specific routes to bridge this: /auth/callback/:providerId and /auth/verify, which redirect back to the app using the registered protocol.file:// protocol, magic links are modified to use the apiDomain. The /auth/verify route handles the internal redirection back to the app via the registered protocol.When using header-based authentication, you can redirect the storage of session tokens from browser cookies to localStorage by providing a custom cookieHandler during the supertokens.init configuration.
To implement this, you must create a handler that implements the functions for getting and setting cookies, but directs those operations to localStorage instead. In this pattern, tokens are typically stored under a specific key (e.g., frontendCookies) within the browser's localStorage.
// Conceptual implementation pattern
// The custom handler is passed to supertokens.init
supertokens.init({
// ... other config
cookieHandler: getCookieHandler(),
});When implementing an OTP-to-token mapping for email verification, consider the following production requirements:
Account linking allows a single user to have multiple login methods (e.g., Email/Password and Google). This demo implements two types of linking:
Enabled on the backend by initializing the recipe with a shouldDoAutomaticAccountLinking implementation. When a user logs in via a third-party provider, SuperTokens checks if the account should be automatically linked to an existing user.
For more control, you can implement manual linking via custom API endpoints. In this demo:
/link page is used to manage login methods./addPassword or /addPhoneNumber to associate new credentials with the currently logged-in user.This pattern demonstrates how to implement a custom thirdparty provider using Okta with the PKCE (Proof Key for Code Exchange) flow. It involves two main architectural requirements:
Custom Thirdparty Provider Support:
Multi-tenancy Support:
tenantId in the frontend.tenantId to backend APIs.tenantId on the backend to simulate or route to different User Pools.This demo implements a pattern where signing up (via Social or Email/Password) does not automatically log the user in, but instead prompts them to sign in again. This is achieved through two mechanisms:
API Override: The default sign-up behavior is modified using the API override feature. The custom logic is located in:
api-server/customSignInUpPOST.js (for social login)api-server/customSignUpPOST.js (for email/password login)Frontend UI Feedback: To inform the user they need to log in manually after a successful sign-up:
src/App.js, the onHandleEvent function is used to set a flag in localStorage when a sign-up event is triggered.ThirdPartyEmailPasswordHeader component. A custom component, SignInMessage (defined in src/App.js), checks the localStorage flag and displays a message to the user.This pattern allows users to associate multiple email addresses with a single account and use any of them to log in. It also ensures that the email verification flow covers all associated emails.
EmailPassword recipe functions on the backend. For any function accepting an email, look up the primary email associated with the input email in your map, then call the original SuperTokens implementation using that primary email.