Redmine

Hello Marius Ionescu BĂLTEANU and team,

I'd like to propose a design for native OpenID Connect support and seek your direction before opening any patches. I've spent time analysing the four community OIDC plugins (`enricohuang/redmine_oidc`, `devopskube/redmine_openid_connect`, `nanego/redmine_omniauth_oidc`, `kontron/redmine_oauth`), read this issue and #37363 in detail, and produced a full design document covering data model, authentication flow, session lifecycle, logout (RP-initiated + Back-Channel), claim mapping, admin UI, security checklist, and testing strategy.

Full proposal: in attachement

The proposed shape is a native OIDC 1.0 implementation in Redmine core (no plugin layer), targeting 7.0.0. Architecture highlights:

Dedicated `OidcProvider` ActiveRecord model (not `AuthSource` STI) supporting multiple active providers simultaneously, with presets for Keycloak, Microsoft Entra ID, Okta, Auth0, Google Cloud Identity / Workspace, and a fully-configurable Custom (generic OIDC) profile.
Stable user identity via an `oidc_user_links(issuer, sub)` join table; first-time email matching gated by `email_verified=true`.
Mandatory PKCE S256 and JWKS-based ID token signature verification — the critical security gap in three of the four existing community plugins.
Three universal claim-mapping strategies (`group` / `project_role` / `none`) driven by a configurable dot-notation claim path that works across all major IdPs without special-casing. Admin flag is sync-controlled only when the admin explicitly opts in via an `admin_role_values` whitelist. Manually-assigned groups and memberships are never overwritten.
Full SSO logout propagation: RP-initiated logout via `end_session_endpoint`, Back-Channel Logout endpoint, opt-in periodic introspection for sub-token-TTL revocation latency.
Reactive token lifecycle: lazy refresh-on-expiry with a configurable buffer (default 300s), serialised under a pessimistic row lock to handle refresh-token rotation safely. No background scheduler in MVP.
2FA delegated to the IdP when the `amr` or `acr` claim signals MFA; auto-provisioned users without TOTP are routed through Redmine's existing setup wizard when global policy requires 2FA but the IdP did not assert MFA.
One new gem dependency: `jwt` (~> 2.x) for signature verification. Alternatives are either heavier (`omniauth_openid_connect` pulls OmniAuth middleware) or unsafe (manual base64 decoding, which is what three of the four existing plugins currently do).
EN + CS locales in MVP; comprehensive test pyramid (unit / functional / integration with WebMock-stubbed IdP); security checklist as a patch-submission gate.

Before I commit time to implementation, I'd appreciate your direction on the following:

1. Scope: OIDC-only vs OIDC + plain OAuth2 in MVP? The title of this issue says "OAuth Authentication", and Felix Singer's comment in #37363 (note 2) asks for plain OAuth2 providers (GitHub, GitLab, Google OAuth). I propose OIDC-only for MVP because plain OAuth2 lacks a signed identity assertion (no ID token, no JWKS), but this is genuinely your call — extending to plain OAuth2 doubles the surface area and we akens the security baseline.
2. AuthSource vs. dedicated model? OIDC's browser-redirect flow doesn't fit the `AuthSource#authenticate(login, password)` contract, and multi-provider with per-provider quirks complicates STI. I propose a dedicated `OidcProvider` model. Confirm or redirect.
3. Patch series shape? Acceptable as one large patch, or do you want it split into a series (schema + models → discovery/JWKS primitives → login flow → role mapping → admin UI → BCL → tests)?
4. Gem dependency: is `jwt` (~> 2.x) acceptable? It's the minimum to do JWKS signature verification properly.
5. Server-side session store as a BCL prerequisite? Redmine defaults to cookie-only sessions; Back-Channel Logout needs server-side sessions to be able to destroy sessions on demand. Document this as a prerequisite admins must enable for BCL to be effective, or different approach?
6. Prior art — note 5 above (Jan Catrysse) links to a v2.0.0 feature branch of an alternative SSO implementation. I didn't have the URL when drafting the proposal — could you point me at it if it should inform the design?

The full proposal documents 21 design decisions with their rationale, and lists exactly what's deliberately out of scope for MVP (background refresh, plugin migration importers, SAML, plain OAuth2, SCIM, Front-Channel Logout, real-IdP integration tests in CI, step-up auth, mobile/native client support). Happy to break any section into a separate discussion if useful, and to iterate the design before any code lands.

Thanks for your time.

Jan Opravil

Native OIDC implementation — patch attached

Following up on my design proposal above (comment #7): the implementation is complete and attached as redmine-oidc-native-support.patch (single consolidated diff, applies cleanly with patch -p1 or git apply against current trunk, r25125).

Scope (120 files, ~22.9k lines added):

- OidcProvider — dedicated model (not AuthSource STI), multiple providers can be enabled simultaneously. Built-in presets for Keycloak, Microsoft Entra ID, Okta, Auth0 and Google Cloud Identity/Workspace, plus a generic "custom" option for any spec-compliant IdP.
- OidcSession / OidcUserLink — per-device session tracking (refresh/access/ID tokens encrypted at rest via the existing Redmine::Ciphering), separate from the identity link so one identity can hold several concurrent device sessions.
- Auth code flow with mandatory PKCE (S256) and JWKS-based ID token signature verification (lib/redmine/oidc/id_token_validator.rb, jwks.rb, discovery.rb) — no fallback to unsigned or alg=none tokens.
- Login-CSRF defence via a signed, user-agent-bound handshake cookie (handshake_binding.rb) plus server-side handshake store, per RFC 9700 §4.7.
- RFC 9207 mix-up mitigation, iss checking, nonce, and standard claim validation (issuer/audience/exp/iat).
- Back-Channel and Front-Channel Logout support (RFC/OIDC spec), both revoking the stored refresh token at the provider, not just dropping the local session.
- Session lifecycle: periodic revalidation (prompt=none), optional token introspection (RFC 7662), token revocation (RFC 7009) on logout/unlink/deactivation/account deletion.
- Three role-mapping strategies: none, group (claim → Redmine group) and project_role (claim → project membership + role), plus a separate admin_role_values mapping — all reconciled against actual current access on every login, not just an internal bookkeeping table, and fully reversible when a provider or link is removed.
- Delegated 2FA: optional "trust the IdP's MFA claim (amr/acr) within a configurable max_age" policy, falling back to Redmine's own 2FA.
- CLI tooling: rake redmine:oidc:{providers,create,delete,revoke_grants,prune_sessions,refresh_metadata}, plus one-shot importers from two existing community plugins' data shapes (enricohuang/redmine_oidc, jcatrysse/bless-this-redmine-sso).
- Admin UI (OidcProvidersController + views) and end-user UI (login buttons, linked-accounts panel, unlink flow).
- Full English + Czech i18n.

Dependency: one new gem, jwt (~> 3.2), for signature verification.

Tests: 989 test runs (functional/unit/integration), all green, covering the full auth/logout/refresh/revocation lifecycle, role-mapping reconciliation, concurrency (row-locking against races between refresh and logout/BCL), and a dedicated security-regression suite (audit_r17_findings_test.rb) pinning specific findings from an independent security review of the branch (claim-extraction privilege escalation, weak-key JWKS acceptance, session-fixation-adjacent issues, etc.).

Patch attached below.