> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/security/fido2-and-webauthn/fido2-and-webauthn-reference.md). # What OpenIAM's WebAuthn implementation does and does not do What OpenIAM's WebAuthn implementation does and does not do, the ceremony parameters that are fixed in the product, and everything 4.2.1.0 creates. ## What this covers The claims a security review will ask you to substantiate about [FIDO2 and WebAuthn](/administration-guide/security/fido2-and-webauthn.md): what the product implements, what it does not, which ceremony parameters are fixed with no field behind them, and the objects release 4.2.1.0 creates. Be clear about all of this before you promise anything. ## What OpenIAM supports, and what it does not The left column is what the product does; the right column is what an administrator usually assumes and does not get. | OpenIAM does | OpenIAM does not | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Register any WebAuthn authenticator the browser offers — a USB or NFC security key, a phone over the browser's cross-device flow, or a built-in platform authenticator such as Touch ID or Windows Hello | Restrict which of those a user may register. There is no attachment or model policy field | | Bind every credential to the hostname it was registered on, and reject an assertion presented at any other hostname | Offer an origin allow-list, a second permitted hostname, or any way to relax that | | Request an attestation statement and store it on the credential | Verify it. No trust anchors, no AAGUID allow-list and no FIDO Metadata Service check ship, so attestation is evidence you can read later, not a control that blocks an unapproved key | | Require user presence — a touch or a tap — on every assertion | Require user verification. A security key with no PIN set, tapped without unlocking anything, produces an assertion OpenIAM accepts | | Let a user hold several authenticators and name each one | Enforce a minimum. A user with exactly one authenticator and no other factor is one lost key away from a help-desk call | | Store a signature counter per credential and update it on every successful assertion | Report a counter regression anywhere you can see it | | Let the user register, rename and delete their own authenticators in SelfService | Give you a Webconsole screen showing who has registered what | **Passkeys, as the term is normally used, are not supported.** A passkey is a discoverable credential the user can pick from the browser before typing a username — "sign in with a passkey", autofill on the username field, no identifier entered at all. OpenIAM's Web Authentication page cannot start there: it requires the login first, uses it to look up which credentials to allow, and refuses to proceed without it, showing *Login is a required field*. The registration page does not ask for a discoverable credential either. A platform authenticator may still create one — Apple and Google devices often do regardless of what the site asks — and it will work perfectly well as a **second factor once the username is known**. It will not give you usernameless sign-in, and no setting turns that on. ## The ceremony parameters you cannot change These are fixed in the product. There is no field, no property and no script behind any of them. | Setting | Value | What it means for you | | ------------------------------------ | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Relying-party ID | The **host of the incoming request** | Not configurable. See [Relying party, origin, and what breaks across domains](/administration-guide/security/fido2-and-webauthn.md#relying-party-origin-and-what-breaks-across-domains) | | Expected origin | The **URL of the incoming request** | Not configurable. Same section | | Relying-party display name | `org.openiam.idm.fido.auth.rp.name`, ships `OpenIAM` | The only thing on this list you can set | | Credential algorithms offered | `ES256` and `RS1` | Almost every authenticator supports `ES256`, so this is rarely visible. `EdDSA` is not offered | | Registration timeout | `60000` ms | A user who walks away mid-registration must start again | | Attestation conveyance | `DIRECT` | The statement is requested and stored in `FIDO_AUTHENTICATOR.ATTESTATION_STATEMENT` — and **not verified**. It is forensic evidence, not admission control | | User verification, at registration | Not required | A key with no PIN set registers successfully | | User verification, at authentication | Not required; user **presence** is required | An assertion proves someone touched the authenticator. It does not prove they unlocked it | | Excluded credentials | The user's already-registered credentials | The browser refuses to register the same authenticator twice for one user, which is why a repeat registration on the same key is rejected by the browser rather than by OpenIAM | Two of these you can confirm yourself; the rest you cannot. The relying-party ID and origin are visible in the browser's WebAuthn prompt and in the registration request in the network trace. **User verification not being required is testable**: register a security key that has no PIN set, then sign in with it. If it succeeds without the key ever asking you to unlock anything, user verification is not being enforced — which is the shipped behaviour. The remaining rows cannot be confirmed from the Webconsole or from any log; treat them as product behaviour for this release, and ask OpenIAM support if a security review needs them attested. {% hint style="info" %} **What this means when you write the control objective.** Because user verification is not required, a `WEB_AUTH` step is a **possession** factor, comparable in strength to a hardware token the user carries — strong against phishing, weak against someone who picks up an unattended key. It is not, on its own, two factors. Chain it after `PASSWORD_AUTH` rather than offering it as a sibling root if you need both. {% endhint %} ## What 4.2.1.0 creates You do not build any of it; you attach it. | What ships | Value | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication level | `WEB_AUTH`, **Web authentication (FIDO)**, `REQUIRES_AUTHENTICATION='N'` | | Auth level grouping | `WEB_AUTH` | | IdP page | `/idp/auth-web` | | Rule | `DEF_WEB_AUTH_RULE`, **Def. Web authentication** — `WEB_AUTH` → `AUTHORIZATION_ACCEPT` | | SelfService menu resource | `SS_FIDO_KEYS`, `RESOURCE_TYPE_ID='MENU_ITEM'`, URL `/selfservice/security-keys`, displayed as **FIDO Authenticators**, added under `SELFCENTER` | | Credential storage | `FIDO_AUTHENTICATOR` — `ID`, `NAME`, `DESCRIPTION`, `USER_ID`, `COUNTER`, `COSE_KEY`, `AAGUID`, `CREDENTIAL_ID`, `ATTESTATION_STATEMENT`, `CLIENT_EXTENSIONS`, `AUTHENTICATOR_EXTENSIONS` | | Transport storage | `FIDO_AUTHENTICATOR_TRANSPORT` — `AUTHENTICATOR_ID`, `TRANSPORT` | | User column | `USERS.USER_HANDLE` | `NAME` was widened to 255 characters and `DESCRIPTION` added later in the same release, so a credential saved on an early 4.2.1.0 build carries a shorter name than one saved today. Two of those rows need a caveat. `FIDO_AUTHENTICATOR_TRANSPORT` exists but stays empty: OpenIAM does not record which transports an authenticator reported at registration, so you cannot tell a USB key from a phone by reading the table. And `USERS.USER_HANDLE` is present but is not what the ceremony uses — the WebAuthn user handle OpenIAM sends is the **OpenIAM user ID**, encoded for transport. Neither fact is visible in the Webconsole; the transport one you can confirm break-glass by counting rows in `FIDO_AUTHENTICATOR_TRANSPORT` after a registration and finding none, and the user-handle one only OpenIAM support can attest. ## The one property that is live {% hint style="warning" %} **Exactly one FIDO property exists in a fully migrated database.** `org.openiam.idm.fido.auth.rp.name`, type `String`, category `Authentication`, shipped value `OpenIAM` — the relying-party **display name** the browser shows during registration. It is cosmetic: changing it does not invalidate existing credentials, because the browser binds to the relying-party ID, not to the name. `org.openiam.idm.fido.auth.use.first.login` and `org.openiam.idm.fido.auth.rp.icon` were both seeded in 4.2.1.0 and both removed in **4.2.2.0**. They do not exist in a fully migrated database; if you find them, the database is behind. Setting either has no effect, and the message text for the first one (*Enable Web Authentication — If enabled, Web Authentication will be available on the login page*) still ships, which is why the property looks live when it is not. Whether Web Authentication is offered is decided entirely by the rule. Confirm all of this in one place: filter the `Authentication` category of **Administration → System Configuration** on `fido`. You should see exactly one key. {% endhint %} ## Related * [FIDO2 and WebAuthn](/administration-guide/security/fido2-and-webauthn.md) — the rollout, the recovery and the rollback * [Authentication levels, rules and capability flags](/administration-guide/security/authentication-providers-and-mfa/authentication-provider-reference.md) — `WEB_AUTH` among every level, and the shipped rules * [System property reference](/administration-guide/reference/system-properties.md) — the `Authentication` category *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/security/fido2-and-webauthn/fido2-and-webauthn-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.