pfSense

```
h3. Problem

The webConfigurator can currently authenticate against the Local Database,
LDAP, or RADIUS. All three are synchronous username/password checks. There is
no way to authenticate the GUI against an OpenID Connect identity provider
(Google Workspace, Entra ID / Azure AD, Okta, Authentik, Keycloak), which is
how most organisations now centralise administrative access, MFA and
offboarding.

Two consequences:

• Administrators cannot apply their IdP's MFA and conditional-access policy to
  firewall GUI logins.
• Revoking a departing administrator requires a separate manual step on every
  firewall, because GUI credentials live outside the IdP.

Proposal¶

Add a third authentication server type, "oidc", alongside LDAP and RADIUS,
configured under System > User Manager > Authentication Servers with only an
issuer URL, client ID and client secret. Provider endpoints are obtained via
OIDC discovery, so no per-provider endpoint configuration is needed.

Because OIDC is a redirect flow rather than a synchronous credential check, it
cannot be implemented as another *_backed() function called from
authenticate_user(). It fits naturally in session_auth(), which already
handles the interactive login POST, via ?oauth=start and ?oauth=callback. This
avoids introducing a new pre-authentication endpoint into the GUI.

Authorisation reuses the existing remote-user model: no local user account is
required, and privileges come from mapping a configurable group claim onto
pfSense groups, exactly as LDAP and RADIUS group mapping work today.

Additionally: optionally disable password login¶

To make a firewall SSO-only, a "Disable password login" option is added to
System > User Manager > Settings. It is rejected unless the selected
authentication server is an OIDC server, and it affects only the interactive
login form. XML-RPC (HA sync) authenticates through a separate code path and is
deliberately unchanged. Recovery from a broken SSO configuration is via console
or SSH, consistent with existing lockout scenarios.

Security notes¶

• Authorization code flow with PKCE (S256); state and nonce on every request.
• The code is exchanged for tokens over a TLS-verified back channel, so the ID
  token is trusted without local JWKS signature verification. iss, aud, exp and
  nonce are all validated.
• Logins can be restricted to one or more hosted domains, matched against the
  hd claim or the email domain.

Status¶

An implementation is ready and has been tested against live Google Workspace:
discovery, the authorization redirect, token exchange, ID-token claim
validation and login all succeed end to end. A pull request will be linked to
this issue.
```