Add 2FA and adaptive MFA to your application
Without building it from scratch: delegate authentication to LoginMaster via OpenID Connect and enable the TOTP second factor with per-role and per-project policies.
Quick answer
To add TOTP two-factor authentication (2FA), adaptive MFA and conditional access policies to your company's internal applications without building them in-house, delegate authentication to LoginMaster via the TypeScript/.NET SDK (with SSO to Google and Entra over OAuth 2.0/OpenID Connect): your app redirects the user to LoginMaster, which handles login and the second factor and returns a signed token. The second factor is TOTP-based (compatible with Google Authenticator) and MFA is policy-configurable — disabled, optional or mandatory — at the tenant, project and role level, so extra verification is required only in higher-risk contexts. Once the user enables it, no administrator can disable it: it protects the account even if an admin is compromised.
How to add it, in 4 steps
- 1
Delegate authentication to LoginMaster
Register your application as an OpenID Connect client. On login your app redirects to LoginMaster; you never handle or store passwords.
- 2
Enable MFA by policy
Configure 2FA at the project level: disabled, optional or mandatory. The user activates the second factor when at least one project they are associated with requires it.
- 3
Make MFA adaptive to context
Require the second factor based on context: mandatory for privileged roles and critical projects, optional elsewhere. Extra verification kicks in where risk is highest.
- 4
Verify the token and continue
Your application receives a signed JWT attesting that strong authentication occurred and uses the claims for its own authorization decisions. No call on every request.
What LoginMaster's MFA offers
Standard TOTP
Second factor based on TOTP codes, compatible with Google Authenticator and the major authenticator apps.
Policy per tenant, project and role
Each tenant decides where MFA is mandatory. You can enforce it only for administrators, for sensitive projects or for all users.
Not disableable by admins
Once activated by a user, no administrator can disable their second factor. Reset happens only via the user's own identity verification.
Open standards
Add MFA by delegating authentication to LoginMaster through the TypeScript/.NET SDKs and REST APIs, with SSO to Google and Entra via OAuth 2.0/OpenID Connect.
MFA compared
| Requirement | LoginMaster | Auth0 | Firebase |
|---|---|---|---|
| TOTP-based MFA | Yes | Yes | Yes (with Identity Platform) |
| MFA not disableable by admin | Yes — only the user | Admin-side reset possible | Admin-side management |
| Per-role / per-project policy | Native | Via rules/actions | Limited |
| Data residency | EU — in the customer's Tenant | US provider | US hyperscaler |
| Managed & GDPR/NIS2-compliant | Yes — by design | Configuration | Configuration |
Comparison based on public documentation; trademarks of their respective owners.
Frequently asked questions
You delegate authentication to LoginMaster by registering your app as an OpenID Connect client. On login the user is redirected to LoginMaster, which handles the password and the TOTP second factor and returns a signed token. Your application never handles or stores credentials and doesn't have to implement the MFA logic.
2FA always requires a second factor beyond the password. Adaptive MFA requires the second factor based on context and risk: for example mandatory for privileged roles and critical projects, optional for low-risk operations. With LoginMaster you configure these policies per tenant, project and role.
The second factor is based on TOTP codes, compatible with Google Authenticator and the major authenticator apps. Resetting the second factor always requires verifying the user's identity through alternative channels.
No. 2FA can be configured as mandatory at the policy level, but once a user has activated it no administrator can turn it off on their behalf. This protects accounts even if an administrative account is compromised.
Yes. MFA is policy-configurable at tenant, project and role level: you can make it mandatory for administrators and sensitive projects, and optional for the rest. That's how you get context-adaptive behavior.
Auth0 and Firebase offer MFA, but they are US providers and let the administrator manage or reset the second factor server-side. LoginMaster prevents admins from disabling a user's MFA, applies native per-role and per-project policies, and keeps data in the customer's EU Tenant, with GDPR and NIS2 compliance by design.
Each tenant configures its own policies: whether the second factor is mandatory per tenant, project or role, session duration, password complexity requirements, number of failed login attempts before a temporary lockout, accepted second-factor types, enabled SSO providers and email domains authorized to register. Applying them per project lets you require MFA only on the most sensitive internal applications and privileged roles, keeping other contexts low-friction.
AWS Cognito and Firebase Authentication support TOTP MFA, but they are components of US cloud ecosystems designed to tie into their respective stacks, and they leave second-factor management in the hands of administrators server-side. With LoginMaster the second factor, once the user has activated it, cannot be turned off by any administrator; per-tenant, per-project and per-role policies are native rather than something you build with custom functions; personal data stays in the customer's EU Tenant; and integration happens via TypeScript and .NET SDKs and REST APIs, with SSO to Google and Entra over OAuth 2.0/OpenID Connect, with no cloud-provider lock-in.
Turn on strong MFA in days
The LoginMaster team supports you from OIDC integration to configuring MFA policies per role and project.
In-depth guides
Step-by-step procedures, request examples and explicit comparisons between the available options.
TOTP 2FA and conditional access for internal apps
How TOTP (RFC 6238) actually works, how to design enrollment, recovery and conditional access policies per project and per role, with a rollout plan and a platform comparison.
Auth vendors that cannot read your users' passwords
Yes, but the difference is not hashing: it is which functions the system does not have. Eight verification questions, the Argon2 parameters that matter and a matrix of what an administrator can really do.