For most SMEs, the right move is to delegate authentication to a standards-based identity provider using OIDC or SAML rather than building 2FA from scratch. Use phishing-resistant methods like push or FIDO for admins and privileged accounts, and methods like TOTP or SMS for lower-risk customer journeys. Whichever route you choose, give your developer clear specifications: authorization code flow, PKCE for public clients, defined redirect URIs, and proper JWT verification.
TL;DR:
- Delegating authentication to a standards-based IdP reduces long-term security and maintenance risks, especially for high-risk or regulated environments.
- FIDO/WebAuthn and push notifications are recommended for privileged accounts and high-value transactions due to their phishing resistance.
- Clear specifications for protocol flow, endpoints, redirect URIs, and acceptance testing are essential to ensure secure and reliable implementation.
- Recovery processes must include multi-step human verification and logging to prevent social engineering attacks that bypass second-factor protections.
- Costs and ongoing maintenance, such as certificate rotation and patching, should be considered from the start, with ownership clearly defined for policies and technical updates.
Table of Contents
- When to delegate authentication to an IdP and when to build 2FA into your app
- Which second-factor methods actually fit your use case
- What to give your developer: the integration checklist
- Security checklist: the controls that make 2FA actually work
- Costs, maintenance and who owns what afterwards
- How Flowlab scopes and delivers 2FA work for SMEs
- Get a complimentary app fit review before you brief a developer
- Sources
- FAQ
When to delegate authentication to an IdP and when to build 2FA into your app
Delegating authentication means your application hands the login process to a specialist identity provider (IdP) rather than handling passwords and codes itself. The app receives a signed token confirming who the user is, and never touches the credential directly. Standard protocols such as OIDC and SAML reduce risk precisely because they’ve been tested against years of real attacks. A QoA parameter can even request a minimum assurance level, so the IdP presents a stronger method automatically when the transaction warrants it.
In-app 2FA still has a place. If you’re building a small internal tool with a handful of staff and no regulatory exposure, coding a TOTP check yourself might be faster and cheaper than integrating an external IdP. The drawback is that you now own every security update, every edge case, and every future vulnerability that surfaces in your custom code.
Decide based on:
- Regulatory exposure — sectors with compliance obligations should lean towards audited, standards-based providers.
- Admin access risk — anyone with elevated permissions needs stronger protection than a general user.
- Developer resources — a small team with limited security experience benefits from an IdP doing the heavy lifting.
- Budget for the long term — custom systems cost less upfront and considerably more to maintain.
Practitioner guidance is consistent on this point: projects that build proprietary 2FA rather than relying on standard protocols tend to carry higher long-term maintenance and security risk than teams expect at the outset.
Which second-factor methods actually fit your use case
Not every login needs the same level of friction. Matching the method to the risk of the transaction keeps staff and customers moving without weakening protection where it matters.
- TOTP (time-based one-time passcode) generates a six-digit code inside an authenticator app that refreshes every 30 seconds. It works offline, costs nothing per verification, and suits staff logins or medium-risk customer accounts well.
- SMS OTP sends a code by text message. It’s familiar to almost every user and requires no app installation, but it depends on mobile network reach and carries known interception risks, so it belongs on lower-risk flows only, never on admin or financial approval accounts.
- Push notifications send an approval prompt to a registered device, where the user taps to confirm. This adds context (location, device, time) that a bare code can’t, and it works well for staff and customer journeys with moderate risk.
- FIDO/WebAuthn hardware keys bind authentication to a physical device or platform credential that can’t be phished, because the cryptographic check happens against the exact origin requesting it. Industry guidance consistently points to FIDO and authenticated push as more resilient to phishing than SMS OTP, which is why privileged accounts and high-value transactions should default to one of these two.
Cost and distribution matter too. SMS carries a per-message fee at scale; hardware keys need procurement and replacement logistics; push and TOTP are effectively free once integrated. For a customer-facing app with thousands of users, that arithmetic often decides the method before security even enters the conversation.
What to give your developer: the integration checklist
A developer can only build what you specify. Vague briefs like “add two-factor authentication” produce vague, expensive rework later. Hand over the following before any code is written.
Protocol and flow requirements:
- Require the authorization code flow rather than older, less secure flows. Technical guidance on OIDC integration recommends this pattern specifically because it keeps tokens out of the browser’s history and address bar.
- Specify whether each client is confidential or public, and require PKCE (Proof Key for Code Exchange) on any public client, such as a mobile app or single-page web app, to prevent authorization code interception.
Endpoints and token handling:
- Confirm the IdP’s discovery document, token endpoint, and userinfo endpoint are documented and reachable from your environment.
- Require ID token signature verification on every login, not just at initial setup. Extracts from real-world integration patterns warn specifically against misusing ID tokens for API authorisation, a common shortcut that creates security gaps later.
Redirect and session security:
- List every redirect URI explicitly. Wildcards or loosely matched callback URLs are a common source of token-leak vulnerabilities.
- Define CORS rules and allowed origins before the developer starts, not after testing begins.
- Specify session length, idle timeout, and what happens to existing sessions when a password or second factor changes.
Acceptance tests to demand before sign-off:
- Successful and failed authorization code exchange
- Token signature and expiry validation
- A step-up prompt triggering correctly for a sensitive action
- A simulated recovery flow, checked for account takeover risk
Pro Tip: Ask your developer to demonstrate a failed login attempt with an expired or tampered token, not just a successful one. Most integration bugs hide in the failure paths, not the happy path.
If your organisation needs to connect to a legacy SAML identity provider or a government-issued identity service, an identity broker (the Keycloak pattern is a common example) can convert SAML responses into JWTs your app already understands, avoiding a second, parallel authentication system.
Security checklist: the controls that make 2FA actually work
Two-factor authentication is not a standalone fix. Government guidance on secure remote access is explicit that 2FA works best alongside strong password hygiene, regular patching, and active monitoring, not as a replacement for any of them.
Build these controls in alongside your second factor:
- Password policy minimums paired with account lockout after repeated failed attempts.
- Least-privilege access, so a compromised standard account can’t reach admin functions even if the second factor is bypassed somehow.
- Anomaly and step-up rules that flag logins from new devices or unusual locations and request a stronger factor before allowing access.
- A documented recovery process, including backup codes issued sparingly, a verified support workflow, and centralised logging of every recovery attempt.
The real gap most SMEs miss: phishing resistance isn’t just about which method you choose. It’s about whether your recovery process can be socially engineered around the second factor entirely. A support desk that resets 2FA on a phone call is a bigger risk than weak passwords.
Recovery deserves particular care. Multi-step human verification before reissuing access, strict limits on backup-code issuance, and centralised logging of recovery attempts close off the most common route attackers use to bypass a second factor without ever cracking it.
Costs, maintenance and who owns what afterwards
Budget for four categories: initial development, any IdP subscription fees, per-message SMS costs if you use them, and hardware key procurement for privileged staff. Development is usually the largest one-off cost; SMS and hardware keys are the ongoing, usage-linked ones.
Maintenance doesn’t stop at launch. SMEs routinely underbudget lifecycle tasks such as certificate rotation, library updates, and dependency patching, and skipping these creates the exact vulnerabilities 2FA was meant to close. Build them into your service-level agreement upfront, not as an afterthought.
Ownership matters too. Policy changes (who needs step-up, which roles need FIDO) typically live with whoever manages the central IdP configuration. Application-level changes (how the app requests and handles tokens) sit with your development team. Ask for:
- A clear maintenance line item in the initial scope
- Named ownership for certificate and key rotation
- An agreed response time for security patches
How Flowlab scopes and delivers 2FA work for SMEs
Every 2FA project starts with a question, not a solution: what is the actual operational risk you’re trying to close? A complimentary app fit review works through that before any development conversation happens, weighing whether adapting an existing product foundation gets you there faster than a custom build or whether your workflow genuinely needs something bespoke.
The pitfalls repeat across SME projects. Maintenance budgets get set for the launch date and nothing after. Recovery flows get built as an afterthought, then become the weakest link in the whole system. And SMS gets used for admin accounts because it was the fastest thing to wire up, not because anyone weighed the risk.
None of this is exotic. It’s what happens when authentication gets treated as a checkbox instead of a design decision made against your actual risk profile.
— Ronald
Get a complimentary app fit review before you brief a developer
This company offers a practical route for SMEs who’d rather confirm the right approach before spending on development than discover it was wrong halfway through a build. A complimentary app fit review looks at your actual workflow and tells you plainly whether a delegated IdP integration, an adapted existing product, or a genuinely custom build fits your situation, along with a realistic cost range and timeline before anything is committed.
That review exists specifically to stop SMEs overspending on complexity they don’t need, or underbuilding something that creates risk later. If you’re weighing up costs before you commit to a scope, the app development cost guide gives a useful sense of what different approaches typically involve. When you’re ready to talk specifics, book a review and get a clear answer on the right path for your app.
Sources
Technical guidance cited throughout this piece comes from documented OIDC integration patterns and national identity service architectures. For broader website security context, see this SMB security checklist, and for ongoing authentication auditing, Aisyndicate.
FAQ
Should I use OIDC or SAML for my application?
OIDC is generally simpler to integrate with modern web and mobile apps, while SAML remains common with legacy enterprise and government identity services; an identity broker can bridge the two if you need both.
What’s the difference between delegated IdP and in-app two factor authentication apps?
Delegated IdP hands authentication to an external, standards-based provider, while in-app 2FA means your own codebase generates and checks the second factor, carrying more long-term maintenance risk.
Is SMS OTP secure enough for customer accounts?
SMS OTP is acceptable for lower-risk customer journeys but should never be the only option for admin or privileged accounts, where phishing-resistant methods like FIDO or push are the stronger choice.
How much does adding 2FA to an existing app typically cost?
Costs vary by integration complexity, chosen methods, and whether you’re adapting an existing product or building custom; Flowlab’s complimentary app fit review gives a scoped estimate before you commit to development.
What should a developer’s acceptance tests for 2FA include?
At minimum, tests should cover successful and failed authorization code exchange, token signature verification, a working step-up prompt, and a simulated recovery flow check.