[Security Architecture] Authentication Design - IDaaS + Passkey + Short-Lived Tokens

About this article

As the second installment of the “Security Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains authentication design.

Authentication is the first gate of all access, and once it’s broken, other defenses become meaningless. The password era has effectively ended, and as of 2026, Passkey (FIDO2 password-less authentication) is the front-runner. This article handles selection of authentication methods - the 3 auth factors, password/MFA/Passkey, SSO, social login, IDaaS - while leaving session management to the software chapter and browser defenses to the frontend chapter.

What is authentication in the first place

Authentication is, roughly speaking, “the mechanism for verifying that someone really is who they claim to be.”

Imagine the entrance to an office building. You show your employee badge at reception, your identity is confirmed, and the gate opens — that’s authentication. If you combine not just the badge but also facial recognition and a PIN, no one can get in by picking up a lost badge. The digital world works the same way: combining a password (knowledge), a smartphone (possession), and a fingerprint (biometrics) to raise identity-verification accuracy is what modern authentication design is about.

This article’s coverage

Article	Coverage
This article (auth design)	The 3 auth factors / MFA / Passkey / password policy / IDaaS / SSO
50/02 Authorization and IAM	RBAC / ABAC / ReBAC / least privilege / IAM operation
20/07 Authentication and sessions	Server session vs JWT / OAuth implementation / Cookie server settings
30/07 Auth	Browser-specific XSS / CSRF / CSP / token storage

The question of this article is “how to verify someone’s identity.” Carrying it after verification lives in another chapter.

If the entrance is breached, everything inside the house is meaningless

If authentication is breached, no access control beyond it functions. Auth strength sets the security ceiling for the whole system, so it’s the area to design most carefully. The era when passwords alone could defend has ended, and multi-factor authentication (MFA) has become the de facto standard. The 2022 LastPass leak (a case where massive amounts of encrypted password vaults were taken) and the same year’s Okta supply-chain breach showed that attacks on auth platforms are real risks.

If auth is weak, all security countermeasures are meaningless. No compromise here.

Why it’s needed

1. Impersonation damage is enormous

If auth is breached, attackers can act as legitimate users. From data leaks to financial damage to using the system as a stepping-stone to other systems - it has the power to sink a company in an instant.

2. The era of password-only is over

Phishing, info leaks, brute force - the era of defending with password alone has ended. No-MFA is effectively undefended.

3. Tug-of-war with user experience

Strong auth increases user effort. Failing to balance security and usability appropriately leads users to avoid it and use workarounds.

The 3 auth factors

Authentication is classified into 3 factors by “what evidence is used to verify identity.” MFA combines different factors, so even if one leaks, others defend. Note that two of the same factor (password + secret question) is not MFA.

flowchart TB
    USER([User])
    KNOW["Something you know<br/>(knowledge)<br/>password/PIN"]
    HAVE["Something you have<br/>(possession)<br/>phone/Key/IC"]
    BE["Something you are<br/>(biometric)<br/>fingerprint/face/iris"]
    SFA[1 factor only = SFA<br/>weak]
    MFA[2+ combination = MFA<br/>orders of magnitude stronger]
    USER --> KNOW
    USER --> HAVE
    USER --> BE
    KNOW --> SFA
    KNOW --> MFA
    HAVE --> MFA
    BE --> MFA
    classDef user fill:#fef3c7,stroke:#d97706;
    classDef factor fill:#dbeafe,stroke:#2563eb;
    classDef weak fill:#fee2e2,stroke:#dc2626;
    classDef strong fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    class USER user;
    class KNOW,HAVE,BE factor;
    class SFA weak;
    class MFA strong;

Factor	Meaning	Example
Something you know	Knowledge	Password, PIN, secret question
Something you have	Possession	Phone, security key, IC card
Something you are	Biometric	Fingerprint, face recognition, iris

MFA = combining 2+ of the above, becoming orders of magnitude stronger than 1-factor authentication (SFA).

The limits of passwords

Password authentication is an old method, but in modern times standalone use is discouraged. The reasons - “users use weak passwords,” “they reuse them,” “they get phished” - are because technology can’t fill these human weaknesses.

Problem	Content
Weak passwords	password123 is regularly in the top
Reuse	Other-site leaks chain-breach
Phishing	Entered into fake sites
Brute force	Broken by exhaustive search
Leak-list attacks	Credential Stuffing (the trick of using IDs/passwords leaked elsewhere)

NIST’s (National Institute of Standards and Technology, the US org that creates security standards) guidelines (SP 800-63B) changed to deprecating forced periodic changes, with “length-focused, change only on leak” recommended. The modern basis for passwords is “length, leak detection, MFA combined.”

Multi-factor authentication (MFA)

An auth method using 2+ different factors, blocking 99.9% of attacks compared to standalone password authentication - per Microsoft data. Major MFA methods:

Method	Strength	Notes
SMS code	Low	SIM hijacking, eavesdropping risks
TOTP (Google Authenticator etc.)	Mid	App-generated codes, widely adopted
Push notification (Okta Verify etc.)	Mid	One tap, popular
FIDO2 / WebAuthn (auth standard with public-key crypto, phishing-impossible)	Strongest	Phishing-resistant, password-less possible
Hardware key (YubiKey)	Strongest	Safe unless physically stolen

SMS is weak, so it should be avoided in enterprise systems. To seriously defend, the strongest combination is FIDO2 / WebAuthn + hardware keys.

Password-less authentication

A method that completely eliminates passwords and authenticates with FIDO2 / WebAuthn + biometric only. Spreading via Windows Hello, Apple Face ID, Google Passkeys, etc., it brings fundamental security improvement by making phishing impossible since passwords don’t exist.

Pros	Cons
Phishing-resistant	Compatible devices required
Good user experience	Bad chemistry with old systems
No password management	Hard to handle biometric leak
Unbreakable by leak lists	Recovery procedures complex to design

Since 2024, “passkeys” have become standard at major services - new builds should premise passkey support from the start.

Single sign-on (SSO)

SSO is the mechanism for logging into multiple services with one authentication. For organizations using Google Workspace, Slack, GitHub, Salesforce, etc. for work, the biggest benefit is centralized account management - stopping a retiree’s account ends with one stop on the IdP side.

Protocol	Use case
SAML 2.0	Enterprise veteran, XML-based
OAuth 2.0	Authorization protocol (not authentication)
OpenID Connect (OIDC)	Auth extension on OAuth 2.0, modern mainstream
Kerberos	Windows AD (Active Directory, MS’s auth platform) corporate env

Organizations adopting SSO typically center an IdP (Identity Provider) like Okta, Azure AD (Entra ID), or Google Workspace, and federate to each service via SAML/OIDC.

Social login

A method to let users log in to your service using Google, Apple, GitHub, LINE, etc. Users skip new registration, and there’s the effect of conversion rates rising several times. It’s effectively standard in B2C services.

Provider	Suited for
Google	Wide range, most adopted
Apple	Required for iOS apps (App Store rule)
Microsoft	B2B, enterprise-oriented
GitHub	Developer-oriented tools
LINE	Japanese B2C

For iOS apps offering other social logins, Apple has the rule that Apple Sign-In must coexist. Implementation is doable in dozens of lines using IDaaS like Auth0, Firebase Auth, or Supabase Auth.

IDaaS (auth as SaaS)

IDaaS is a service that “provides auth functions as SaaS,” reducing the cost and risk of building auth platforms in-house. Password storage, MFA, social login, SSO, passkey support - self-implementing these takes person-months, IDaaS takes days.

Rough decision by scale: personal/small startups go with Supabase Auth / Firebase Auth, B2B SaaS with Auth0 / Clerk, large enterprise/SSO-centric with Okta / Entra ID, AWS-centric with Cognito. Choose with these 3 lines, revisit when growth happens.

Service	Characteristics	Suited for
Auth0	Strongest features, B2B/B2C both	Serious systems
Okta	Industry standard, enterprise	Large enterprise, SSO-centric
Firebase Auth	Google, cheap	Mobile, small scale
Supabase Auth	OSS, PostgreSQL-integrated	Startups
Azure AD B2C	Microsoft, low cost	B2C, MS-system companies
AWS Cognito	AWS-integrated	AWS-using companies

Self-building auth is mostly discouraged today. Built by anyone other than security specialists, it becomes hole-ridden.

Decision criteria

1. Service type

The strictness of auth is decided by the sensitivity of the data handled. EC sites and medical systems need different auth strengths.

Service type	Recommended auth
B2C, small	Social login + optional MFA
B2C, money-handling	MFA required (TOTP / Push)
B2B business systems	SSO + MFA required
Finance, medical, government	FIDO2 + hardware key + multi-layer auth

2. User population

Choices also vary by users’ IT literacy. Forcing FIDO2 on a service for elderly users means no one can log in.

User population	Recommended
General consumers (wide ages)	SMS + app, selectable
Corporate users (higher IT literacy)	TOTP / Push / FIDO2
Engineers/developers	FIDO2 + hardware key
Elderly, non-IT	SMS + support-focused

Auth-strength x service-type practical matrix

Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.

Auth strength is decided by sensitivity of data x user IT literacy. Below is the practical matrix.

Service type	User population	Recommended auth	Required MFA	Password strength
B2C, free service	General consumers	Password + social login	Optional	12+ chars
B2C, money-handling (EC, banks)	General consumers	MFA required + Passkey recommended	TOTP / Push	14 chars + leak detection
B2B business SaaS	Corporate users	SSO + MFA required	TOTP / Push / FIDO2	12 chars + periodic
Finance/medical/government	Limited	FIDO2 + hardware key	FIDO2 required	16 chars + audit
Admin accounts	Internal	FIDO2 + hardware key (YubiKey etc.)	Required	Long passphrase
For AI agents	Machine	Service Account + short-lived tokens	-	Avoid API keys

“Microsoft research data shows that just enabling MFA blocks 99.9% of automated attacks.” Avoid SMS in enterprise as it can be broken via SIM swap, and standardize on TOTP / FIDO2 / Passkey - the modern rule.

No-MFA is out of the question. At minimum TOTP, design new builds on the premise of Passkey support.

Auth-design pitfalls and forbidden moves

Here are the typical accident patterns in the auth area. All of them link directly to impersonation, company-survival-level damage.

Forbidden move	Why it’s bad
Self-build auth (bcrypt + Cookie session etc.)	Misses 10+ angles like password-reset path, session-fixation, timing attacks
Adopt SMS only as MFA	Broken in 10 minutes like the 2019 Twitter CEO Jack Dorsey SIM-swap incident
No countermeasure against MFA fatigue attacks	The 2022 Uber internal breach was broken by MFA fatigue. FIDO2 / Passkey phishing-resistance is required
Force periodic password changes	Deprecated by NIST since 2017. Only spawns weak passwords. Change only on leak
Hash passwords with SHA-256 alone	Brute-forced via GPU. Argon2id / bcrypt cost 12+ required
Access Tokens valid for 30+ days	Damage on leak prolongs. 15 min + Refresh Token is the rule
Don’t immediately stop retirees’ auth credentials	The 2019 US major bank internal-fraud case. IAM/IdP deletion required on retirement checklist
Newly implement OAuth Implicit Flow	Deprecated from 2020 onward. Authorization Code with PKCE required
Embed permanent API keys in apps	Instant leak from accidental Git commit. Move to short-lived tokens + Service Account
Grant AI agents the same permissions as humans	Damage scales with high-speed mass operations. Dedicated narrowed-down accounts for agents
”Periodic password changes are safe” forced policy	Deprecated by NIST since 2017; change only on leak is the correct answer
”MFA installed = safe” overconfidence	Broken by MFA fatigue attacks and phishing; FIDO2 is the true answer

The 2022 Uber internal breach (contractor password leak + MFA fatigue attack reaching internal Slack/AWS/GCP), 2019 Twitter CEO SIM swap, 2022 Okta / LastPass breaches - accidents in the auth area grow more sophisticated year by year, and “MFA installed = safe” is a thing of the past.

For auth: don’t self-build, delegate externally + Passkey + short-lived tokens. The triad drastically reduces accident rates.

AI decision axes

AI-era favorable	AI-era unfavorable
IDaaS (Auth0, Okta, Firebase)	Self-built auth
Passkey (FIDO2)	Password-centric
OAuth 2.0 + OIDC	Custom protocols
Short-lived tokens for agents	Permanent API keys

1. Delegate to IDaaS — self-building is mostly discouraged; use Auth0 / Okta / Firebase Auth
2. MFA standard + Passkey support — avoid SMS, recommend TOTP / Passkey
3. Adopt SSO + OIDC — SSO required for enterprise, build with standard protocols
4. Agent auth short-lived and limited — avoid permanent API keys, OAuth Client Credentials + short-lived tokens

Author’s note - the trap of “I can build auth myself”

Stories of getting hurt from self-building auth are well-known industry talking points. There’s a story about an in-house tool where someone built bcrypt + Cookie sessions naively with the motivation “writing auth myself is more educational” - and at the security review just before release, they were pointed out 10+ angles they hadn’t even imagined: password-reset path, brute-force countermeasures, session-fixation, timing attacks, account lockout - and ended up rewriting the whole thing.

Another famous one is the 2022 Uber internal breach incident, where a contractor’s password leaked and “MFA fatigue attack” (the technique of spamming MFA notifications until the user gives in) landed, and the attacker reached internal Slack/AWS/GCP. A clear case where the “MFA installed = safe” assumption collapsed, and an event that suddenly spread the importance of FIDO2 / Passkey phishing-resistance.

I myself also remember almost trying it as a junior thinking “I can probably write auth,” only to be stopped by a senior with “absolutely don’t self-build.” The reason “what you can learn by self-building is the lesson that you shouldn’t self-build” is said is because the feeling of “auth can be made like a CRUD relative” is an illusion only the writer has.

Self-built auth has a wide chasm between ‘works’ and ‘defends’. By the time you notice the chasm, production is already running.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Auth method (password / MFA / Passkey / SSO)
• MFA method (SMS / TOTP / Push / FIDO2)
• IDaaS adoption (Auth0 / Okta / Firebase / self-build)
• Social login (scope of support)
• Session design (Cookie / JWT / refresh)
• Password policy (length, leak detection)
• Agent auth (Service Account, API Key)

How to record decision reasons

Since auth platforms affect both security and user experience, it’s important to leave why you chose that method/product as an ADR (Architecture Decision Record). Below is an example.

Item	Content
Title	Adopt Auth0 (IDaaS) as authentication platform
Status	Approved
Context	Selecting the auth platform for a B2C SaaS. Social login (Google/Apple) support and mandatory MFA are requirements
Decision	Adopt Auth0 as IDaaS, delegating auth externally
Reasons	- Achieves password management, MFA, social login, and Passkey support without in-house implementation - Natively supports OIDC/SAML, making future SSO expansion easy - Built-in Breached Password Detection
Rejected alternatives	Firebase Authentication: limited custom claims management, hard to handle complex permission models. In-house implementation: operational load of password hashing, session management, and vulnerability response is too high
Result	Start with free tier (7,500 MAU); monitor monthly for paid-plan migration threshold

Auth-method changes affect all users, so successors need to understand “why IDaaS instead of in-house.” The greatest value of an ADR is that “why this choice was made” is clear at a glance when revisited later.

Summary

This article covered auth design, including the 3 auth factors, MFA, Passkey, SSO, social login, IDaaS selection, and modern auth design with both humans and AI agents in view.

Delegate to IDaaS, MFA standard + Passkey support, adopt SSO + OIDC, and keep agent auth short-lived and limited. That is the practical answer for auth design in 2026.

Next time we’ll cover authorization and IAM (RBAC, ABAC, ReBAC, least privilege).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.