Authentication Methods Explained: What Keycloak Supports

Authentication methods prove who a user is with something they know, have or are: passwords, one-time codes, passkeys, certificates and biometrics, often combined as MFA or reached through SSO. Keycloak supports passwords, OTP, WebAuthn passkeys, X.509 certificates, and SSO through OIDC, SAML and identity brokering.

This guide covers the types of authentication you will meet, then shows where each one lives in Keycloak: the authenticator that runs it, the required action that enrolls the user, and the admin console screen that configures it. It also separates methods from protocols, maps the NIST assurance levels to real authenticator choices, and compares the tradeoffs. The support statements are based on upstream Keycloak’s Server Administration Guide, which showed version 26.8.2 when we read it, so check the guide for your own version. If you first need the difference between proving who someone is and deciding what they may do, read why a valid login can still get a 403.

What are the main types of authentication methods?

Most methods fall into three factors: something you know (a password), something you have (a phone or security key) and something you are (a fingerprint). The NIST digital identity guideline, SP 800-63B, uses those same phrases when it explains how a physical authenticator and a biometric match combine. Its glossary defines multi-factor authentication (MFA) as a system that “requires more than one distinct type of authentication factor” (SP 800-63B, glossary).

Passwords

NIST describes a password as a secret the subscriber chooses and either memorizes or records, and it adds that “Passwords are not phishing-resistant” (SP 800-63B, Sec. 3.1.1). Keycloak hashes and salts passwords in its built-in database (Keycloak, password hashing), and its guide lists Argon2 as the default for non-FIPS deployments (Keycloak, hashing algorithm).

One-time codes

A one-time password (OTP) is a one-time secret obtained from a device or application the user holds (SP 800-63B, Sec. 3.1.4). Keycloak’s guide says a time-based code (TOTP) comes from the current time and a shared secret, and a counter-based code (HOTP) uses a shared counter instead (Keycloak, OTP policies). Codes sent by SMS are the common alternative, and the UK’s National Cyber Security Centre describes an SMS PIN as “the most widespread and well-understood second factor” but says it “is not the most secure option” (NCSC).

Passkeys and security keys

These methods use public key cryptography (FIDO Alliance), and at login the server sends “a challenge that the selected authenticator signs” (W3C WebAuthn Level 2, Sec. 5.5). FIDO2 is “an open authentication standard” that passkeys are built on (FIDO Alliance), and WebAuthn is the W3C’s “API for accessing Public Key Credentials” (W3C WebAuthn Level 2). Each credential “can only be accessed by origins belonging to that Relying Party” (W3C WebAuthn Level 2, Sec. 1), meaning the service that registers and authenticates the user (W3C, Relying Party). The FIDO Alliance says its standards provide “phishing-resistant authentication” (FIDO Alliance). You can also read FIDO2 Passwordless Authentication: How It Works in Keycloak and Keycloak Passkeys & WebAuthn: The Complete Guide.

Certificates

Certificate-based authentication uses the private key behind an X.509 certificate. In client-authenticated TLS (mutual TLS), the client signs with that key during the connection (SP 800-63B, Sec. 3.2.5). In our view it suits organizations that already run a certificate authority, since someone has to issue certificates and withdraw them. Keycloak can check revocation with CRLs, CRL Distribution Points or OCSP (Keycloak, X.509).

Biometrics

A fingerprint or face match is a factor, not a complete method. NIST says “A biometric characteristic is not recognized as an authenticator by itself” and requires a physical authenticator alongside it (SP 800-63B, Sec. 2). On the web, a biometric can unlock a passkey: the FIDO Alliance definition that Keycloak quotes says a user signs in “with the same process that they use to unlock their device (biometrics, PIN, or pattern)” (Keycloak, passkeys support). The WebAuthn specification adds that “Biometric data is not revealed to the WebAuthn Relying Party” (W3C WebAuthn Level 2, Sec. 14.3). You can also read Biometric Authentication: Methods, Risks and Keycloak Setup.

Tokens

With token-based authentication, the client sends a token along with its request. Keycloak’s guide describes services that “require an Access token (Bearer token)” to “authenticate a request” (Keycloak, audience support). In a browser login, the application receives its token after the user has signed in at Keycloak (Keycloak, authorization code flow), so that token follows one of the other methods here rather than replacing it.

SSO and federated login

Single sign-on (SSO) lets one login cover many applications. Federated login goes one step further by trusting another organization’s login: NCSC describes it as allowing “a customer to use their sign-in for an existing account in one trusted service to sign in to another new service” (NCSC). NCSC gives Apple, Facebook and Google as examples and notes this “may also be referred to as Social Login”, and Keycloak can also broker to “a business partner whose users need to access your services” (Keycloak, identity brokering). The user still proves who they are with a password or passkey, but at the other provider.

Passwordless

Passwordless is a category rather than a single method. The FIDO Alliance presents passkeys as passwordless authentication (FIDO Alliance), and NCSC calls magic links “a type of passwordless login” where the customer logs in “by clicking a link that has been emailed to their registered address” (NCSC). NCSC also warns that someone with access to a user’s phone “may be able to access the accounts associated with that phone, including email and SMS notifications” (NCSC), so a passkey and a magic link are not equal in strength even though both remove the password.

Which authentication methods does Keycloak support?

Keycloak runs authentication as a flow: an ordered list of steps called executions, each backed by an authenticator, which you edit under Authentication → Flows (Keycloak, authentication flows). A required action is a task that Keycloak makes the user complete at login, such as registering a credential (Keycloak, required actions). You can also read Building Custom Authentication Flows in Keycloak.

A few rows need more explanation. A directory changes where the password is checked rather than the step that asks for it: the form in the browser flow stays the same, but “Keycloak never imports passwords” and “Password validation always occurs on the LDAP server” (Keycloak, LDAP). Keycloak announced official passkey support for 26.4.0, after a preview available since 23.0.0 (Keycloak, passkeys support). The guide’s WebAuthn section mentions a biometric only as one way to unlock a passkey, “for example by using a PIN code or a fingerprint” (Keycloak, loginless WebAuthn), which is why biometrics have no row of their own beyond WebAuthn.

X.509 also depends on server setup, because Keycloak accepts a client certificate only “if you have configured the server to use mutual SSL authentication” (Keycloak, X.509). For services, the guide prefers service accounts with mutual TLS over the direct grant, which “may require sharing of the user certificate with client applications” (Keycloak, X.509).

Identity brokering deserves its own place in this matrix, because Keycloak delegates the login to an outside provider. The guide defines an identity broker as “an intermediary service connecting service providers with identity providers”, and when you use Keycloak this way it sits between your applications and the outside provider. The guide bases these providers on SAML v2.0, OpenID Connect v1.0 and OAuth v2.0, and lists social providers including Google, Microsoft, GitHub and GitLab (Keycloak, identity brokering). You can also read Keycloak Social Login: Google, Apple, and GitHub Setup and our identity providers feature page.

CIBA works differently from the other methods, because Keycloak delegates the login to “an external authentication entity” that authenticates the user through an authentication device (Keycloak, CIBA policy). You can also read Keycloak CIBA: Backchannel Authentication for Financial Services. For email links, we publish an open-source Apache 2.0 extension, keycloak-magic-link, for Keycloak 25 and 26.

To see what a realm is really running, you can read it with the Admin CLI. These commands, adapted from the guide’s examples, read the flows, the steps in the browser flow and the password policy:

kcadm.sh get authentication/flows -r demorealm
kcadm.sh get authentication/flows/browser/executions -r demorealm
kcadm.sh get realms/demorealm --fields passwordPolicy

You can set the realm’s passwordPolicy attribute from the same tool, in the form of the guide’s password policy example:

kcadm.sh update realms/demorealm -s 'passwordPolicy="length(12) and notUsername and passwordHistory(4)"'

What is the difference between an authentication method and a protocol?

In this guide, a method means how the user proves who they are, and a protocol means how that result travels between systems. Under those meanings OTP and passkeys are methods, OIDC and SAML are protocols, and JWT is a token format.

• OpenID Connect (OIDC) is “an interoperable authentication protocol based on the OAuth 2.0 framework of specifications” (OpenID Foundation). Keycloak’s guide describes browser applications redirecting the user to Keycloak and receiving tokens back (Keycloak, authorization code flow).
• SAML 2.0 is, in the words of Keycloak’s guide, “a similar specification to OIDC but more mature”, and it “exchanges XML documents” that are checked with XML signatures (Keycloak, SAML).
• JWT is “a compact, URL-safe means of representing claims” (RFC 7519). It is the format of a token rather than a way to log in, and you can inspect one with our JWT decoder.

This separation is useful in practice, because the application can stay on the same protocol while Keycloak runs the method, although you should still test how your application behaves when you change one. Keycloak’s guide gives Kerberos as an example: Keycloak and the application “communicate through OpenID Connect or SAML messages”, so the Kerberos login is “hidden from the application” (Keycloak, Kerberos).

Your app sends an OIDC or SAML request (1), Keycloak runs the flow, which is where the method happens (2), the result returns over the same protocol, as tokens for OIDC or an assertion for SAML (3), and an app that holds an access token, often a JWT, can call its API with it, and the API checks the token (4). A SAML sign-in returns an assertion rather than an access token, so a SAML app needs a separate step to get one before step 4.

How do NIST AAL levels map to Keycloak authenticators?

NIST grades authentication strength as Authenticator Assurance Levels (AALs) in SP 800-63B. The older revision 3 carries a banner saying it “has been superseded by NIST SP 800-63-4 as of August 1, 2025”, so the table below uses revision 4. The right-hand column is our own reading of how the guideline could apply, not a statement from NIST.

Three details matter when you read this table.

• User verification. By default, Keycloak sets User Verification Requirement to required for passwordless WebAuthn (Keycloak, loginless WebAuthn). NIST describes multi-factor cryptographic authentication as a key “that requires activation by a second authentication factor” (SP 800-63B, Sec. 3.1.7), and we read that device check as the second factor in the passkey case.
• Synced passkeys. NIST describes exportable keys as “usable at AAL2 or below” (SP 800-63B, Sec. 3.1.6.1), with added requirements in Appendix B, and it says “syncable authenticators SHALL NOT be used at AAL3” (SP 800-63B, AAL3 requirements).
• Hardware models. An AAGUID identifies an authenticator model, and if you set Acceptable AAGUIDs, “only those authenticators are valid to register new WebAuthn credentials” (Keycloak, WebAuthn).

Certificates can also reach a strong level, since NIST names client-authenticated TLS as a phishing-resistant protocol and gives PIV and CAC government smart cards as examples (SP 800-63B, Sec. 3.2.5). The X.509 section of Keycloak’s guide covers checks on the certificate, and we found nothing there about where the private key is stored, so that part depends on how you issue certificates. An AAL describes your whole system, including cryptography validation that NIST requires at AAL3 (SP 800-63B, AAL3 requirements), so a Keycloak setting alone does not make you compliant. For brokered logins, SP 800-63C defines Federation Assurance Levels.

Keycloak can also ask for a stronger level only when an action needs it. In a step-up flow, a Conditional - Level Of Authentication step defines numbered levels, and you map those to the Authentication Context Class Reference (ACR) values your apps request (Keycloak, step-up). Here is a request using gold, an example value you would map to level 2:

GET /realms/demorealm/protocol/openid-connect/auth?client_id=payments-app&response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&acr_values=gold

The guide says acr_values requests the level “as non-essential” (Keycloak, step-up) and that the acr claim is “also included in the access token and ID token” (Keycloak, ACR mapping), so your app should check the claim before it allows the sensitive action. A decoded token would carry something like this (the values are illustrative):

{
  "iss": "https://auth.example.com/realms/demorealm",
  "aud": "payments-app",
  "acr": "gold"
}

You can also read Step-Up Authentication with Keycloak: A Practical Guide.

What are the tradeoffs between authentication methods?

The phishing column below comes from the sources linked under the table. The user experience and running cost columns are our own general assessment, so weigh them against your users and team.

NIST explains the OTP and SMS rows: authenticators with “manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant” (SP 800-63B, Sec. 3.2.5), and the same section lists client-authenticated TLS as phishing-resistant. For magic links, NIST says “Phishing resistance requires single- or multi-factor cryptographic authentication” (SP 800-63B, Sec. 3.2.5) and “Email SHALL NOT be used for out-of-band authentication” (SP 800-63B, Sec. 3.1.3.1), so do not treat an emailed link as a second factor when you assess against AAL2. SMS is also a “restricted” authenticator, which means an organization using it has to accept that risk knowingly (SP 800-63B, Sec. 3.2.9).

Which authentication method should you use?

For workforce login, start with the identity provider your company already runs and broker it into Keycloak, so employees do not need another set of account details. Add security keys or passkeys for administrators and other sensitive roles, and consider Kerberos where desktop sign-in on a Windows domain already exists. X.509 fits when you already manage devices and a certificate authority.

For customer login, offer passkeys with a fallback, since not every user will have a suitable device. Social login can suit consumer apps whose users already have a provider account, and Keycloak can also broker to a business partner’s identity provider (Keycloak, identity brokering). NCSC advises “Providing your users with a choice of second factors” because that “will ensure you cover the widest customer base” (NCSC), so plan for several methods and their recovery paths from the start. Keycloak’s recovery codes give you one such path.

For services with no user at all, use the client credentials grant with a signed JWT or a certificate rather than a long-lived shared secret where you can.

FAQ

What are the five types of authentication?

The five come from vendor lists rather than from a standard we could find. WorkOS’s version, for example, names username and password, multi-factor, token-based, certificate-based and biometric authentication. That list mixes factors and combinations, so this guide also treats SSO and passkeys separately.

What are the three authentication factors?

The three factors are something you know, something you have and something you are (SP 800-63B). MFA needs more than one distinct type (SP 800-63B, glossary), so two things you know do not count.

Does Keycloak support biometric authentication?

Keycloak’s guide documents no biometric authenticator of its own. A user’s fingerprint can unlock a passkey through WebAuthn (Keycloak, loginless WebAuthn), and the WebAuthn specification says the biometric data is not revealed to the Relying Party (W3C WebAuthn Level 2, Sec. 14.3).

Does Keycloak support SMS or email one-time codes?

The Server Administration Guide documents no SMS or email code authenticator, so you would add one with a provider built on the Authentication SPI. The guide’s OTP section covers TOTP and HOTP with authenticator apps such as FreeOTP and Google Authenticator (Keycloak, OTP policies).

Is SSO an authentication method?

SSO is a way to reuse a login rather than a way to prove identity. The user still authenticates once with a method such as a password or passkey, and in Keycloak the Cookie step then recognizes the session for other applications (Keycloak, authentication flows).

Which authentication method is the most secure?

NIST’s highest level, AAL3, requires “a phishing-resistant authenticator” with “a non-exportable authentication key” (SP 800-63B, AAL3 requirements). Hardware security keys are one way to meet that, and our reading is that device-bound passkeys and certificates on hardware can be too.

What to do next

List the methods your apps need against the support matrix above, and note which ones need server-level work, such as mutual TLS for X.509. Then set the methods up on a managed Keycloak realm with Skycloak.

Sources

• Keycloak, Server Administration Guide, version 26.8.2, retrieved 2026-11-06, https://www.keycloak.org/docs/latest/server_admin/
• Keycloak, Server Developer Guide, Authentication SPI, retrieved 2026-11-06, https://www.keycloak.org/docs/latest/server_development/#_auth_spi
• Keycloak, “Passkeys support in upcoming Keycloak release (26.4)”, retrieved 2026-11-06, https://www.keycloak.org/2025/09/passkeys-support-26-4
• NIST, SP 800-63B-4, Authentication and Authenticator Management, retrieved 2026-11-06, https://pages.nist.gov/800-63-4/sp800-63b.html
• NIST, SP 800-63B revision 3, superseded, retrieved 2026-11-06, https://pages.nist.gov/800-63-3/sp800-63b.html
• NIST, SP 800-63C-4, Federation and Assertions, retrieved 2026-11-06, https://pages.nist.gov/800-63-4/sp800-63c.html
• W3C, Web Authentication Level 2, retrieved 2026-11-06, https://www.w3.org/TR/webauthn-2/
• FIDO Alliance, FIDO2 and passkeys, retrieved 2026-11-06, https://fidoalliance.org/fido2/
• OpenID Foundation, OpenID Connect, retrieved 2026-11-06, https://openid.net/connect/
• IETF, RFC 7519, JSON Web Token, retrieved 2026-11-06, https://www.rfc-editor.org/rfc/rfc7519
• NCSC, Authentication methods: choosing the right type, retrieved 2026-11-06, https://www.ncsc.gov.uk/guidance/authentication-methods-choosing-the-right-type
• WorkOS, The five different types of authentication, retrieved 2026-11-06, https://workos.com/blog/the-five-different-types-of-authentication