feat: add OIDC claim overrides and group filtering

[GyroGearl00se]

Summary

This PR enhances the OIDC/OAuth authentication provider by introducing three new advanced configuration properties:

1. Username Claim: Allows admins to override the default username extraction claim.
2. Groups Claim: Allows admins to override the default groups extraction claim (supporting both string and array formats).
3. Allowed Groups: Introduces a comma-separated list of groups to strictly restrict login access.

Why

Some Identity Providers do not adhere to standard OIDC claim names. Giving administrators the flexibility to map these claims as needed.

Furthermore, without group-based filtering (Allowed Groups), any authenticated user from the configured IDP can successfully log in. By enforcing an allowed groups intersection during the [GetUserInfo] phase, we can proactively deny access to users before they even reach the dashboard, improving security posture.

Related issue

Closes #

Validation

• Tested the new OIDC configurations directly in the UI & confirmed save/edit in database (sqlite - dev.db)
• Used a locally running Authentik instance as the IDP to test different scenarios (custom scopes, group assignments, successful logins, and group-based rejections).
• Ran automated backend unit tests for OIDC claim extraction and group validation cases.

Checklist

• I reviewed this PR myself before requesting review.
• I understand the changes, including AI-generated parts (if any).
• For new features, a feature request issue is linked.
• I cleaned up AI noise (unnecessary comments, dead code, and unrelated changes).
• This PR is reasonably scoped (or split into smaller PRs).

[zxh326]

Two issues block this as a safe fix.

1. In pkg/auth/oauth_provider.go, UsernameClaim and GroupsClaim are implemented as hard replacements rather than preferred claims. If the configured claim is missing or mistyped, Kite stops checking the standard claim chain entirely. That can leave user.Username empty even when standard fields are present, and FindWithSubOrUpsertUser only validates Sub, so the first bad login can create a user with an empty username. After that, later logins can start failing on the unique index. The same problem also turns AllowedGroups into a blanket deny if the configured groups claim is wrong. This should either fall back to the existing default extraction logic or fail explicitly before user upsert.

2. In pkg/auth/login_handler.go, the new redirect branch checks err.Error() == "user is not in any of the allowed groups". That makes the behavior depend on exact error text and will silently regress to generic user_info_failed if the error is wrapped or reworded. Please use a sentinel or typed error instead.

The overall direction makes sense, but I don't think this is the best fix in its current form.

[zxh326]

Thanks @GyroGearl00se

I’ve added some end-to-end tests to ensure that everything works as expected.