Understanding Authentication with Keycloak

Overview

Authentication is the process of verifying that users are who they claim to be before granting access to resources. It sounds simple, but "authentication" is an umbrella term that hides a lot of nuance: a password, a one-time code, a fingerprint, and a passkey are all authentication, yet they offer very different levels of security and very different user experiences.

A public customer portal, an internal admin console, and a partner federation each call for a different answer.

The sections below build up the vocabulary to tell them apart; factors, their combinations, the assurance levels that grade them and map each one to a method you can configure on Keycloak. Every method has its own dedicated page with step-by-step configuration, linked throughout and gathered in the synthesis table at the end.

The three authentication factors

Every authentication method relies on one or more factors, grouped into three categories. This is the foundational vocabulary, and it is shared by the main security frameworks (the French ANSSI, the EU eIDAS regulation, and the US NIST guidelines all use it):

Factor category	What it is	Examples	Cloud-IAM page
Something you know	A secret the user memorizes	Password, PIN, security question	Username & Password
Something you have	A device or object the user possesses	Authenticator app, email/SMS one-time code, hardware security key	Email or SMS OTP, Magic link
Something you are	A physical trait of the user	Fingerprint, facial recognition	WebAuthn / passkeys

Combining factors: SFA, 2FA, MFA

Once you understand factors, the acronyms fall into place.

• SFA (Single-Factor Authentication) — authentication with one factor only. A username and password is the classic example.
• 2FA (Two-Factor Authentication) — two factors from two different categories. A password (something you know) followed by an authenticator-app code (something you have) is 2FA.
• MFA (Multi-Factor Authentication) — two or more factors from different categories. 2FA is the most common form of MFA.

The category requirement is the part people get wrong. A password and a PIN is not 2FA: both are something you know, so they share the same weakness. An attacker who can phish or guess one kind of memorized secret can go after both with the same playbook. Genuine multi-factor authentication forces an attacker to defeat two different kinds of proof.

Phishing-resistance is a separate axis

Adding factors raises the bar, but it does not automatically make authentication phishing-resistant. A password combined with an SMS code is MFA, yet both can still be captured by a convincing fake login page or intercepted, the SMS channel in particular is exposed to SIM-swapping attacks.

European and US authorities converge on this point. The ANSSI explicitly notes that multi-factor authentication does not automatically qualify as strong authentication, and advises against codes delivered over insecure channels such as SMS, recommending cryptographic protocols (FIDO2, certificates) instead. The NIST guidelines (SP 800-63B-4, July 2025) similarly downgrade email and SMS one-time passwords and promote passkeys.

This distinction number of factors versus resistance to phishing, is what makes passkeys the direction the industry is moving toward.

Assurance levels: a reference frame

To match an authentication method to a use case without relying on subjective judgment, it helps to lean on the assurance-level frameworks published by recognized authorities. They grade authentication strength on a scale, so you can map the risk of your application to the strength you should require.

eIDAS (European Union)

The eIDAS regulation defines three levels of assurance: Low, Substantial, and High. Detailed in Implementing Regulation (EU) 2015/1502, which draws on the ISO/IEC 29115 standard (while differing from it on some points, notably identity proofing). Substantial requires at least two authentication factors from different categories; High additionally requires protection against attackers attempting to duplicate or tamper with the authentication process; typically cryptographic, hardware-backed methods.

ANSSI / CNIL (France)

The guide "Recommandations relatives à l'authentification multifacteur et aux mots de passe" (ANSSI, with CNIL contribution) is the French reference. Its headline recommendations: run a risk analysis before choosing a method, prefer multi-factor authentication, prefer a possession-based factor, and adapt password robustness to the context. On biometrics, the CNIL's multi-factor authentication recommendation goes further: an inherence factor carries specific risks for individuals and cannot be imposed without an alternative a possession factor, for instance and its use as personal data falls under the GDPR.

NIST (United States), for international context

The NIST guidelines (SP 800-63B-4) define three Authenticator Assurance Levels: AAL1 (single-factor permitted), AAL2 (multi-factor required), and AAL3 (hardware-based, phishing-resistant authenticator required).

Cloud-IAM won't pick a level on your behalf, the right one depends on your own risk analysis, but our team can help you define it.

Passwordless authentication

Passwordless authentication removes the something you know factor entirely: there is no password to phish, leak, or reuse.

A clarification worth making early, passwordless is not automatically multi-factor, and it is not synonymous with passkeys. A magic link sent by email is passwordless too, it relies on a single possession factor (access to the mailbox). Passkeys are the passwordless method gaining the most traction, but they are one option among several.

Passkeys and WebAuthn

Passkeys are becoming an industry norm, and the vocabulary is often muddled. WebAuthn / FIDO2 is the underlying standard, the W3C/FIDO Alliance specification for public-key authentication, while a passkey is the user-facing experience built on it.

Under the hood, a passkey is a public/private key pair whose private half never leaves the user's device, so there is no shared secret to intercept; that makes it phishing-resistant by design, and it can serve either as a first factor replacing the password or as a second factor on top of one. Keycloak supports passkeys natively and, since Keycloak v26.4, integrates them directly into the login forms see Passwordless Authentication with WebAuthn for the details and setup.

Adaptive and step-up authentication

So far we have treated authentication as a fixed gate. In practice, the level of scrutiny can and often should vary with the context.

Adaptive authentication

Adaptive authentication adjusts the requirement based on risk signals: the user's IP address, device fingerprint, geolocation, time of day, or anomalies like impossible travel (a login from Paris ten minutes after one from Tokyo). A returning user on a known device on the corporate network might pass with a single factor, while the same account seen from an unfamiliar country, a new device, or a flagged IP range is challenged for a second or blocked outright. The aim is to keep friction low for routine logins and raise it only when something looks off.

Step-up authentication

Step-up authentication raises the requirement at the moment of a sensitive action, rather than at login. A user already signed in with a password can browse freely, but is asked to re-prove their identity with a passkey, an OTP, or a biometric check before a higher-stakes operation: confirming a payment or wire transfer, changing account or security settings, viewing sensitive records, or granting admin access. The session stays low-friction until the moment the risk actually rises.

Step-up authentication exists natively in Keycloak through the LoA mechanism, but the native implementation is rigid and non-trivial to configure. Adaptive authentication is not part of Keycloak's native feature set at all. Through Cloud-IAM, both are made straightforward by the Adaptive Auth extension from the Cloud-IAM Extensions Catalog.

Re-authentication

Closely related to step-up is re-authentication: asking a user to prove their identity again on an existing session. This can be triggered by a new sensitive action, after a period of inactivity, or before an administrative operation. It limits the window in which a hijacked or unattended session can be abused.

Keycloak supports it natively through the ACR to LoA Mapping configured per realm and enforced with the Conditional - Level of Authentication flow and/or the client.

SSO and Social Login

These two are frequently mistaken for authentication methods or security levels. They are neither.

Single Sign-On (SSO)

SSO is a session experience: the user authenticates once and then accesses multiple applications without logging in again. SSO says nothing about how strongly the user authenticated, for example you can have weak SSO (a single password) or strong SSO (a passkey) It is orthogonal to the factors and levels discussed above.

Social login

Social login is a specific case of federation where the external identity provider is a consumer platform: Google, Facebook, Apple, and similar. The user authenticates with their existing account, and your application leverages that identity.

Identity Provider brokering and social login are natively supported. See Social login and Identity Provider (OIDC).

Account recovery and fallback

A point that is easy to overlook when designing a flow: what happens when a factor is lost?

A passkey lives on a device that can be broken or replaced; a hardware key can be misplaced; a phone running an authenticator app can be wiped. If there is no recovery path, a lost factor means a locked-out user and a support burden.

Designing authentication therefore means designing fallback at the same time: recovery codes, a secondary registered factor or an assisted-recovery procedure. The trade-off is real, since a weak recovery path can quietly undermine an otherwise strong primary method an attacker will always target the weakest link. Keycloak supports recovery codes and multiple registered credentials per user; the MFA and WebAuthn pages cover the practical setup.

How this maps to Keycloak

The table below is the quick-reference view: each method, the factor category it belongs to, whether it is natively supported on Cloud-IAM Managed Keycloak, and where to find its configuration page.

Method	Factor category	Typical role	Support on Cloud-IAM	Cloud-IAM page
Username or email + password	Something you know	SFA	Native	Username & Password
Authenticator app (TOTP / HOTP)	Something you have	2FA / MFA	Native	MFA
Email OTP	Something you have	SFA or 2FA	Cloud-IAM extension	Email or SMS OTP
SMS OTP	Something you have	SFA or 2FA	Cloud-IAM extension	Email or SMS OTP
Magic link	Something you have	SFA	Cloud-IAM extension	Magic link
FIDO2 security key (e.g. YubiKey)	Something you have	SFA or 2FA	Native	Passwordless WebAuthn
Passkey / WebAuthn	Something you have + something you are	SFA or 2FA	Native	Passwordless WebAuthn
Windows Hello / platform biometrics	Something you have + something you are	SFA or 2FA	Native	-
LDAP / Active Directory	Federation	SFA	Native	Identity Provider (OIDC)
Social login	Federation	Delegated	Native	Social login
Identity Provider (OIDC)	Federation	Delegated	Native	Identity Provider (OIDC)
SAML 2.0 (Identity Provider)	Federation	Delegated	Native	-