{"id":1093,"date":"2026-07-02T06:58:41","date_gmt":"2026-07-01T23:58:41","guid":{"rendered":"https:\/\/sumberlaba.com\/index.php\/2026\/07\/02\/the-ultimate-guide-to-how-to-use-supertokens-for-authentication-from-setup-to-production\/"},"modified":"2026-07-02T06:58:41","modified_gmt":"2026-07-01T23:58:41","slug":"the-ultimate-guide-to-how-to-use-supertokens-for-authentication-from-setup-to-production","status":"publish","type":"post","link":"https:\/\/sumberlaba.com\/index.php\/2026\/07\/02\/the-ultimate-guide-to-how-to-use-supertokens-for-authentication-from-setup-to-production\/","title":{"rendered":"The Ultimate Guide to How to Use SuperTokens for Authentication: From Setup to Production"},"content":{"rendered":"

The Ultimate Guide to How to Use SuperTokens for Authentication: From Setup to Production<\/h1>\n

Authentication remains one of the most critical and often frustrating components of modern web and mobile applications. Developers constantly battle the trade-off between building a secure, scalable authentication system themselves and relying on monolithic third-party providers that lock you into their ecosystem and often incur skyrocketing costs as your user base grows. Enter SuperTokens, an open\u2011source authentication solution that gives you complete control over your user data and authentication flow while drastically reducing development time. Unlike traditional providers, SuperTokens is built to be self\u2011hosted or used as a managed service, offering a suite of “recipes” for email\u2011password, passwordless, social login, and session management out of the box. This guide will take you through the entire journey of integrating SuperTokens into your application, from initial setup to production deployment, covering best practices, common pitfalls, and real\u2011world configuration examples. By the end, you will have a fully functional authentication system that is both secure and customizable, with the ability to extend it as your application evolves.<\/p>\n

Before diving into the step\u2011by\u2011step implementation, it\u2019s important to understand the architecture that makes SuperTokens so powerful. At its core, SuperTokens consists of three main components: the SuperTokens core service (a microservice that handles authentication logic, token generation, and persistent storage), the frontend SDK (available for React, Vanilla JS, and soon other frameworks), and the backend SDK (for Node.js, Python, Go, and others). The core service stores user data and sessions in your own database (PostgreSQL, MySQL, or SQLite), while the backend SDK integrates with your API to verify sessions and manage user roles. The frontend SDK provides pre\u2011built UI components like login\/sign\u2011up forms, but also allows fully custom UIs. This decoupled architecture means you can scale each component independently and never have to pass user data through a third\u2011party server. Now, let\ufffd\ufffd\ufffds walk through the exact steps to get SuperTokens up and running in your application.<\/p>\n

\"Article<\/p>\n

Step 1: Setting Up the SuperTokens Core Service<\/h2>\n

The first step in your integration journey is to run the SuperTokens core service. This service is the brain of your authentication system \u2013 it handles the creation, verification, and revocation of sessions, as well as the storage of user credentials and password hashes. You have two options: you can either self\u2011host the core using Docker or deploy it on a cloud VM, or you can use the SuperTokens managed service (called SuperTokens Cloud). For most production applications, self\u2011hosting gives you full control over your data and avoids any third\u2011party dependency, but the managed service is excellent for prototyping or if you don’t want to manage infrastructure. To self\u2011host with Docker, you need a Docker environment (Docker Desktop or a Linux server with Docker Engine). The official SuperTokens Docker image is `registry.supertokens.io\/supertokens\/supertokens-postgresql:latest` (if you are using PostgreSQL). Alternatively, you can use the SQLite\u2011based image for simpler setups that don’t need a separate database. Create a `docker-compose.yml` file that includes both the SuperTokens core and a PostgreSQL database container. Here is a minimal example:<\/p>\n

version: '3.8'\nservices:\n  db:\n    image: postgres:14-alpine\n    environment:\n      POSTGRES_USER: supertokens_user\n      POSTGRES_PASSWORD: somePassword\n      POSTGRES_DB: supertokens\n    ports:\n      - \"5432:5432\"\n  supertokens:\n    image: registry.supertokens.io\/supertokens\/supertokens-postgresql:latest\n    depends_on:\n      - db\n    ports:\n      - \"3567:3567\"\n    environment:\n      POSTGRES_CONNECTION_URI: \"postgresql:\/\/supertokens_user:somePassword@db:5432\/supertokens\"\n      API_KEY: \"your-api-key\"\n    restart: unless-stopped<\/code><\/pre>\n
Once you run `docker-compose up -d`, the core service will be available on `http:\/\/localhost:3567`. You can verify it’s working by hitting `http:\/\/localhost:3567\/hello`. The core service is now ready to accept connections from your backend SDK. If you prefer the managed service, simply sign up at https:\/\/supertokens.com, create a new project, and you\u2019ll receive a connection URI and an API key. For the purpose of this tutorial, we\u2019ll assume you are self\u2011hosting, but the backend SDK configuration is nearly identical regardless of deployment method. Note that the core service does not store user data itself \u2013 it uses your own database. This is a huge privacy and security win because your users\u2019 passwords and personal details never leave your infrastructure. The core service also handles rate limiting, brute\u2011force protection, and automatically rotates refresh tokens to keep sessions secure.<\/p>\n
Step 2: Integrating the Backend SDK (Node.js Example)<\/h2>\n
With the core service running, your next task is to install and configure the SuperTokens backend SDK for your server. In this tutorial, we\u2019ll use Node.js with Express, but the concepts apply directly to Python (Flask\/Django), Go, and other supported languages. Start by installing the SuperTokens Node.js SDK and the appropriate recipe SDK for the authentication method you want. For email\u2011password login, you\u2019ll need the `supertokens-node` package and the `supertokens-node\/recipe\/emailpassword`:<\/p>\n
npm install supertokens-node express cors<\/code><\/pre>\n
Now, create a file, say `app.js`, and initialise SuperTokens with the configuration pointing to your core service. You\u2019ll need to provide the connection URI (e.g., `http:\/\/localhost:3567`), your API key (if you set one), and the appName (any string that identifies your app). Here\u2019s a minimal initialisation snippet for email\u2011password authentication with session management:<\/p>\n
const supertokens = require(\"supertokens-node\");\nconst Session = require(\"supertokens-node\/recipe\/session\");\nconst EmailPassword = require(\"supertokens-node\/recipe\/emailpassword\");\n\nsupertokens.init({\n  framework: \"express\",\n  supertokens: {\n    connectionURI: \"http:\/\/localhost:3567\",\n    apiKey: \"your-api-key\",\n  },\n  appInfo: {\n    appName: \"MyApp\",\n    apiDomain: \"http:\/\/localhost:3001\",\n    websiteDomain: \"http:\/\/localhost:3000\",\n    apiBasePath: \"\/auth\",\n    websiteBasePath: \"\/auth\",\n  },\n  recipeList: [\n    EmailPassword.init(),\n    Session.init(),\n  ],\n});<\/code><\/pre>\n
The `appInfo` object is crucial because SuperTokens uses these domains to verify the origin of requests and to set secure cookie domains. The `apiBasePath` and `websiteBasePath` define where your backend authentication endpoints will be mounted (e.g., `\/auth\/signup`, `\/auth\/signin`). After initialisation, you need to add SuperTokens middleware to your Express app. This middleware handles the POST requests to the authentication endpoints automatically, so you don\u2019t have to write your own signup\/login logic. Simply add:<\/p>\n
const express = require(\"express\");\nconst { middleware } = require(\"supertokens-node\/framework\/express\");\n\nconst app = express();\napp.use(express.json());\napp.use(middleware());\n\n\/\/ Your other routes here...\napp.listen(3001);<\/code><\/pre>\n
Your backend is now ready to accept authentication requests. The `middleware` function will respond to any request whose path starts with `\/auth` and handle signup, signin, signout, session refresh, and email verification endpoints automatically. To verify that a session is valid on a protected API route, you can use the `verifySession` middleware provided by the Session recipe. For example:<\/p>\n
const { verifySession } = require(\"supertokens-node\/recipe\/session\/framework\/express\");\n\napp.get(\"\/dashboard\", verifySession(), (req, res) => {\n  let userId = req.session.getUserId();\n  res.json({ message: \"Welcome!\", userId });\n});<\/code><\/pre>\n
This will automatically check the session tokens in the cookies or headers and return a 401 if the session is invalid or expired. The session refresh is also handled transparently by the frontend SDK, so you don\u2019t need to worry about token rotation on your own.<\/p>\n
Step 3: Configuring the Frontend SDK (React Example)<\/h2>\n
With your backend ready, it\u2019s time to connect your frontend application. SuperTokens provides frontend SDKs for Vanilla JS and React that offer both pre\u2011built UI components and hooks for custom UIs. We\u2019ll use React for this example. First, install the necessary packages:<\/p>\n
npm install supertokens-auth-react react-dom react-router-dom<\/code><\/pre>\n
Then, initialise the frontend SDK in your main `App.js` or a dedicated `Supertokens.js` file. The configuration must match your backend\u2019s `appInfo` \u2013 same `apiDomain`, `websiteDomain`, and `apiBasePath`. Here\u2019s an initialisation with the email\u2011password recipe and the pre\u2011built UI:<\/p>\n
import SuperTokens from \"supertokens-auth-react\";\nimport EmailPassword from \"supertokens-auth-react\/recipe\/emailpassword\";\nimport Session from \"supertokens-auth-react\/recipe\/session\";\n\nSuperTokens.init({\n  appInfo: {\n    appName: \"MyApp\",\n    websiteDomain: \"http:\/\/localhost:3000\",\n    apiDomain: \"http:\/\/localhost:3001\",\n    apiBasePath: \"\/auth\",\n    websiteBasePath: \"\/auth\",\n  },\n  recipeList: [\n    EmailPassword.init(),\n    Session.init(),\n  ],\n});<\/code><\/pre>\n
Now, wrap your application with the SuperTokens component and use the pre\u2011built routes. For example, in your routing setup:<\/p>\n
import { SuperTokensWrapper } from \"supertokens-auth-react\";\nimport { Routes, Route } from \"react-router-dom\";\n\nfunction App() {\n  return (\n    \n      \n        } \/>\n        } \/>\n      <\/Routes>\n    <\/SuperTokensWrapper>\n  );\n}<\/code><\/pre>\n
The `` component (imported from the recipe) renders the sign\u2011up, sign\u2011in, and reset password forms automatically. You can also customise the UI by passing props like `signInForm` and `signUpForm` with your own components. If you prefer a headless approach, you can use the `useSessionContext` hook to get the session status and manually render forms. The frontend SDK also handles session refresh in the background \u2013 it intercepts API responses and automatically refreshes the session before retrying the request, so your users never see a login prompt until they explicitly sign out or their session expires.<\/p>\n
Step 4: Implementing Social Login (Google, GitHub, etc.)<\/h2>\n
SuperTokens supports social login via its ThirdParty recipe. This recipe works in conjunction with the ThirdPartyEmailPassword recipe if you want to offer both email\u2011password and social login in the same flow. To add Google login, for example, you first need to create OAuth 2.0 credentials in the Google Cloud Console. Enable the “Google+ API” (or the newer OAuth consent screen), create an OAuth 2.0 Client ID for a web application, and add the redirect URI to match `http:\/\/localhost:3000\/auth\/callback\/google` (adjust based on your websiteDomain and basePath). Then, install the ThirdPartyEmailPassword recipe on both backend and frontend. On the backend, modify your recipe list:<\/p>\n
const ThirdPartyEmailPassword = require(\"supertokens-node\/recipe\/thirdpartyemailpassword\");\n\nrecipeList: [\n  ThirdPartyEmailPassword.init({\n    providers: [\n      {\n        config: {\n          thirdPartyId: \"google\",\n          clients: [{\n            clientId: \"YOUR_GOOGLE_CLIENT_ID\",\n            clientSecret: \"YOUR_GOOGLE_CLIENT_SECRET\",\n          }],\n        },\n      },\n    ],\n  }),\n  Session.init(),\n],<\/code><\/pre>\n
On the frontend, update the recipe list to use ThirdPartyEmailPassword instead of EmailPassword:<\/p>\n
import ThirdPartyEmailPassword from \"supertokens-auth-react\/recipe\/thirdpartyemailpassword\";\n\nrecipeList: [\n  ThirdPartyEmailPassword.init(),\n  Session.init(),\n],<\/code><\/pre>\n
The pre\u2011built UI will automatically add “Sign in with Google” buttons. You can also add GitHub, Facebook, or any custom OAuth provider by following the same pattern. The SuperTokens core handles the OAuth callback and links the social account to a local user record if it\u2019s the first sign\u2011in. If a user signs up with email first and later wants to link a social account, you can implement account linking manually using the UserMetadata recipe. For most applications, the simple social login setup is sufficient and greatly reduces friction for new users.<\/p>\n
Step 5: Managing Sessions and User Roles<\/h2>\n
Once your users are authenticated, you\u2019ll likely need to manage session lifetimes, role\u2011based access control (RBAC), and user metadata. SuperTokens provides built\u2011in session management that handles access tokens (short\u2011lived, typically a few minutes) and refresh tokens (long\u2011lived, configurable up to several days). By default, the access token expires in 1 hour and the refresh token in 24 hours, but you can change these values in the `Session.init` configuration:<\/p>\n
Session.init({\n  sessionExpiredStatusCode: 401,\n  cookieSameSite: \"lax\",\n  exposeAccessTokenToFrontendInCookieBasedAuth: false,\n  antiCsrf: \"VIA_TOKEN\",\n  sessionTokenBackend: \"viaCookie\",\n  refreshTokenValidity: 60 * 24 * 7, \/\/ 7 days in minutes\n  accessTokenValidity: 30, \/\/ 30 minutes\n})<\/code><\/pre>\n
For RBAC, you can leverage JWT payload claims. The session recipe allows you to add custom claims to the access token. For example, you can add a `role` claim during signup or update it via an API endpoint. In your backend SDK, after verifying the session, you can access these claims:<\/p>\n
let session = req.session;\nlet role = session.getAccessTokenPayload().role;<\/code><\/pre>\n
You can also use the UserMetadata recipe to store arbitrary JSON data per user (like preferences, profile information, etc.). Install the UserMetadata recipe on both sides and then use `super.setUserMetadata(userId, metadata)` on the backend. This is great for storing non\u2011sensitive data without creating your own user table. However, for critical role data, it\u2019s better to keep it as a session claim or in your own database. SuperTokens also supports email verification and password reset out of the box \u2013 the email password recipe includes flows for sending verification emails and resetting passwords. You just need to provide your email sending configuration (SMTP settings or use a service like SendGrid) either in the core configuration or via a custom email password reset using the backend SDK\u2019s `sendEmail` callback.<\/p>\n
Tips and Best Practices for SuperTokens Authentication<\/h2>\n
1. Always Use HTTPS in Production<\/h3>\n
While this might seem obvious, it\u2019s worth emphasising: SuperTokens relies on cookies to store session tokens. In production, you must serve your website and API over HTTPS to prevent session hijacking via network sniffing. Additionally, set the `cookieSecure: true` property in your session configuration. When developing locally, you can leave it as `false` because your localhost is not served over HTTPS. If you use the `cookieSameSite` attribute, set it to `”lax”` or `”strict”` to mitigate CSRF attacks. For added security, SuperTokens includes an anti\u2011CSRF token mechanism that you can enable by setting `antiCsrf: “VIA_TOKEN”`. This adds a custom header to API requests that must match a value stored in the session. The frontend SDK does this automatically, so you just need to enable it in the configuration.<\/p>\n
2. Use the Pre\u2011built UI for Rapid Prototyping, but Customise for Production<\/h3>\n
The pre\u2011built SuperTokens UI is great for getting a working authentication screen in minutes, but it uses generic styling that might clash with your brand. For a production application, you should either override the CSS by providing a custom styles object or build a completely custom UI using the hooks like `useSessionContext` and `useAuthRecipe`. The custom UI approach gives you full control over the form fields, error messages, and layout. SuperTokens provides several hooks \u2013 for example, `useAuth` from the recipe returns functions like `signUp`, `signIn`, `signOut`, and `getAuthState`. This allows you to build your own pages while still leveraging SuperTokens\u2019 session management and token handling. Avoid exposing raw credentials in client\u2011side logs, and never store the session tokens in localStorage (SuperTokens uses httpOnly cookies by default, which is the safest option).<\/p>\n
3. Plan for Scaling Your Authentication Infrastructure<\/h3>\n
SuperTokens is designed to scale horizontally. The core service is stateless with respect to the authentication logic, but it does rely on your database. As your user base grows, ensure your database can handle the load. You can run multiple instances of the SuperTokens core behind a load balancer, as long as they all point to the same database. The core service also caches some data, but for high\u2011throughput applications, consider using a dedicated PostgreSQL or MySQL instance with connection pooling (e.g., PgBouncer). Additionally, you can tune the core\u2019s memory and CPU limits in your Docker configuration. If you choose the managed service, scaling is handled for you, but you lose some fine\u2011grained control. For startups, starting with the free tier of the managed service is reasonable, but once you hit thousands of users, self\u2011hosting becomes more cost\u2011effective.<\/p>\n
4. Implement Rate Limiting and Brute\u2011Force Protection<\/h3>\n
SuperTokens core includes built\u2011in rate limiting for login attempts. By default, after 5 failed sign\u2011in attempts within 5 minutes, the user\u2019s account is temporarily locked out. You can configure these thresholds in the core\u2019s configuration file. If you are self\u2011hosting, you can also add custom rate limiting at the reverse proxy level (e.g., Nginx or Cloudflare) to protect against DDoS attacks on your authentication endpoints. Additionally, use strong password policies \u2013 the email password recipe allows you to validate password strength via a custom `validatePassword` function. For example, you can enforce a minimum length, require special characters, or check against common password lists. This adds an extra layer of security beyond what SuperTokens provides out of the box.<\/p>\n
5. Monitor Your Authentication Flows<\/h3>\n
Once your application is live, you need visibility into how users are authenticating. SuperTokens exposes metrics via its `\/metrics` endpoint (if enabled) that shows counts of sign\u2011ups, sign\u2011ins, session refreshes, and errors. You can integrate this with Prometheus or send logs to your monitoring system. Also, implement logging of failed authentication attempts and session revocations. If you suspect a security incident, you can use the SuperTokens API to invalidate all sessions for a specific user or even all users via the `revokeAllSessionsForUser` function. This is critical for responding to credential leaks. Finally, set up alerts for unusual patterns, such as a sudden spike in sign\u2011ups or many failed logins from a single IP range, which might indicate an automated attack.<\/p>\n
Frequently Asked Questions (FAQ)<\/h2>\n
Q1: Can I use SuperTokens with a non\u2011Node.js backend?<\/h3>\n
Absolutely! SuperTokens provides official backend SDKs for Node.js, Python (with Flask and Django), Go, and Java. The framework\u2011specific middleware might differ slightly, but the core concepts are identical. For example, in Python with Flask, you would install `supertokens-python` and initialise it with `super.init()` and then add the `super.middleware()` to your app. The session verification is done with a decorator. The community is also working on SDKs for Ruby and PHP. All backend SDKs communicate with the same core service, so you can mix languages in a microservice architecture \u2013 just ensure the `appInfo` is consistent across all services.<\/p>\n
Q2: How do I migrate my existing user database to SuperTokens?<\/h3>\n
SuperTokens allows you to import users into its core database using the User Metadata recipe and the core API. For password\u2011based users, you\u2019ll need to import their password hashes. SuperTokens supports bcrypt, argon2, and SHA\u2011256 (with a salt). You can write a script that reads your existing user table and inserts records via the SuperTokens core\u2019s `\/recipe\/signup` endpoint (but you must set the password as a pre\u2011hashed value). However, be aware that the password hash algorithm must match SuperTokens\u2019 configuration. If your existing hashes are incompatible, you may need to force users to reset their passwords on first login. A safer approach is to integrate SuperTokens and your existing auth system side\u2011by\u2011side during a transition period, then gradually migrate users. SuperTokens also supports a “passwordless” migration where users login via email magic links and then set a password later \u2013 this avoids the hash compatibility problem entirely. For detailed guidance, refer to the official SuperTokens migration documentation.<\/p>\n
Q3: Does SuperTokens support multi\u2011factor authentication (MFA)?<\/h3>\n
As of the latest version, SuperTokens does not yet have an official MFA recipe, but it is on the roadmap. However, you can implement MFA yourself by using the session claims and a custom recipe. For example, you could add a TOTP (Time\u2011based One\u2011Time Password) flow after initial email\u2011password authentication. You would store the MFA secret in User Metadata and use a library like `otplib` on the backend. The session token could then have a claim `mfaVerified: false` until the user completes the second factor. Many developers have built such integrations and shared their patterns in the SuperTokens forum. Alternatively, you could delegate MFA to an external service like Auth0 or Twilio, but that partially defeats the purpose of using an open\u2011source solution. For now, if MFA is a strict requirement, evaluate whether SuperTokens fits your timeline or if you need a partner solution.<\/p>\n
Q4: What databases does SuperTokens support?<\/h3>\n
The SuperTokens core supports PostgreSQL, MySQL, and SQLite (for development\/testing only). In production, you should use PostgreSQL or MySQL because SQLite does not handle concurrent writes well. The core automatically creates the necessary tables (like `users`, `user_info`, `session_info`, `password_reset_tokens`, etc.) when it starts up. You can also pre\u2011populate these tables if you have a specific schema migration strategy. The core does not require any external database migration tools; it manages its own schema. If you switch databases later, you would need to export and import the data, but the schema is well\u2011documented in the SuperTokens GitHub repository.<\/p>\n
Q5: How do I customise the email templates for verification and password reset?<\/h3>\n
SuperTokens sends emails (for email verification and password reset) via the core service. You can customise the email content by providing a `config.yaml` file when running the core Docker container. In this file, you can set the email HTML template, the subject line, and the sender name. For example, you can overwrite the default template with your brand\u2019s HTML and CSS. If you are using an external email sending service (like SendGrid, Mailgun, or SES), you need to configure SMTP credentials in the core configuration. The core does not require you to have an email server; it uses SMTP to send emails on your behalf. If you prefer to handle email sending yourself (e.g., to use a transactional email service with dynamic templates), you can disable the core\u2019s email feature and handle the email sending in your backend code by listening to the `emailverify` and `passwordreset` callbacks in the backend SDK. The callback is triggered when a user requests verification or reset, and you can then use your own email service to send the link.<\/p>\n
Q6: Is SuperTokens free for commercial use?<\/h3>\n
Yes, SuperTokens is completely open source under the Apache 2.0 license, which means you can use it for any commercial application without paying any licensing fees. The managed cloud service (SuperTokens Cloud) has a free tier that is suitable for small projects, and paid tiers for larger workloads. If you self\u2011host, there are no usage limits \u2013 you are only limited by your own infrastructure. This is a huge advantage over many competitors that charge per active user or per monthly authentication request. The only potential cost is if you need commercial support or enterprise features (like single sign\u2011on or advanced audit logs), which SuperTokens offers as paid add\u2011ons. But for the vast majority of applications, the free, self\u2011hosted version is fully capable.<\/p>\n
Conclusion<\/h2>\n
Integrating SuperTokens for authentication may initially seem like an additional setup step compared to simpler third\u2011party login buttons, but the long\u2011term benefits are enormous. You retain full ownership of your user data, you are not locked into a vendor\u2011specific API, and you can customise every aspect of the authentication flow \u2013 from the UI to the session lifetime to the password hashing algorithm. In this guide, we have covered the entire lifecycle: setting up the core service, integrating the backend and frontend SDKs, adding social login, managing sessions and roles, and following best practices for security and scalability. By now, you should have a working authentication system that handles sign\u2011ups, logins, session refresh, and user verification. The next steps would be to add passwordless login (if that fits your use case), implement role\u2011based access control, and set up monitoring. SuperTokens is continuously evolving \u2013 its community is active, and the development team regularly releases new recipes and improvements. Whether you are building a side project or a large\u2011scale SaaS, SuperTokens provides a solid, maintainable foundation for authentication that grows with your application. Start with the simple email\u2011password flow, then iterate. Your users will appreciate the seamless experience, and you will appreciate the peace of mind that comes with a secure, self\u2011hosted auth system.<\/p>\n\n\n\n\n\n\n\n\n\n
Comparison of Authentication Approaches<\/caption>\n
Feature<\/th>\nSuperTokens (Self\u2011Hosted)<\/th>\nFirebase Authentication<\/th>\nAuth0<\/th>\n<\/tr>\n<\/thead>\n
Data Ownership<\/td>\nFull \u2013 data stays in your database<\/td>\nShared with Google<\/td>\nShared with Auth0<\/td>\n<\/tr>\n
Pricing Model<\/td>\nFree (Apache 2.0) + infrastructure costs<\/td>\nFree tier, then per active user<\/td>\nFree tier up to 7,000 users, then expensive<\/td>\n<\/tr>\n
Session Management<\/td>\nHighly configurable (access\/refresh tokens, cookies, custom JWT claims)<\/td>\nLimited to Firebase SDK<\/td>\nCustomisable but complex<\/td>\n<\/tr>\n
Supported Auth Methods<\/td>\nEmail\u2011Password, Passwordless, OAuth, Social<\/td>\nEmail\u2011Password, OAuth, Phone<\/td>\nMany, including MFA<\/td>\n<\/tr>\n
Open Source<\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n\n\n
Common SuperTokens Configuration Parameters<\/caption>\n
Parameter<\/th>\nLocation<\/th>\nDescription<\/th>\nDefault Value<\/th>\n<\/tr>\n<\/thead>\n
connectionURI<\/code><\/td>\nBackend SDK supertokens<\/code> config<\/td>\nURI of the SuperTokens core service<\/td>\nhttp:\/\/localhost:3567<\/td>\n<\/tr>\n
apiKey<\/code><\/td>\nBackend SDK supertokens<\/code> config<\/td>\nAPI key defined in core config for security<\/td>\nEmpty (not required by default)<\/td>\n<\/tr>\n
accessTokenValidity<\/code><\/td>\nSession.init()<\/code><\/td>\nHow long an access token is valid (in minutes)<\/td>\n60<\/td>\n<\/tr>\n
refreshTokenValidity<\/code><\/td>\nSession.init()<\/code><\/td>\nHow long a refresh token is valid (in minutes)<\/td>\n1440 (24 hours)<\/td>\n<\/tr>\n
cookieSameSite<\/code><\/td>\nSession.init()<\/code><\/td>\nSameSite attribute for session cookies<\/td>\nlax<\/td>\n<\/tr>\n
antiCsrf<\/code><\/td>\nSession.init()<\/code><\/td>\nCSRF protection mechanism (NONE<\/code> or VIA_TOKEN<\/code>)<\/td>\nNONE<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"
The Ultimate Guide to How to Use SuperTokens for Authentication: From Setup to Production Authentication remains one of the most critical and often frustrating components of modern web and mobile applications. Developers constantly battle the trade-off between building a secure, scalable authentication system themselves and relying on monolithic third-party providers that lock you into their … <\/p>\n","protected":false},"author":2716,"featured_media":1092,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1093","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-category"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1093","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/users\/2716"}],"replies":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/comments?post=1093"}],"version-history":[{"count":1,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1093\/revisions"}],"predecessor-version":[{"id":1094,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1093\/revisions\/1094"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/media\/1092"}],"wp:attachment":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/media?parent=1093"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/categories?post=1093"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/tags?post=1093"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}