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