Should OIDC become WebAPI's primary authentication mechanism?

[chrisknoll]

As part of the WebAPI 3.0 modernization effort, we've been revisiting the authentication architecture. Moving from Shiro to Spring Security has given us an opportunity to simplify the authentication layer and better align with modern identity management practices.

Historically, WebAPI has supported multiple authentication mechanisms directly, including:

• Database authentication
• LDAP authentication
• Windows / Active Directory authentication (SPNEGO/Kerberos)

Each of these providers requires WebAPI to understand how to authenticate against a particular identity source. While this provides flexibility, it also means we own and maintain multiple authentication implementations, configuration models, and security considerations.

Over the past decade, however, the identity landscape has evolved considerably. Many organizations no longer expect applications to authenticate directly against LDAP or Active Directory. Instead, they deploy an Identity Provider (IdP) such as Microsoft Entra ID, Keycloak, Okta, Ping Identity, or similar products. These systems continue to authenticate users against LDAP, Active Directory, Kerberos, MFA, smart cards, passkeys, etc., but expose a standard OpenID Connect (OIDC) interface for applications.

From WebAPI's perspective, the authentication flow becomes much simpler:

Browser
    |
    v
Identity Provider (OIDC)
    |
    +-- LDAP
    +-- Active Directory
    +-- Kerberos
    +-- MFA
    +-- Other enterprise authentication
          |
          v
       WebAPI

In this model, WebAPI no longer needs to know how the user authenticated. It only needs to trust the OIDC provider, validate the identity, and map the authenticated user to WebAPI permissions before issuing its own application JWT.

One benefit of this approach is that many of the authentication mechanisms we currently support become implementation details of the Identity Provider rather than WebAPI itself. Organizations can continue using LDAP or Active Directory exactly as they do today, but those integrations are managed by infrastructure that is specifically designed for identity management.

The one notable exception may be database authentication. A built-in JDBC provider remains useful for development, testing, and smaller installations where deploying a dedicated Identity Provider may not be desirable.

This raises an architectural question for the project:

Should OIDC become the primary (or recommended) authentication mechanism for WebAPI, with direct LDAP and Windows authentication considered legacy or compatibility options?

Potential benefits include:

• A simpler authentication architecture within WebAPI
• Reduced maintenance of multiple authentication providers
• Better alignment with modern enterprise identity management
• Automatic support for capabilities provided by the IdP (MFA, passkeys, conditional access, SSO, etc.)
• Easier integration with a wider variety of enterprise identity solutions

I'm interested in hearing from the community:

• Are there deployments that still depend on direct LDAP or Windows authentication?
• Would introducing an external OIDC provider be a significant barrier to deployment?
• Should WebAPI continue to maintain multiple authentication implementations, or should we encourage deployments to standardize on OIDC while retaining database authentication for development and lightweight installations?

I don't view this as a change that necessarily needs to happen immediately, but it seems like a worthwhile discussion as we continue modernizing WebAPI's security architecture.