Login page shows irrelevant auth options & generic errors

[andypols]

Problem

The configuration only allows one authentication mechanism.

The login page is hard-coded to support all options and the user is expected to know which one to use.

We are using Okta-based SSO, which makes the login form unnecessary. Users can sign in without entering any credentials, but the presence of the form gives the impression that a username and password are required. When they attempt to log in this way, they see a generic error message: "You do not have the correct access permission."

In reality, the server is returning a more accurate message: "Username and password–based login is not enabled at this time.", but that is being ignored.

Expected behaviour

Make the login page config-aware:

• Only display Username & Passwords when needed to authenticate (local or active directory)
• Automatically login when OICD based SSO (remove the button)

Always render the errors returned, avoid acronyms (such as OICD)

[kriswest]

+1 from me on this. We're working with LDAP rather than OIDC and would like to hide that button when OIDC is not enabled.

[jescalada]

I'll pick this one up since I was the one who baked the OIDC button into the login originally... I can make it so that only the currently enabled auth methods are added as buttons on the login page.

@andypols What do you think the UI should look like for your Okta SSO use case? Am I correct to assume that your config has a custom auth option for that in the authentication array? In that case we might want to add an extra config option like hideLoginForm so that the form is hidden and only the relevant button (Okta SSO Login) is visible. This also means that all the other login options should be set to enabled: false.

[andypols]

@jescalada I don't think you need any UI for SSO authentication. The current code simply redirects when the user clicks the OIDC button:

  function handleOIDCLogin(): void {
    window.location.href = `${API_BASE}/api/auth/oidc`;
  }

Instead of a dedicated button, the client could load an api/auth/config (or similar) endpoint that indicates:

• username/password → show the login form
• sso → redirect to the auth provider ( ${API_BASE}/api/auth/oidc)
• otherwise → show an error (though I’m not sure if that case is actually possible)

We are using a custom auth (Passport OIDC, not GitProxy’s version since it doesn’t work with our setup), but it’s still just standard OIDC and works fine with the existing redirect flow.