WebAuthn / FIDO2 Authentication for ILIAS

This feature request outlines the framework for integrating WebAuthn/FIDO2 into the ILIAS core. A separate roadmap is provided below as a downloadable companion document and contains the detailed implementation perspective, including architectural details, phased rollout considerations, and the consideration of an initial plugin-based introduction for testing and practical evaluation before or alongside core integration.

1 Initial Problem

ILIAS currently supports several ways of validating user identities, including authentication against the local ILIAS database as well as integration with external authentication sources and mechanisms such as LDAP, Shibboleth, OpenID Connect, and Apache-based external authentication setups. However, ILIAS does not currently provide native WebAuthn/FIDO2 authentication in the core as a built-in browser-based method for passkeys, platform authenticators, or hardware security keys.​

This gap matters both for usability and for security. Password-based sign-in remains common, but it introduces friction on mobile devices, depends heavily on password quality and reuse behaviour, and remains vulnerable to phishing and credential theft in ways that WebAuthn is specifically designed to reduce.​

Modern users increasingly expect sign-in experiences based on passkeys, device biometrics, or security keys rather than repeated manual password entry. On current platforms, these methods are available directly in browsers and operating systems, but without native ILIAS support they can only be used indirectly through external identity infrastructure if such infrastructure is available and configured accordingly.​

The purpose of this feature request is therefore to introduce WebAuthn/FIDO2 as a native authentication capability in the ILIAS core. The goal is to enable phishing-resistant, browser-native authentication based on standards that are already established across major platforms, while integrating the feature into existing ILIAS login, account, administration, and security structures in a way that is understandable and operable for institutions.

2 Conceptual Summary

WebAuthn/FIDO2 authentication should be integrated into the ILIAS authentication framework as a core-supported sign-in method alongside existing local and externally integrated authentication options. The feature should enable users to register WebAuthn credentials in their ILIAS account and to use those credentials for secure authentication in supported browsers.​

From a product perspective, the feature covers two closely related areas. First, it should support passwordless or password-reduced sign-in based on passkeys, platform authenticators, or roaming security keys where the local installation decides to offer such a workflow. Second, it should establish the basis for using the same credential type in security-sensitive confirmation or additional verification scenarios where this is later desired. The feature request describes both areas conceptually, but the main focus remains the introduction of native WebAuthn support itself rather than the full redesign of all authentication flows in ILIAS.​

The implementation should support the authenticator classes users are most likely to encounter in practice:

At a conceptual level, the feature should provide the following:

It should not be assumed that every institution will adopt WebAuthn in the same way. Some installations may initially use it as an additional sign-in option alongside passwords and external authentication systems. Others may aim for a stronger passkey-based strategy over time. The implementation should therefore be designed so that it is valuable as an incremental addition without forcing a single deployment model on all ILIAS installations.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

3.2.1 Login Page

A new WebAuthn sign-in entry point should be added to the ILIAS login page. This entry point should be understandable to non-technical users and should use language that describes the expected action rather than relying solely on standards terminology. Labels such as “Sign in with Face ID, Fingerprint or Security Key” are suitable because they communicate the concrete sign-in action more directly than labels based only on “WebAuthn” or “FIDO2”.

The WebAuthn entry point should be positioned so that it is easy to discover, especially on mobile devices, without disrupting existing login methods. It should be visually clear that WebAuthn is a valid sign-in path, while conventional login remains available where needed. If the installation offers multiple sign-in methods, the design should help users understand that they are choosing between parallel authentication paths rather than being forced into an unfamiliar process.​

The login page should also handle common environment differences appropriately:

The purpose of this interface change is not merely to add another button. It is to make a standards-based passwordless sign-in option visible and understandable to users who may already be familiar with passkeys on their devices but not with WebAuthn terminology.

3.2.2 User Account Settings - Sign-In Options

The current “Change Password” area in the user account should evolve into a broader “Sign-In Options” area. This reflects the fact that authentication in ILIAS should no longer be represented only as password management, but as a broader set of available sign-in methods.​

Within this area, password management can remain available as one sub-area, while a dedicated WebAuthn-related sub-area should allow users to manage their registered credentials. This area should provide a clear and understandable self-service interface for users who want to add a passkey or security key, inspect their registered credentials, rename them, or remove them.​

The user-facing credential management area should include at least:

3.2.3 Administration – WebAuthn / FIDO2

A dedicated administration area should be introduced under the existing authentication and registration settings. This area should allow institutions to activate the feature and adapt it to their environment without needing to modify code or rely on undocumented behaviour.

Setting	Default	Description
Enable WebAuthn authentication	Off	Master switch for the feature
Allow passwordless login (primary auth)	Off	Enables WebAuthn as a standalone login method without password
Allow as second factor (2FA)	Off	Enables WebAuthn as a step-up after password login
Allowed authenticator types	Platform + Roaming	Restrict to platform authenticators only, roaming only, or both
Require user verification	On	Enforces userVerification: "required" (biometric/PIN, not just presence)
Relying Party ID (rpId)	(host name)	FIDO2 Relying Party Identifier; defaults to ILIAS hostname
Relying Party Display Name	(site name)	Human-readable name shown in authenticator UI
Maximum credentials per user	10	Prevent credential accumulation abuse

This configuration should be designed carefully because WebAuthn is sensitive to deployment context. Incorrect domain configuration or unclear activation rules could lead to confusing user behaviour and support issues even if the core authentication logic is technically correct.

3.3 New User Interface Concepts

The registration and login flows use browser-native WebAuthn UI, which cannot be styled by ILIAS (browsers render biometric/PIN dialogs natively for security reasons). No new ILIAS UI Kitchen Sink components are required for the feature itself.

However, the surrounding ILIAS interfaces still matter greatly. Users need clear entry points, understandable labels, comprehensible fallback messaging, and an account interface that makes credential management feel trustworthy rather than obscure.

3.4 Accessibility Implications

Accessibility must be considered for all ILIAS-controlled parts of the implementation. Buttons, links, forms, and credential-management tables must remain operable via keyboard and understandable to assistive technologies.

At the same time, the browser-native or operating-system-native authenticator prompts are outside the direct design control of ILIAS. Therefore a realistic distinction has to be made: ILIAS is responsible for the accessibility of its own surrounding interface and fallback logic, while the accessibility of the native WebAuthn prompt depends on the browser and platform implementation.​

Users who cannot use a specific biometric modality must not be left without a route through the sign-in process. Where WebAuthn is offered, the broader sign-in design should continue to allow practical alternatives, such as passwords or other suitable authenticators, depending on institutional policy and system configuration.

4 Additional Information

4.1 Involved Authorities

4.2 Technical Aspects

WebAuthn operates as a challenge-response process involving three parties: the ILIAS backend as the relying party server, the user’s browser as the WebAuthn client, and an authenticator such as a built-in platform authenticator or an external FIDO2 security key. During registration, a credential is created and the public-key material needed for later verification is associated with the user account. During authentication, the authenticator proves possession of the credential by signing a challenge that the server can verify.​

The private key remains on the authenticator or in the associated secure platform environment and is not transmitted to ILIAS. 

Within ILIAS, this capability should not be treated as an isolated add-on. It should be integrated into the existing login architecture, user-account management, session handling, and administrative configuration structures so that it behaves like a coherent core authentication feature rather than a disconnected plugin concept.

4.3 Privacy

Biometric data is never stored by ILIAS. In WebAuthn-based authentication, biometric matching is performed locally by the device or authenticator platform, while ILIAS stores credential-related information needed for registration and verification rather than raw biometric templates.

Users should be able to manage and delete their registered credentials within their account, and administrative deletion must also be possible where appropriate for support or security reasons. When an ILIAS account is deleted, the associated WebAuthn credential records should also be removed in accordance with normal account and data lifecycle handling.

4.4 Security

This feature introduces security-sensitive functionality and therefore requires an explicitly documented security concept.

The implementation must ensure, among other things, that challenges are generated securely, responses are validated correctly, origins and relying-party constraints are respected, credentials are bound to the correct account context, and abuse protection measures are considered for sensitive endpoints.​

The following security properties are central to the rationale for the implementation:

Logging should support troubleshooting and security analysis without collecting unnecessary or privacy-invasive data. In particular, enough visibility to detect failed enrolments, failed authentications, and unusual behaviour patterns while respecting the fact that authentication data is especially sensitive should be provided.​

Abuse protection such as rate limiting should also be considered as part of the implementation.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.