{ "componentChunkName": "component---src-pages-blog-markdown-remark-fields-slug-js", "path": "/blog/phishing-resistant-mfa", "result": {"data":{"markdownRemark":{"html":"

Why Traditional Multi-Factor Authentication (MFA) Is No Longer Enough

\n

Multi-factor authentication has become a standard security recommendation, but not all MFA implementations are created equal. Traditional MFA methods, despite adding a security layer beyond passwords, contain critical vulnerabilities that sophisticated attackers regularly exploit. Traditional MFA methods - SMS codes, authenticator apps with time-based one-time passwords (TOTPs), and even email verification have proven vulnerable to sophisticated phishing attacks.

\n

Why Traditional MFA Fails

\n

SIM Swapping: When Your Phone Number Betrays You

\n

This attack occurs when bad actors convince mobile carriers to transfer a victim’s phone number to a device they control. Once successful, they can intercept SMS-based verification codes meant for the legitimate user. This isn’t some obscure practice either, in 2022 CEO of Transform Ventures Michael Terpin won a $75 million lawsuit against a SIM-swapping perpetrator who stole millions in digital assets by hijacking his phone number. More information can be found on our dedicated SIM Swapping Post.

\n

Phishing For Credentials

\n

Even app-based authenticators like Google Authenticator or Authy can be compromised through well-crafted phishing campaigns. In 2023, the MGM Resorts cyberattack caused an estimated $100 million in damages despite having MFA in place. A group of bad actors used social engineering to manipulate MGM help desk employees into resetting MFA settings, granting them access to terabytes of data.

\n

Social Engineering: Exploiting the Human

\n

Human psychology remains the weakest link in security systems. The widely documented “0ktapus” campaign successfully targeted over 130 organizations, as reported by cybersecurity firm Group-IB, would target employees with convincing Okta login pages to steal credentials in real time. Victims who clicked the links and entered their credentials and MFA codes inadvertently gave attackers access to their corporate accounts, leading to significant data breaches at companies like Twilio and Cloudflare. Cloudflare’s own security incident report noted that employees using FIDO2-based hardware security keys remained protected while those using push notifications were compromised.

\n

What Makes MFA Phishing-Resistant?

\n

The core issue? These methods rely on shared secrets that can be intercepted or stolen. Phishing-resistant MFA eliminates reliance on shared secrets by leveraging asymmetric cryptography and binding authentication to specific origins (websites). This fundamentally changes the security model:

\n\n

In this guide, we’ll implement a bulletproof phishing-resistant MFA system using SuperTokens, WebAuthn, and FIDO2 standards. This approach not only strengthens security but also improves user experience by reducing friction.

\n

Why WebAuthn?

\n

Phishing remains one of the most effective attack vectors against traditional authentication. WebAuthn counters this by binding authentication directly to the user’s device through public-key cryptography. When users register with WebAuthn, their device generates a unique key pair for that service. The private key never leaves the device, while the public key is stored on the server. During authentication, the server sends a challenge only the correct private key can sign.

\n

The critical phishing protection comes from origin binding - the browser ensures authentication requests can only come from the exact domain that registered the credential. Even perfect site clones at different URLs will fail because the origins don’t match. For developers, this means implementing authentication that protects users regardless of their susceptibility to phishing attempts.

\n

How WebAuthn works

\n

WebAuthn creates a secure authentication framework built on asymmetric cryptography. Instead of storing shared secrets like passwords on servers, it employs public-private key pairs. When users register their device generates these unique keys - the private key remains secured on the device while the public key is stored on the server.The absence of passwords eliminates common vulnerabilities like credential stuffing, password spraying, and database breaches. There’s simply no password to steal, reuse, or crack, removing entire categories of attacks from consideration.

\n

User verification happens locally on the device through either biometrics (fingerprints, facial recognition) or hardware security keys. This verification proves the legitimate user is present without transmitting biometric data to the server. The local device handles all sensitive verification, then cryptographically signs the authentication challenge using the private key only after successful verification.

\n

Prerequisites – What You Need to Get Started

\n

Before diving into implementation, ensure you have:

\n\n

Let’s get started with a robust implementation that will protect your users from even the most sophisticated phishing attempts.

\n

Step 1 – Setting Up SuperTokens for Authentication

\n\n

Step 2 – Enabling WebAuthn for Passwordless, Phishing-Resistant MFA

\n

Implementation

\n

Note: Any project structure is based on the used cli command from above

\n

We’ll be using the WebAuthn Recipe, more information at the quickstart guide. First update the frontend, find the config.tsx file located in /frontend/src/config.tsx.

\n\n

You’re file should look like the following:

\n

Frontend config.tsx

\n {\n if (context.action === "SUCCESS" && context.newSessionCreated) {\n return "/dashboard";\n }\n },\n};\n\nexport const recipeDetails = {\n docsLink: "https://supertokens.com/docs/emailpassword/introduction",\n};\n\nexport const PreBuiltUIList = [\n EmailPasswordPreBuiltUI,\n WebauthnPreBuiltUI,\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n return props.children;\n};`, `53041110033076675000`)\"\n >\n \n \n \n \n
\nimport EmailPassword from \"supertokens-auth-react/recipe/emailpassword\";\nimport { EmailPasswordPreBuiltUI } from \"supertokens-auth-react/recipe/emailpassword/prebuiltui\";\nimport Session from \"supertokens-auth-react/recipe/session\";\n\nimport WebAuthn from \"supertokens-auth-react/recipe/webauthn\"; // passkeys\nimport { WebauthnPreBuiltUI } from 'supertokens-auth-react/recipe/webauthn/prebuiltui'; // passkeys\n\n\nexport function getApiDomain() {\n    const apiPort = import.meta.env.VITE_APP_API_PORT || 3001;\n    const apiUrl = import.meta.env.VITE_APP_API_URL || `http://localhost:${apiPort}`;\n    return apiUrl;\n}\n\nexport function getWebsiteDomain() {\n    const websitePort = import.meta.env.VITE_APP_WEBSITE_PORT || 3000;\n    const websiteUrl = import.meta.env.VITE_APP_WEBSITE_URL || `http://localhost:${websitePort}`;\n    return websiteUrl;\n}\n\nexport const SuperTokensConfig = {\n    appInfo: {\n        appName: \"SuperTokens Demo App\",\n        apiDomain: getApiDomain(),\n        websiteDomain: getWebsiteDomain(),\n    },\n    // recipeList contains all the modules that you want to\n    // use from SuperTokens. See the full list here: https://supertokens.com/docs/guides\n    recipeList: [\n        EmailPassword.init(),\n        WebAuthn.init(),\n        Session.init()\n    ],\n    getRedirectionURL: async (context) => {\n        if (context.action === \"SUCCESS\" && context.newSessionCreated) {\n            return \"/dashboard\";\n        }\n    },\n};\n\nexport const recipeDetails = {\n    docsLink: \"https://supertokens.com/docs/emailpassword/introduction\",\n};\n\nexport const PreBuiltUIList = [\n    EmailPasswordPreBuiltUI,\n    WebauthnPreBuiltUI,\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n    return props.children;\n};
\n

Now we’ll update the backend. Find the config.ts file located in /backend/config.ts, and Import WebAuthn from the recipe

\n\n \n \n \n \n
\nimport EmailPassword from \"supertokens-node/recipe/emailpassword\";\nimport Session from \"supertokens-node/recipe/session\";\nimport { TypeInput } from \"supertokens-node/types\";\nimport Dashboard from \"supertokens-node/recipe/dashboard\";\nimport UserRoles from \"supertokens-node/recipe/userroles\";\n\nimport WebAuthn from \"supertokens-node/recipe/webauthn\"; // enables passkeys\n\n\nexport function getApiDomain() {\n    const apiPort = process.env.VITE_APP_API_PORT || 3001;\n    const apiUrl = process.env.VITE_APP_API_URL || `http://localhost:${apiPort}`;\n    return apiUrl;\n}\n\nexport function getWebsiteDomain() {\n    const websitePort = process.env.VITE_APP_WEBSITE_PORT || 3000;\n    const websiteUrl = process.env.VITE_APP_WEBSITE_URL || `http://localhost:${websitePort}`;\n    return websiteUrl;\n}\n\nexport const SuperTokensConfig: TypeInput = {\n    framework: \"koa\",\n    supertokens: {\n        // this is the location of the SuperTokens core.\n        connectionURI: \"https://try.supertokens.com\",\n    },\n    appInfo: {\n        // learn more about this on https://supertokens.com/docs/thirdpartyemailpassword/appinfo\n        appName: \"SuperTokens Koa demo app\",\n        apiDomain: getApiDomain(),\n        websiteDomain: getWebsiteDomain(),\n    },\n    recipeList: [\n        EmailPassword.init(),\n        WebAuthn.init(),\n        Session.init(), \n        Dashboard.init(), \n        UserRoles.init()\n    ],\n};
\n

Navigate to http://localhost:3000/auth you’ll see a new option to use the passkey as an auth option

\n

Enforcing Phishing-Resistant MFA Policies

\n

To enable mfa we’ll use the MFA recipe to require multi-factor authentication, currently mfa has the support for Email/SMS One-Time Password (OTP) or Time-based One-Time Password (TOTP). Just like above we’ll be adding recipes to both the front and backend config files.

\n

Frontend adding mfa config.tsx

\n {\n if (context.action === "SUCCESS" && context.newSessionCreated) {\n return "/dashboard";\n }\n },\n};\n\nexport const recipeDetails = {\n docsLink: "https://supertokens.com/docs/emailpassword/introduction",\n};\n\nexport const PreBuiltUIList = [\n EmailPasswordPreBuiltUI,\n WebauthnPreBuiltUI,\n PasswordlessPreBuiltUI,\n MultiFactorAuthPreBuiltUI,\n TOTPPreBuiltUI\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n return props.children;\n};\n\n`, `25404164581753274000`)\"\n >\n \n \n \n \n
\nimport EmailPassword from \"supertokens-auth-react/recipe/emailpassword\";\nimport { EmailPasswordPreBuiltUI } from \"supertokens-auth-react/recipe/emailpassword/prebuiltui\";\nimport Session from \"supertokens-auth-react/recipe/session\";\n\nimport WebAuthn from \"supertokens-auth-react/recipe/webauthn\"; // passkeys\nimport { WebauthnPreBuiltUI } from 'supertokens-auth-react/recipe/webauthn/prebuiltui'; // passkeys\n\n// mfa\nimport MultiFactorAuth from \"supertokens-auth-react/recipe/multifactorauth\";\nimport { MultiFactorAuthPreBuiltUI } from \"supertokens-auth-react/recipe/multifactorauth/prebuiltui\";\nimport Passwordless from \"supertokens-auth-react/recipe/passwordless\";\nimport { PasswordlessPreBuiltUI } from \"supertokens-auth-react/recipe/passwordless/prebuiltui\";\nimport TOTP from \"supertokens-auth-react/recipe/totp\";\nimport { TOTPPreBuiltUI } from \"supertokens-auth-react/recipe/totp/prebuiltui\";\n\nexport function getApiDomain() {\n    const apiPort = import.meta.env.VITE_APP_API_PORT || 3001;\n    const apiUrl = import.meta.env.VITE_APP_API_URL || `http://localhost:${apiPort}`;\n    return apiUrl;\n}\n\nexport function getWebsiteDomain() {\n    const websitePort = import.meta.env.VITE_APP_WEBSITE_PORT || 3000;\n    const websiteUrl = import.meta.env.VITE_APP_WEBSITE_URL || `http://localhost:${websitePort}`;\n    return websiteUrl;\n}\n\nexport const SuperTokensConfig = {\n    appInfo: {\n        appName: \"SuperTokens Demo App\",\n        apiDomain: getApiDomain(),\n        websiteDomain: getWebsiteDomain(),\n    },\n    // recipeList contains all the modules that you want to\n    // use from SuperTokens. See the full list here: https://supertokens.com/docs/guides\n    recipeList: [\n        EmailPassword.init(),\n        WebAuthn.init(),\n        Passwordless.init({\n            contactMethod: \"EMAIL_OR_PHONE\",\n        }),\n        MultiFactorAuth.init({ \n            firstFactors: [\"webauthn\", \"emailpassword\"]\n        }),\n        TOTP.init(),\n        Session.init()\n    ],\n    getRedirectionURL: async (context) => {\n        if (context.action === \"SUCCESS\" && context.newSessionCreated) {\n            return \"/dashboard\";\n        }\n    },\n};\n\nexport const recipeDetails = {\n    docsLink: \"https://supertokens.com/docs/emailpassword/introduction\",\n};\n\nexport const PreBuiltUIList = [\n    EmailPasswordPreBuiltUI,\n    WebauthnPreBuiltUI,\n    PasswordlessPreBuiltUI,\n    MultiFactorAuthPreBuiltUI,\n    TOTPPreBuiltUI\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n    return props.children;\n};\n\n
\n

Backend adding mfa config.tsx

\n {\n if (session === undefined) {\n // we do not want to do first factor account linking by default. To enable that,\n // please see the automatic account linking docs in the recipe docs for your first factor.\n return {\n shouldAutomaticallyLink: false\n };\n }\n if (user === undefined || session.getUserId() === user.id) {\n // if it comes here, it means that a session exists, and we are trying to link the \n // newAccountInfo to the session user, which means it's an MFA flow, so we enable \n // linking here.\n return {\n shouldAutomaticallyLink: true,\n shouldRequireVerification: false\n }\n }\n return {\n shouldAutomaticallyLink: false\n };\n }\n }),\n MultiFactorAuth.init({\n firstFactors: ["webauthn", "emailpassword"],\n override: {\n functions: (oI) => ({\n ...oI,\n getMFARequirementsForAuth: () => [\n {\n oneOf: [\n MultiFactorAuth.FactorIds.TOTP,\n MultiFactorAuth.FactorIds.OTP_EMAIL,\n MultiFactorAuth.FactorIds.OTP_PHONE,\n ],\n },\n ],\n }),\n },\n }),\n TOTP.init(),\n Session.init(), \n Dashboard.init(), \n UserRoles.init()\n ],\n};\n\n`, `6986074075188631000`)\"\n >\n \n \n \n \n
import EmailPassword from \"supertokens-node/recipe/emailpassword\";\nimport Session from \"supertokens-node/recipe/session\";\nimport { TypeInput } from \"supertokens-node/types\";\nimport Dashboard from \"supertokens-node/recipe/dashboard\";\nimport UserRoles from \"supertokens-node/recipe/userroles\";\n\nimport WebAuthn from \"supertokens-node/recipe/webauthn\"; // enables passkeys\n\n// mfa imports\nimport AccountLinking from \"supertokens-node/recipe/accountlinking\";\nimport MultiFactorAuth from \"supertokens-node/recipe/multifactorauth\";\nimport TOTP from \"supertokens-node/recipe/totp\";\nimport Passwordless from \"supertokens-node/recipe/passwordless\";\n\nexport function getApiDomain() {\n    const apiPort = process.env.VITE_APP_API_PORT || 3001;\n    const apiUrl = process.env.VITE_APP_API_URL || `http://localhost:${apiPort}`;\n    return apiUrl;\n}\n\nexport function getWebsiteDomain() {\n    const websitePort = process.env.VITE_APP_WEBSITE_PORT || 3000;\n    const websiteUrl = process.env.VITE_APP_WEBSITE_URL || `http://localhost:${websitePort}`;\n    return websiteUrl;\n}\n\nexport const SuperTokensConfig: TypeInput = {\n    framework: \"koa\",\n    supertokens: {\n        // this is the location of the SuperTokens core.\n        connectionURI: \"https://try.supertokens.com\",\n    },\n    appInfo: {\n        // learn more about this on https://supertokens.com/docs/thirdpartyemailpassword/appinfo\n        appName: \"SuperTokens Koa demo app\",\n        apiDomain: getApiDomain(),\n        websiteDomain: getWebsiteDomain(),\n    },\n    recipeList: [\n        EmailPassword.init(),\n        WebAuthn.init(),\n        Passwordless.init({\n            contactMethod: \"EMAIL_OR_PHONE\",\n            flowType: \"USER_INPUT_CODE_AND_MAGIC_LINK\",\n        }),\n        AccountLinking.init({\n            shouldDoAutomaticAccountLinking: async (newAccountInfo: AccountInfoWithRecipeId & { recipeUserId?: RecipeUserId }, user: User | undefined, session: SessionContainerInterface | undefined, tenantId: string, userContext: UserContext) => {\n                if (session === undefined) {\n                    // we do not want to do first factor account linking by default. To enable that,\n                    // please see the automatic account linking docs in the recipe docs for your first factor.\n                    return {\n                        shouldAutomaticallyLink: false\n                    };\n                }\n                if (user === undefined || session.getUserId() === user.id) {\n                    // if it comes here, it means that a session exists, and we are trying to link the \n                    // newAccountInfo to the session user, which means it's an MFA flow, so we enable \n                    // linking here.\n                    return {\n                        shouldAutomaticallyLink: true,\n                        shouldRequireVerification: false\n                    }\n                }\n                return {\n                    shouldAutomaticallyLink: false\n                };\n            }\n        }),\n        MultiFactorAuth.init({\n            firstFactors: [\"webauthn\", \"emailpassword\"],\n            override: {\n                functions: (oI) => ({\n                    ...oI,\n                    getMFARequirementsForAuth: () => [\n                        {\n                            oneOf: [\n                                MultiFactorAuth.FactorIds.TOTP,\n                                MultiFactorAuth.FactorIds.OTP_EMAIL,\n                                MultiFactorAuth.FactorIds.OTP_PHONE,\n                            ],\n                        },\n                    ],\n                }),\n            },\n        }),\n        TOTP.init(),\n        Session.init(), \n        Dashboard.init(), \n        UserRoles.init()\n    ],\n};\n\n
\n

Testing Your MFA Implementation

\n

Unit Tests

\n

Let’s add some unit tests to test the flow - Sign up, Session verification, Refreshing session tokens, and Logout. Create a test directory in the backend /backend/__tests__

\n

Backend auth-flow.test.ts

\n ({\n init: jest.fn(),\n}));\n\njest.mock('supertokens-node/recipe/emailpassword', () => ({\n signUp: jest.fn(),\n signIn: jest.fn(),\n}));\n\njest.mock('supertokens-node/recipe/session', () => ({\n createNewSession: jest.fn(),\n getSession: jest.fn(),\n revokeAllSessionsForUser: jest.fn(),\n}));\n\ndescribe('Authentication Flow Tests', () => {\n // Comprehensive mock user data\n const mockUser: User = {\n id: 'test_st',\n emails: ['test@example.com'],\n timeJoined: Date.now(),\n isPrimaryUser: true,\n tenantIds: ['default'],\n phoneNumbers: [],\n thirdParty: null,\n loginMethods: [],\n webauthn: {\n credentialIds: ['mock-credential-id'],\n },\n toJson: () => ({\n id: 'test_st',\n emails: ['test@example.com'],\n }),\n };\n\n // Mock session container\n const createMockSessionContainer = (userId: string): SessionContainerInterface => ({\n revokeSession: jest.fn(),\n getSessionDataFromDatabase: jest.fn(),\n updateSessionDataInDatabase: jest.fn(),\n getUserId: () => userId,\n getAccessToken: () => 'mock-access-token',\n getHandle: () => 'mock-session-handle',\n getRecipeUserId: jest.fn().mockReturnValue({ getAsString: () => userId }),\n getTenantId: jest.fn().mockReturnValue('default'),\n getAccessTokenPayload: jest.fn().mockReturnValue({}),\n getAllSessionTokensDangerously: jest.fn().mockReturnValue({\n accessToken: 'mock-access-token',\n refreshToken: 'mock-refresh-token',\n }),\n mergeIntoAccessTokenPayload: jest.fn(),\n getTimeCreated: jest.fn().mockReturnValue(Date.now()),\n getExpiry: jest.fn().mockReturnValue(Date.now() + 3600000),\n assertClaims: jest.fn(),\n \n // Adding missing methods with mock implementations\n fetchAndSetClaim: jest.fn(),\n setClaimValue: jest.fn(),\n getClaimValue: jest.fn(),\n removeClaim: jest.fn(),\n attachToRequestResponse: jest.fn(),\n });\n\n // Reset all mocks before each test\n beforeEach(() => {\n jest.clearAllMocks();\n });\n\n // Utility function to create sign up/in response\n const createSuccessResponse = () => ({\n status: "OK" as const,\n user: mockUser,\n recipeUserId: {\n getAsString: () => mockUser.id,\n },\n });\n\n // Test 1: Sign Up\n test('should successfully sign up a new user', async () => {\n // Arrange\n const mockSignUpResponse = createSuccessResponse();\n const mockAlreadyExistsResponse = { \n status: "EMAIL_ALREADY_EXISTS_ERROR" as const \n };\n\n (EmailPassword.signUp as jest.Mock)\n .mockImplementation((tenantId, email, password) => {\n if (email === 'test@example.com') {\n return Promise.resolve(mockSignUpResponse);\n }\n if (email === 'existing@example.com') {\n return Promise.resolve(mockAlreadyExistsResponse);\n }\n throw new Error('Unexpected email');\n });\n\n const mockSession = createMockSessionContainer(mockUser.id);\n (Session.createNewSession as jest.Mock).mockResolvedValue(mockSession);\n\n // Act\n const signUpResult = await EmailPassword.signUp(\n 'tenant-id', \n 'test@example.com', \n 'Test123!'\n );\n\n // Assert\n expect(signUpResult).toEqual(expect.objectContaining({\n status: "OK",\n user: expect.objectContaining({\n emails: expect.arrayContaining(['test@example.com'])\n })\n }));\n\n // Try signing up with existing email\n const existingEmailResult = await EmailPassword.signUp(\n 'tenant-id', \n 'existing@example.com', \n 'Test123!'\n );\n\n expect(existingEmailResult).toEqual({\n status: "EMAIL_ALREADY_EXISTS_ERROR"\n });\n });\n\n // Test 2: Session Verification\n test('should get user session', async () => {\n // Arrange\n const mockSession = createMockSessionContainer(mockUser.id);\n\n (Session.getSession as jest.Mock).mockResolvedValue(mockSession);\n\n // Act\n const sessionResult = await Session.getSession(\n {} as any, // req\n {} as any, // res\n {} // options\n );\n\n // Assert\n expect(sessionResult.getUserId()).toBe(mockUser.id);\n expect(Session.getSession).toHaveBeenCalled();\n });\n\n // Test 3: Revoking Sessions\n test('should revoke all sessions for a user', async () => {\n // Arrange\n const mockRevokeResponse: string[] = [mockUser.id];\n\n (Session.revokeAllSessionsForUser as jest.Mock).mockResolvedValue(mockRevokeResponse);\n\n // Act\n const revokeResult = await Session.revokeAllSessionsForUser(mockUser.id);\n\n // Assert\n expect(revokeResult).toEqual([mockUser.id]);\n expect(Session.revokeAllSessionsForUser).toHaveBeenCalledWith(mockUser.id);\n });\n\n // Test 4: Sign In\n test('should successfully sign in an existing user', async () => {\n // Arrange\n const mockSignInResponse = createSuccessResponse();\n const mockWrongCredentialsResponse = { \n status: "WRONG_CREDENTIALS_ERROR" as const \n };\n\n (EmailPassword.signIn as jest.Mock)\n .mockImplementation((tenantId, email, password) => {\n if (email === 'test@example.com') {\n return Promise.resolve(mockSignInResponse);\n }\n if (email === 'wrong@example.com') {\n return Promise.resolve(mockWrongCredentialsResponse);\n }\n throw new Error('Unexpected email');\n });\n\n const mockSession = createMockSessionContainer(mockUser.id);\n (Session.createNewSession as jest.Mock).mockResolvedValue(mockSession);\n\n // Act\n const signInResult = await EmailPassword.signIn(\n 'tenant-id', \n 'test@example.com', \n 'Test123!'\n );\n\n // Assert\n expect(signInResult).toEqual(expect.objectContaining({\n status: "OK",\n user: expect.objectContaining({\n emails: expect.arrayContaining(['test@example.com'])\n })\n }));\n\n // Try signing in with wrong credentials\n const wrongCredentialsResult = await EmailPassword.signIn(\n 'tenant-id', \n 'wrong@example.com', \n 'WrongPass123!'\n );\n\n expect(wrongCredentialsResult).toEqual({\n status: "WRONG_CREDENTIALS_ERROR"\n });\n });\n\n // Error Handling Tests\n describe('Error Scenarios', () => {\n test('should handle sign up failure', async () => {\n // Arrange\n const mockError = new Error('Sign up failed');\n \n (EmailPassword.signUp as jest.Mock).mockRejectedValue(mockError);\n\n // Act & Assert\n await expect(EmailPassword.signUp(\n 'tenant-id',\n 'test@example.com', \n 'Test123!'\n )).rejects.toThrow('Sign up failed');\n });\n\n test('should handle session retrieval failure', async () => {\n // Arrange\n const mockError = new Error('Invalid session');\n \n (Session.getSession as jest.Mock).mockRejectedValue(mockError);\n\n // Act & Assert\n await expect(Session.getSession(\n {} as any, // req\n {} as any, // res\n {} // options\n )).rejects.toThrow('Invalid session');\n });\n });\n});`, `19589297603779408000`)\"\n >\n \n \n \n \n
\nimport SuperTokens from 'supertokens-node';\nimport EmailPassword from 'supertokens-node/recipe/emailpassword';\nimport Session from 'supertokens-node/recipe/session';\nimport { SessionContainerInterface } from 'supertokens-node/recipe/session/types';\nimport { User } from 'supertokens-node/types';\n\n// Mock dependencies\njest.mock('supertokens-node', () => ({\n  init: jest.fn(),\n}));\n\njest.mock('supertokens-node/recipe/emailpassword', () => ({\n  signUp: jest.fn(),\n  signIn: jest.fn(),\n}));\n\njest.mock('supertokens-node/recipe/session', () => ({\n  createNewSession: jest.fn(),\n  getSession: jest.fn(),\n  revokeAllSessionsForUser: jest.fn(),\n}));\n\ndescribe('Authentication Flow Tests', () => {\n  // Comprehensive mock user data\n  const mockUser: User = {\n    id: 'test_st',\n    emails: ['test@example.com'],\n    timeJoined: Date.now(),\n    isPrimaryUser: true,\n    tenantIds: ['default'],\n    phoneNumbers: [],\n    thirdParty: null,\n    loginMethods: [],\n    webauthn: {\n      credentialIds: ['mock-credential-id'],\n    },\n    toJson: () => ({\n      id: 'test_st',\n      emails: ['test@example.com'],\n    }),\n  };\n\n  // Mock session container\n  const createMockSessionContainer = (userId: string): SessionContainerInterface => ({\n    revokeSession: jest.fn(),\n    getSessionDataFromDatabase: jest.fn(),\n    updateSessionDataInDatabase: jest.fn(),\n    getUserId: () => userId,\n    getAccessToken: () => 'mock-access-token',\n    getHandle: () => 'mock-session-handle',\n    getRecipeUserId: jest.fn().mockReturnValue({ getAsString: () => userId }),\n    getTenantId: jest.fn().mockReturnValue('default'),\n    getAccessTokenPayload: jest.fn().mockReturnValue({}),\n    getAllSessionTokensDangerously: jest.fn().mockReturnValue({\n      accessToken: 'mock-access-token',\n      refreshToken: 'mock-refresh-token',\n    }),\n    mergeIntoAccessTokenPayload: jest.fn(),\n    getTimeCreated: jest.fn().mockReturnValue(Date.now()),\n    getExpiry: jest.fn().mockReturnValue(Date.now() + 3600000),\n    assertClaims: jest.fn(),\n    \n    // Adding missing methods with mock implementations\n    fetchAndSetClaim: jest.fn(),\n    setClaimValue: jest.fn(),\n    getClaimValue: jest.fn(),\n    removeClaim: jest.fn(),\n    attachToRequestResponse: jest.fn(),\n  });\n\n  // Reset all mocks before each test\n  beforeEach(() => {\n    jest.clearAllMocks();\n  });\n\n  // Utility function to create sign up/in response\n  const createSuccessResponse = () => ({\n    status: \"OK\" as const,\n    user: mockUser,\n    recipeUserId: {\n      getAsString: () => mockUser.id,\n    },\n  });\n\n  // Test 1: Sign Up\n  test('should successfully sign up a new user', async () => {\n    // Arrange\n    const mockSignUpResponse = createSuccessResponse();\n    const mockAlreadyExistsResponse = { \n      status: \"EMAIL_ALREADY_EXISTS_ERROR\" as const \n    };\n\n    (EmailPassword.signUp as jest.Mock)\n      .mockImplementation((tenantId, email, password) => {\n        if (email === 'test@example.com') {\n          return Promise.resolve(mockSignUpResponse);\n        }\n        if (email === 'existing@example.com') {\n          return Promise.resolve(mockAlreadyExistsResponse);\n        }\n        throw new Error('Unexpected email');\n      });\n\n    const mockSession = createMockSessionContainer(mockUser.id);\n    (Session.createNewSession as jest.Mock).mockResolvedValue(mockSession);\n\n    // Act\n    const signUpResult = await EmailPassword.signUp(\n      'tenant-id', \n      'test@example.com', \n      'Test123!'\n    );\n\n    // Assert\n    expect(signUpResult).toEqual(expect.objectContaining({\n      status: \"OK\",\n      user: expect.objectContaining({\n        emails: expect.arrayContaining(['test@example.com'])\n      })\n    }));\n\n    // Try signing up with existing email\n    const existingEmailResult = await EmailPassword.signUp(\n      'tenant-id', \n      'existing@example.com', \n      'Test123!'\n    );\n\n    expect(existingEmailResult).toEqual({\n      status: \"EMAIL_ALREADY_EXISTS_ERROR\"\n    });\n  });\n\n  // Test 2: Session Verification\n  test('should get user session', async () => {\n    // Arrange\n    const mockSession = createMockSessionContainer(mockUser.id);\n\n    (Session.getSession as jest.Mock).mockResolvedValue(mockSession);\n\n    // Act\n    const sessionResult = await Session.getSession(\n      {} as any,  // req\n      {} as any,  // res\n      {}  // options\n    );\n\n    // Assert\n    expect(sessionResult.getUserId()).toBe(mockUser.id);\n    expect(Session.getSession).toHaveBeenCalled();\n  });\n\n  // Test 3: Revoking Sessions\n  test('should revoke all sessions for a user', async () => {\n    // Arrange\n    const mockRevokeResponse: string[] = [mockUser.id];\n\n    (Session.revokeAllSessionsForUser as jest.Mock).mockResolvedValue(mockRevokeResponse);\n\n    // Act\n    const revokeResult = await Session.revokeAllSessionsForUser(mockUser.id);\n\n    // Assert\n    expect(revokeResult).toEqual([mockUser.id]);\n    expect(Session.revokeAllSessionsForUser).toHaveBeenCalledWith(mockUser.id);\n  });\n\n  // Test 4: Sign In\n  test('should successfully sign in an existing user', async () => {\n    // Arrange\n    const mockSignInResponse = createSuccessResponse();\n    const mockWrongCredentialsResponse = { \n      status: \"WRONG_CREDENTIALS_ERROR\" as const \n    };\n\n    (EmailPassword.signIn as jest.Mock)\n      .mockImplementation((tenantId, email, password) => {\n        if (email === 'test@example.com') {\n          return Promise.resolve(mockSignInResponse);\n        }\n        if (email === 'wrong@example.com') {\n          return Promise.resolve(mockWrongCredentialsResponse);\n        }\n        throw new Error('Unexpected email');\n      });\n\n    const mockSession = createMockSessionContainer(mockUser.id);\n    (Session.createNewSession as jest.Mock).mockResolvedValue(mockSession);\n\n    // Act\n    const signInResult = await EmailPassword.signIn(\n      'tenant-id', \n      'test@example.com', \n      'Test123!'\n    );\n\n    // Assert\n    expect(signInResult).toEqual(expect.objectContaining({\n      status: \"OK\",\n      user: expect.objectContaining({\n        emails: expect.arrayContaining(['test@example.com'])\n      })\n    }));\n\n    // Try signing in with wrong credentials\n    const wrongCredentialsResult = await EmailPassword.signIn(\n      'tenant-id', \n      'wrong@example.com', \n      'WrongPass123!'\n    );\n\n    expect(wrongCredentialsResult).toEqual({\n      status: \"WRONG_CREDENTIALS_ERROR\"\n    });\n  });\n\n  // Error Handling Tests\n  describe('Error Scenarios', () => {\n    test('should handle sign up failure', async () => {\n      // Arrange\n      const mockError = new Error('Sign up failed');\n      \n      (EmailPassword.signUp as jest.Mock).mockRejectedValue(mockError);\n\n      // Act & Assert\n      await expect(EmailPassword.signUp(\n        'tenant-id',\n        'test@example.com', \n        'Test123!'\n      )).rejects.toThrow('Sign up failed');\n    });\n\n    test('should handle session retrieval failure', async () => {\n      // Arrange\n      const mockError = new Error('Invalid session');\n      \n      (Session.getSession as jest.Mock).mockRejectedValue(mockError);\n\n      // Act & Assert\n      await expect(Session.getSession(\n        {} as any,  // req\n        {} as any,  // res\n        {}  // options\n      )).rejects.toThrow('Invalid session');\n    });\n  });\n});
\n

Updates also need to be made to the package.json to include our test packages and to add the cmd npm test

\n

package.json

\n\n \n \n \n \n
\n{\n    \"scripts\": {\n        \"start\": \"npx vite-node ./main.ts\",\n        \"lint\": \"eslint .\",\n        \"build\": \"tsc\",\n        \"test\": \"jest\"\n    },\n    \"dependencies\": {\n        \"@koa/cors\": \"^5.0.0\",\n        \"koa\": \"^2.15.3\",\n        \"koa-router\": \"^12.0.0\",\n        \"supertokens-node\": \"latest\",\n        \"typescript\": \"^4.7.2\"\n    },\n    \"devDependencies\": {\n        \"@eslint/js\": \"^9.17.0\",\n        \"@types/jest\": \"^29.5.11\",\n        \"@types/koa__cors\": \"^4.0.0\",\n        \"@types/koa-router\": \"^7.4.4\",\n        \"@types/node\": \"^20.11.0\",\n        \"@types/node-fetch\": \"^2.6.11\",\n        \"axios\": \"^1.6.2\",\n        \"eslint\": \"^9.17.0\",\n        \"globals\": \"^15.13.0\",\n        \"jest\": \"^29.7.0\",\n        \"node-fetch\": \"^2.7.0\",\n        \"qs\": \"^6.11.2\",\n        \"ts-jest\": \"^29.1.1\",\n        \"typescript-eslint\": \"^8.18.1\",\n        \"vite-node\": \"^2.1.8\",\n        \"jest-mock\": \"^29.7.0\",\n        \"@types/jest\": \"^29.5.11\"\n    }\n}\n\n
\n

Run npm install then npm test

\n

It’s worth noting the unit tests we added are mocking the api calls. In an enterprise environment ideally there would also be a staging/canary environment that allows full live end-to-end testing for the service.

\n

Logging and Metrics

\n

Logging and Metrics are two important aspects every service should have. They help provide a clear picture into your system to better scale infra or track down a loose bug.

\n

Looking at /backend/main.ts we’ll track how many times a user has logged in, maybe this can provide an insight into strange user behavior to keep an eye out for:

\n

Backend main.ts

\n {\n ctx.body = "hello";\n});\n\n// An example API that requires session verification\nrouter.get("/sessioninfo", verifySession(), (ctx: SessionContext) => {\n const userId = ctx.session!.getUserId();\n \n // Log successful authentication\n authLogs.success++;\n authLogs.recentAttempts.push({\n time: new Date().toISOString(),\n userId,\n status: "success"\n });\n \n ctx.status = 200;\n ctx.body = {\n userId,\n status: "ok",\n authStats: authLogs\n };\n});\n\n// This API is used by the frontend to create the tenants drop down when the app loads.\n// Depending on your UX, you can remove this API.\nrouter.get("/tenants", async (ctx: SessionContext) => {\n const tenants = await Multitenancy.listAllTenants();\n ctx.body = JSON.stringify({ tenants }, null, 4);\n});\n\napp.use(router.routes());\n\nif (!module.parent) app.listen(3001, () => console.log("API Server listening on port 3001"));\n\n`, `40567668967029570000`)\"\n >\n \n \n \n \n
\nimport Koa from \"koa\";\nimport cors from \"@koa/cors\";\nimport supertokens from \"supertokens-node\";\nimport { middleware } from \"supertokens-node/framework/koa\";\nimport { getWebsiteDomain, SuperTokensConfig } from \"./config\";\nimport KoaRouter from \"koa-router\";\nimport { verifySession } from \"supertokens-node/recipe/session/framework/koa\";\nimport { SessionContext } from \"supertokens-node/framework/koa\";\nimport Multitenancy from \"supertokens-node/recipe/multitenancy\";\n\nimport { deleteUser } from \"supertokens-node\";\n\n// basic structures to hold our metrics\ninterface AuthAttempt {\n    time: string;\n    userId: string;\n    status: string;\n}\n\nconst authLogs = {\n    success: 0,\n    recentAttempts: [] as AuthAttempt[]\n};\n\nsupertokens.init(SuperTokensConfig);\n\nconst app = new Koa();\n\nconst router = new KoaRouter();\n\napp.use(\n    cors({\n        origin: getWebsiteDomain(),\n        allowHeaders: [\"content-type\", ...supertokens.getAllCORSHeaders()],\n        credentials: true,\n    })\n);\n\n// This exposes all the APIs from SuperTokens to the client.\napp.use(middleware());\n\n// This endpoint can be accessed regardless of\n// having a session with SuperTokens\nrouter.get(\"/hello\", (ctx: SessionContext) => {\n    ctx.body = \"hello\";\n});\n\n// An example API that requires session verification\nrouter.get(\"/sessioninfo\", verifySession(), (ctx: SessionContext) => {\n    const userId = ctx.session!.getUserId();\n    \n    // Log successful authentication\n    authLogs.success++;\n    authLogs.recentAttempts.push({\n        time: new Date().toISOString(),\n        userId,\n        status: \"success\"\n    });\n    \n    ctx.status = 200;\n    ctx.body = {\n        userId,\n        status: \"ok\",\n        authStats: authLogs\n    };\n});\n\n// This API is used by the frontend to create the tenants drop down when the app loads.\n// Depending on your UX, you can remove this API.\nrouter.get(\"/tenants\", async (ctx: SessionContext) => {\n    const tenants = await Multitenancy.listAllTenants();\n    ctx.body = JSON.stringify({ tenants }, null, 4);\n});\n\napp.use(router.routes());\n\nif (!module.parent) app.listen(3001, () => console.log(\"API Server listening on port 3001\"));\n\n
\n

Each recipe on the frontend /frontend/src/config.tsx has a onHandleEvent to help log what is currently happening in the system.

\n

Frontend config.tsx

\n {\n // Track session events\n if (context.action === "SUCCESS") {\n if (context.createdNewSession) {\n let user = context.user;\n if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {\n // sign up success\n console.log("sign up was a success")\n } else {\n // sign in success\n console.log("sign in was a success - no second auth")\n }\n } else {\n // during step up or second factor auth with email password\n console.log("sign in was a success - second factor auth")\n }\n }\n }\n }),\n MultiFactorAuth.init({ \n firstFactors: ["webauthn", "emailpassword"]\n }),\n TOTP.init(),\n Session.init()\n ],\n getRedirectionURL: async (context) => {\n if (context.action === "SUCCESS" && context.newSessionCreated) {\n return "/dashboard";\n }\n },\n};\n\nexport const recipeDetails = {\n docsLink: "https://supertokens.com/docs/emailpassword/introduction",\n};\n\nexport const PreBuiltUIList = [\n EmailPasswordPreBuiltUI,\n WebauthnPreBuiltUI,\n PasswordlessPreBuiltUI,\n MultiFactorAuthPreBuiltUI,\n TOTPPreBuiltUI\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n return props.children;\n};\n\n`, `59349585916866494000`)\"\n >\n \n \n \n \n
\nimport EmailPassword from \"supertokens-auth-react/recipe/emailpassword\";\nimport { EmailPasswordPreBuiltUI } from \"supertokens-auth-react/recipe/emailpassword/prebuiltui\";\nimport Session from \"supertokens-auth-react/recipe/session\";\n\nimport WebAuthn from \"supertokens-auth-react/recipe/webauthn\"; // passkeys\nimport { WebauthnPreBuiltUI } from 'supertokens-auth-react/recipe/webauthn/prebuiltui'; // passkeys\n\n// mfa\nimport MultiFactorAuth from \"supertokens-auth-react/recipe/multifactorauth\";\nimport { MultiFactorAuthPreBuiltUI } from \"supertokens-auth-react/recipe/multifactorauth/prebuiltui\";\nimport Passwordless from \"supertokens-auth-react/recipe/passwordless\";\nimport { PasswordlessPreBuiltUI } from \"supertokens-auth-react/recipe/passwordless/prebuiltui\";\nimport TOTP from \"supertokens-auth-react/recipe/totp\";\nimport { TOTPPreBuiltUI } from \"supertokens-auth-react/recipe/totp/prebuiltui\";\n\nexport function getApiDomain() {\n    const apiPort = import.meta.env.VITE_APP_API_PORT || 3001;\n    const apiUrl = import.meta.env.VITE_APP_API_URL || `http://localhost:${apiPort}`;\n    return apiUrl;\n}\n\nexport function getWebsiteDomain() {\n    const websitePort = import.meta.env.VITE_APP_WEBSITE_PORT || 3000;\n    const websiteUrl = import.meta.env.VITE_APP_WEBSITE_URL || `http://localhost:${websitePort}`;\n    return websiteUrl;\n}\n\nexport const SuperTokensConfig = {\n    appInfo: {\n        appName: \"SuperTokens Demo App\",\n        apiDomain: getApiDomain(),\n        websiteDomain: getWebsiteDomain(),\n    },\n    // recipeList contains all the modules that you want to\n    // use from SuperTokens. See the full list here: https://supertokens.com/docs/guides\n    recipeList: [\n        EmailPassword.init(),\n        WebAuthn.init(),\n        Passwordless.init({\n            contactMethod: \"EMAIL_OR_PHONE\",\n            onHandleEvent: (context) => {\n                // Track session events\n                if (context.action === \"SUCCESS\") {\n                    if (context.createdNewSession) {\n                        let user = context.user;\n                        if (context.isNewRecipeUser && context.user.loginMethods.length === 1) {\n                            // sign up success\n                            console.log(\"sign up was a success\")\n                        } else {\n                            // sign in success\n                            console.log(\"sign in was a success - no second auth\")\n                        }\n                    } else {\n                        // during step up or second factor auth with email password\n                        console.log(\"sign in was a success - second factor auth\")\n                    }\n                }\n            }\n        }),\n        MultiFactorAuth.init({ \n            firstFactors: [\"webauthn\", \"emailpassword\"]\n        }),\n        TOTP.init(),\n        Session.init()\n    ],\n    getRedirectionURL: async (context) => {\n        if (context.action === \"SUCCESS\" && context.newSessionCreated) {\n            return \"/dashboard\";\n        }\n    },\n};\n\nexport const recipeDetails = {\n    docsLink: \"https://supertokens.com/docs/emailpassword/introduction\",\n};\n\nexport const PreBuiltUIList = [\n    EmailPasswordPreBuiltUI,\n    WebauthnPreBuiltUI,\n    PasswordlessPreBuiltUI,\n    MultiFactorAuthPreBuiltUI,\n    TOTPPreBuiltUI\n];\n\nexport const ComponentWrapper = (props: { children: JSX.Element }): JSX.Element => {\n    return props.children;\n};\n\n
\n

How this setup prevents a phishing attack

\n

Traditional authentication methods are vulnerable because they rely on shared secrets that can be intercepted. To illustrate how the WebAuthn implementation protects against these attacks, let’s simulate a common phishing scenario and see how our SuperTokens + WebAuthn setup renders it ineffective.

\n

In a typical phishing attack targeting traditional MFA:

\n
    \n
  1. An attacker creates a convincing clone of your login page
    2. \n
  2. They send users a link to this fake site (e.g., my-legit-app-secure.com instead of mylegitapp.com)
    3. \n
  3. When users enter credentials and MFA codes, the attacker captures them in real-time
    4. \n
  4. The attacker uses these stolen credentials to access the real site
    5. \n
\n

Even with traditional MFA like SMS codes or authenticator apps, this attack works because the attacker can simply forward the stolen credentials and MFA codes to the legitimate service immediately after capturing them.

\n

This isn’t just theoretical protection. Remember the Cloudflare incident mentioned earlier? Their own security report explicitly stated that employees using FIDO2-based WebAuthn keys (the same standard we’re implementing) remained protected while those using push notifications were compromised.

\n

By requiring phishing-resistant MFA with WebAuthn as we’ve implemented, you’re effectively removing phishing as a viable attack vector against your authentication system. Even if users are tricked into visiting a fake site, the browser’s security model prevents the attack from succeeding.

\n

How SuperTokens Elevates Phishing-Resistant MFA

\n

Why Use SuperTokens Instead of Rolling Your Own?

\n

Authentication seems straightforward on the surface—verify identity and grant access—but implementing it securely involves intricate technical challenges. Many developers underestimate these complexities until they encounter serious security issues in production.

\n

Building your own authentication system from scratch requires managing numerous critical components:

\n
    \n
  1. Security vulnerabilities: Without specialized knowledge, your system could be vulnerable to common attacks like CSRF, XSS, session fixation, and credential stuffing
    2. \n
  2. Compliance requirements: Meeting standards like GDPR, HIPAA, SOC2, and other regulations requires domain expertise that’s expensive to develop and maintain in-house
    3. \n
  3. Ongoing maintenance: Authentication isn’t a “build once and forget” feature—it requires constant updates to address evolving security threats and browser compatibility issues
    4. \n
  4. Developer resources: Building robust authentication diverts valuable engineering time from your core product features and business logic
    5. \n
  5. Edge cases: Authentication has countless edge cases around account recovery, device management, and session handling that you’ll need to solve
    6. \n
\n

SuperTokens’ Advanced Security Features for Phishing-Resistant MFA

\n

Modern authentication systems rely on tokens to maintain user sessions, but these tokens become prime targets for attackers. SuperTokens implements sophisticated session management that mitigates token theft.

\n

SuperTokens implements automatic token rotation, significantly reducing the window of opportunity for attackers if a token is somehow compromised:

\n
    \n
  • Access tokens have short lifespans
    • \n
  • Refresh tokens are automatically rotated with each use
    • \n
  • The rotation system maintains session continuity while limiting exposure
    • \n
\n

Seamless Integration with WebAuthn & FIDO2

\n

SuperTokens’ implementation creates a frictionless bridge between traditional authentication flows and phishing-resistant standards. This means users can authenticate using:

\n
    \n
  • Built-in biometrics (TouchID, FaceID, Windows Hello)
    • \n
  • Platform authenticators (Android/Iphone fingerprint sensors)
    • \n
  • External security keys (YubiKey, Titan Security Key)
    • \n
\n

Flexible Architecture: Enforce MFA for Specific Users/Roles

\n

SuperTokens provides granular control over authentication requirements without complex custom code. With Role-Based MFA Policies you can implement different security requirements based on user roles. This enables you to:

\n
    \n
  • Enforce hardware security keys for administrators
    • \n
  • Require second factors only for sensitive operations
    • \n
  • Implement different policies based on user risk profiles
    • \n
\n

SuperTokens makes it easy to require additional authentication for specific actions. This allows you to:

\n
    \n
  • Require additional factors for high-value transactions
    • \n
  • Implement risk-based authentication policies
    • \n
  • Verify identity before sensitive account changes
    • \n
\n

The system handles common edge cases like authenticator loss. This provides secure recovery options while maintaining security:

\n
    \n
  • Email/phone fallback mechanisms
    • \n
  • Backup code generation for account recovery
    • \n
  • Administrator-assisted recovery workflows
    • \n
\n

By leveraging SuperTokens’ flexible architecture, you can implement authentication policies that balance security with usability, applying the appropriate level of protection based on user role, action sensitivity, and risk assessment.

\n

In the next section, we’ll explore how to deploy this phishing-resistant MFA system at scale and integrate it with existing infrastructure.

\n

Final Thoughts & Next Steps

\n

Taking Phishing-Resistant Authentication to the Next Level

\n

For organizations with stringent security requirements, SuperTokens offers device attestation capabilities that can be leveraged for:

\n
    \n
  • Verifies authenticator is from a trusted manufacturer
    • \n
  • Ensures hardware-backed key storage
    • \n
  • Requires user verification (biometric or PIN)
    • \n
  • Prevents credential cloning between devices
    • \n
\n

Device attestation enables security teams to enforce hardware security key policies and maintain an audit trail of registered authenticators—critical for regulated industries.

\n

Encouraging User Adoption: Making WebAuthn Onboarding Seamless

\n

The most secure authentication is useless if users can’t or won’t use it. SuperTokens provides customizable UI components that guide users through adopting phishing-resistant authentication, making the entire process as low friction as possible.

\n

Best practices for increasing adoption include:

\n
    \n
  • Explaining the possible costs that come with a phishing attack
    • \n
  • Creating fallback mechanisms for lost devices
    • \n
  • Gradually transitioning from traditional MFA to phishing-resistant options
    • \n
\n

Further Reading: SuperTokens Documentation

\n

The implementation we’ve explored is just the beginning. SuperTokens offers extensive documentation for advanced configurations:

\n\n

Conclusion

\n

By implementing phishing-resistant MFA with SuperTokens and WebAuthn, you’ve addressed one of the most persistent security vulnerabilities facing modern applications. This approach not only protects your users from sophisticated attacks but also improves their authentication experience.

\n

The combination of SuperTokens’ flexible architecture, WebAuthn’s cryptographic security, and the FIDO2 standards creates a defense-in-depth strategy that eliminates entire categories of authentication attacks while providing the granular control needed to balance security with usability.

\n

As phishing attacks continue to evolve in sophistication, this implementation ensures your authentication system remains resilient against current and future threats.

\n

","frontmatter":{"date":"May 06, 2025","title":"Implementing Phishing-Resistant MFA: Hands-On Developer Guide","cover":"Implementing-Phishing-Resistant-MFA.png","author":"Maurice Saldivar","description":"Learn how to implement phishing-resistant MFA with FIDO2, WebAuthn, and SuperTokens. Step-by-step tutorial for secure, developer-friendly authentication."},"fields":{"slug":"/phishing-resistant-mfa/"}},"site":{"siteMetadata":{"title":"SuperTokens Blog"}}},"pageContext":{"id":"61890d1b-5d87-5b6d-9e83-30f65c8ecb19","fields__slug":"/phishing-resistant-mfa/","__params":{"fields__slug":"phishing-resistant-mfa"}}}, "staticQueryHashes": []}