LAB 05: Multi Factor and
Passwordless Authentication

Lab Metadata

Lab Title and Description

From One Factor to None: Enforcing MFA and Then Going Passwordless with Passkeys

Everything so far has rested on a password. Lab 01 stored it, Lab 02 validated it through federation, Labs 03 and 04 moved the login to the IdP so that password reached only one hardened page. But a password entered on one hardened page is still a password: it can be phished, guessed, sprayed, and reused. This lab addresses that directly, in two moves. First, defence in depth: add a second factor so that stealing the password is no longer enough. Second, elimination: remove the password from the login entirely and replace it with a passkey, a credential that cannot be phished because it never leaves the user's device and refuses to work on the wrong website.

You will design a custom authentication flow in Keycloak, the same flow engine that runs the IdP login step of the Lab 04 authorization code flow, so every improvement here protects every client at once. You will enforce time based one time passwords (TOTP), generate the codes yourself from the command line with oathtool so the algorithm is not a mystery, then register a WebAuthn passkey and configure a passwordless flow. The centrepiece is a demonstration, not a claim: you will simulate the credential phishing that defeats passwords and even defeats TOTP, and then watch the passkey refuse to authenticate against the wrong origin, because origin binding is built into the protocol itself.

By the end you will have moved a user up the NIST SP 800-63B assurance ladder from a single memorised secret to a phishing resistant authenticator, and you will be able to explain, from your own captured evidence, exactly which attacks each rung stops. Estimated completion time is 3 to 3.5 hours.

Prerequisites

3.1 Prior labs required

docker start ib-openldap ib-keycloak ib-phpldapadmin

# Confirm the realm answers and asmith can still authenticate at the IdP
curl -s http://localhost:8081/realms/northgate/.well-known/openid-configuration | jq -r '.issuer'
# Expected: http://localhost:8081/realms/northgate

3.2 System requirements

3.3 Required tools and versions

3.4 Installation commands

# oathtool implements the same TOTP algorithm as any authenticator app.
# Generating codes yourself demystifies the second factor.
sudo apt-get update && sudo apt-get install -y oathtool

brew install oath-toolkit

3.5 Verification of tools

# Generate a TOTP from a known test secret. The value changes every 30s.
oathtool --totp -b "JBSWY3DPEHPK3PXP"

Real World Problem Statement

This lab solves the problem that every prior lab quietly deferred: the password is a single point of failure, and the most valuable one in the estate. Centralising authentication at the IdP concentrated risk as much as it concentrated control; the IdP login page now guards every federated application at once, so the strength of that single authentication event is the strength of everything. Passwords fail here in ways no amount of complexity policy fixes. They are phished at scale, sprayed against exposed IdPs, and reused from breach corpora. Verizon's breach reporting has for years put stolen or weak credentials at or near the top of initial access vectors, and the attacks that dominate now, adversary in the middle phishing, defeat not just passwords but also the one time codes many organisations added on top.

The answer arrives in two tiers. Multi factor authentication requires something beyond the password, so a stolen password alone is insufficient. But not all factors are equal: TOTP and push notifications are phishable, because a convincing fake site can relay the code or the approval in real time. The phishing resistant tier, WebAuthn and passkeys built on FIDO2, closes that gap by binding the credential cryptographically to both the user's device and the exact website origin, so the credential simply will not respond to an impostor domain. This is why regulators, cyber insurers, and NIST SP 800-63B now distinguish phishing resistant authenticators as a category of their own, and why a senior IAM architect must be able to design, enforce, and explain the whole ladder.

Why it matters, across four dimensions

Concrete scenario

Northgate Financial suffers a near miss: an adversary in the middle phishing campaign harvests an analyst's password and live TOTP code through a lookalike login page and briefly accesses an internal application before the session is spotted and killed. The board mandates phishing resistant MFA for all staff, with a phased path: enforce a second factor immediately for everyone, and move privileged and finance users to passwordless passkeys within the quarter. Your task in this lab is the reference implementation: a custom Keycloak authentication flow that requires a second factor, TOTP enrolment and enforcement, WebAuthn passkey registration, a passwordless flow for eligible users, and a documented demonstration that the passkey defeats the exact adversary in the middle attack that got through, providing the evidence the board's mandate requires.

Skills Mapped to Production Solutions

Architecture Overview

Component breakdown

Data flow (login under the custom flow)

1. The client delegates to the IdP: as in Lab 04, the application sends the user to Keycloak's login, so the flow you build here protects every client automatically. Why: authentication policy belongs at the IdP, defined once and enforced everywhere.
2. First factor, the password: Keycloak validates the password by LDAP bind. Why: this is the Lab 01 to Lab 02 foundation, now demoted from the whole of authentication to merely its first step.
3. Conditional evaluation: the flow checks whether the user must present a second factor, always in the board's mandate, and applies stronger rules for members of privileged groups. Why: uniform enforcement with risk based escalation is how real policies are shaped.
4. Second factor or passwordless: the user presents a TOTP code, or completes a WebAuthn assertion with a passkey; in the passwordless flow the passkey replaces the password step entirely. Why: the assurance level of the session is set here, and for passkeys the origin binding is enforced by the browser and the authenticator, not by Keycloak's good intentions.
5. Tokens issued: only after the full flow succeeds does Keycloak complete the authorization code exchange from Lab 04 and issue tokens carrying the authentication context. Why: downstream applications can read how strongly the user authenticated and make their own risk decisions.

Security considerations

Step by Step Implementation

# Paste the base32 secret Keycloak displayed. oathtool computes exactly
# what any authenticator app would show for it, right now.
SECRET="PASTE_THE_BASE32_SECRET_HERE"
oathtool --totp -b "$SECRET"
# Type the six digit result into the Keycloak setup page to complete
# enrolment. If it rotates before you submit, run oathtool again.

Testing and Validation

The centrepiece: demonstrate why the passkey defeats the phishing that TOTP cannot

This is the evidence the board's mandate demanded. You will show, in your own environment, that a password and a TOTP code can both be relayed to a hostile origin, while a passkey cannot, because the authenticator refuses to sign for the wrong site.

# CONCEPT: adversary in the middle phishing works by hosting a lookalike
# site that relays everything the user types to the real IdP in real time.
# Passwords and TOTP codes are just strings, so they relay perfectly.
# A WebAuthn assertion is signed over the ORIGIN the browser is on, so a
# signature made at the fake origin is invalid at the real one.

# We demonstrate the origin binding directly with the virtual authenticator.

# STEP 1: In developer tools, WebAuthn pane, note that the registered
# credential is bound to rpId matching localhost (the real IdP origin).

# STEP 2: Simulate the wrong origin. Add a hosts entry so a different
# name points at the same Keycloak, imitating a lookalike domain:
echo "127.0.0.1 wrong-origin.local" | sudo tee -a /etc/hosts

# STEP 3: Try the passwordless (passkey) login via the lookalike name:
#   http://wrong-origin.local:8081/realms/northgate/account
# The browser will send origin http://wrong-origin.local:8081 in the
# WebAuthn assertion. Keycloak's relying party ID expects localhost.
# Expected: the WebAuthn step FAILS. The authenticator/browser will not
# produce a usable assertion for a mismatched origin, and Keycloak
# rejects it. The passkey cannot be phished to the wrong site.

# STEP 4 (contrast): via the SAME wrong-origin name, the password + TOTP
# login would proceed to collect both, and in a real relay attack those
# captured strings would work against the genuine localhost IdP. The
# difference is categorical, not a matter of degree.

# CLEANUP the hosts entry afterwards:
sudo sed -i '/wrong-origin.local/d' /etc/hosts

End to end scenario: the assurance ladder for one user

# RUNG 1: password only. Disable the MFA flow briefly (bind default
# browser flow) and log in. Works with one factor. AAL1. Note it, revert.

# RUNG 2: password + TOTP (northgate-mfa-browser bound). Log in; both
# required. AAL2 with a memorised secret plus OTP device.

# RUNG 3: password + passkey. Stronger: the second factor is now
# phishing resistant.

# RUNG 4: passkey only (northgate-passwordless). No password exists in
# the login at all. With user verification required, this is AAL2 with a
# phishing resistant authenticator and nothing to phish or reuse.

# For each rung, note in your portfolio which attacks it stops, using
# the factor ladder from the Section 6 diagram.

Negative and resilience tests

# TEST N1: wrong TOTP is refused (Phase 2.2 negative). Correct password,
# wrong code: denied.

# TEST N2: TOTP time drift. Generate a code, wait 90 seconds, then submit
# the stale code. Expected: refused. TOTP codes are valid only within a
# small window around their period (Keycloak default tolerates 1 step).
# This is the drift issue behind real enrolment tickets when device
# clocks are wrong.
oathtool --totp -b "$SECRET"   # note it, wait 90s, then try to submit it

# TEST N3: lockout interaction. Enable brute force detection under
# Realm settings, Security defenses, Brute force detection. Attempt
# several wrong passwords for a user. Expected: temporary lockout,
# independent of MFA. MFA and lockout are complementary controls.

# TEST N4: recovery reality. In the admin console, delete asmith's OTP
# and webauthn credentials, then attempt login. Expected: Keycloak forces
# re-enrolment via the required action. This models the help desk path
# when a user loses their authenticator, and why a fallback must exist
# BEFORE passwordless enforcement.

Common failure modes and solutions

Security Analysis

What makes this implementation secure

• A stolen password is no longer sufficient: the custom flow enforces a second factor for all users, proven by the wrong code denial and the enforced login.
• The phishing resistant tier is genuinely categorical: the WebAuthn assertion is bound to the origin, so a credential registered for the real IdP cannot be exercised against a lookalike, which the wrong origin test demonstrated.
• Passwordless removes the phishable secret entirely: with user verification required, a single passkey step meets AAL2 while leaving nothing to phish, spray, or reuse.
• Risk based escalation applies stronger authentication to privileged groups, carrying the Lab 01 authorisation model into authentication strength.
• Each factor combination maps to a documented NIST SP 800-63B assurance level, so the design is defensible to audit rather than asserted.
• MFA and brute force lockout were shown to be complementary, and recovery was tested rather than assumed.

What is intentionally simplified for the lab

• Everything runs over HTTP on localhost; production WebAuthn requires HTTPS (browsers permit localhost as a special case), and the relying party ID must be the real domain.
• The phishing demonstration uses one Keycloak behind two names to show origin binding, not a full two server relay proxy.
• Account recovery and fallback authenticators are discussed and tested minimally, not designed to production depth.
• TOTP uses Keycloak defaults (SHA-1, 6 digits, 30s, 1 step drift) rather than a tuned policy.
• The passwordless flow is opt in for testing rather than staged across a real population with a pilot and comms plan.

Production hardening recommendations

Cleanup Instructions

Option A: pause the lab, keep everything (recommended)

docker stop ib-keycloak ib-openldap ib-phpldapadmin
docker start ib-openldap ib-keycloak ib-phpldapadmin   # to resume

Option B: revert authentication changes cleanly

# In the admin console (realm northgate):
#   Authentication, Flows: bind the default "browser" flow again if you
#   want to remove MFA enforcement, or keep northgate-mfa-browser bound
#   (recommended: MFA is a good default to carry into later labs).
#   Users, asmith, Credentials: remove test otp/webauthn credentials if
#   you want a clean slate for re-running the lab.

# Remove the hosts entry if the phishing demo left one behind:
sudo sed -i '/wrong-origin.local/d' /etc/hosts

# Disable the virtual authenticator in developer tools when finished.

Recommended Learning Links

• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management (the AAL definitions and phishing resistance)
• RFC 6238: TOTP, Time Based One Time Password Algorithm
• RFC 4226: HOTP, HMAC Based One Time Password Algorithm
• W3C Web Authentication (WebAuthn) Level 2
• FIDO Alliance specifications (CTAP2, passkeys)
• Keycloak Server Administration Guide: WebAuthn
• Keycloak Server Administration Guide: Authentication flows
• Passkeys overview (FIDO Alliance)

Portfolio Publishing Guide: Evidence of a Phishing Resistant Design

Lab 05 is the most quotable lab yet for a portfolio, because it ends in a demonstration with a clear, board level takeaway: passkeys stop the phishing that passwords and codes do not. The assets are your custom flow, the assurance ladder mapping, and the phishing resistance write up. None of it contains secrets that need heavy redaction, but authenticator details still deserve care.

12.1 Collect the artefacts

cd ~/identity-bytes-architect-labs
mkdir -p lab-05-mfa-passwordless/{docs,config,evidence,screenshots}

# Export the northgate realm again; the custom flows travel in it.
docker exec ib-keycloak /opt/keycloak/bin/kc.sh export \
  --dir /opt/keycloak/data/export --realm northgate --users skip
docker cp ib-keycloak:/opt/keycloak/data/export/northgate-realm.json \
  ./northgate-realm.json

# Sanitise (blank any client secrets) before publishing, as in Lab 02:
jq '(.clients[]? | select(has("secret")) | .secret) = "REDACTED"' \
  northgate-realm.json > lab-05-mfa-passwordless/config/northgate-realm.sanitised.json
rm northgate-realm.json

# Write the assurance ladder as a short markdown table for evidence.
cat > lab-05-mfa-passwordless/evidence/assurance-ladder.md << 'EOF'
# Authenticator assurance ladder (as configured and tested)

| Rung | Factors | Stops | NIST AAL (approx) |
|------|---------|-------|-------------------|
| 1 | Password only | Nothing modern (phish, spray, reuse) | AAL1 |
| 2 | Password + TOTP | Reuse, spraying | AAL2 (not phish resistant) |
| 3 | Password + Passkey | Also real-time phishing | AAL2 |
| 4 | Passkey only (UV required) | Nothing to phish or reuse | AAL2, phishing resistant |

Demonstrated: a passkey registered for the real origin could not be
exercised against a lookalike origin, because the WebAuthn assertion is
origin-bound. Password and TOTP, being strings, relay to any origin.
EOF

12.2 Add Lab 05 to the repository and push

cat > lab-05-mfa-passwordless/README.md << 'EOF'
# Lab 05: Multi Factor and Passwordless Authentication

Part of my Identity Bytes Senior IAM Architect lab series (IB-SIA-05).
Hardens the IdP login step that protects every client from Lab 04,
moving one user from a single password up to a phishing resistant passkey.

## Problem this solves
Centralising authentication concentrated risk on one login event. A
stolen password there compromises everything, and the current wave of
adversary in the middle phishing defeats not just passwords but also
TOTP. The fix is a second factor, and then a phishing resistant one.

## What I built
- A custom Keycloak authentication flow (cloned, edited, bound) enforcing
  a second factor for all users
- TOTP enrolment and enforcement, with codes generated from the command
  line via oathtool to show the RFC 6238 algorithm
- WebAuthn passkey registration using the browser virtual authenticator
- A passwordless flow authenticating with a passkey alone (user
  verification required)
- Per group conditional step up reusing the Lab 01 finance/admin groups

## The demonstration
Showed that a passkey registered for the real origin cannot be used
against a lookalike origin, because the WebAuthn assertion is origin
bound, while a password and TOTP code relay to any origin. This is why
passkeys are phishing resistant and TOTP is not: a categorical
difference, not an incremental one.

## Assurance ladder
Mapped each factor combination to a NIST SP 800-63B AAL. See
evidence/assurance-ladder.md.

## Skills demonstrated
Authentication flow design, TOTP and WebAuthn/FIDO2, passwordless,
conditional/risk based MFA, and assurance level justification.

Full guide: docs/IB-SIA-05-mfa-passwordless.html
EOF

cp <PATH_TO>/IB-SIA-05-mfa-passwordless.html lab-05-mfa-passwordless/docs/
git add .
git commit -m "Lab 05: custom MFA flow, TOTP, WebAuthn passkeys, passwordless, phishing resistance demo"
git push
# Track index: | 05 | MFA, TOTP, WebAuthn passkeys, passwordless | Complete |

12.3 Share it on LinkedIn

Attach the factor ladder from the Section 6 diagram, or a screenshot of the passwordless login completing with no password field, because a passwordless login is a striking image for a general audience. GitHub link in the first comment. A draft in the Identity Bytes style:

Same cadence: Tuesday to Thursday morning UK time, replies within two hours, hashtags at the end (#IAM #MFA #Passkeys #FIDO2 #CyberSecurity), and a comment linking the earlier labs so the series compounds.

12.4 Interview leverage from this lab

This lab evidences the identity security baseline lines of the target role, MFA, passwordless, passkeys, mTLS adjacent thinking, and Zero Trust, and it arms you for the question that separates senior from mid level candidates: not "do you use MFA" but "which MFA, and why". You can answer that a push or OTP factor is phishable and a FIDO2 passkey is not, and then explain the mechanism, origin binding, from a demonstration you ran. When the follow up is about rolling passwordless out safely, you can talk about staged enrolment, recovery design, and per group targeting because you built the conditional flow that does it.