Redmine OIDC Plugin — OpenID Connect SSO

If you searched for a Redmine OIDC plugin, you want standards-based OpenID Connect login on self-hosted Redmine — not a hosted SaaS portal. RedmineShop SSO & Access Suite Community is that plugin: OIDC/OAuth 2.0 for one identity provider, free forever, installed on your server.

What OpenID Connect solves on Redmine

OIDC lets Redmine trust your identity provider for authentication. Users click “Sign in with SSO”, authenticate at Keycloak, Okta, Azure Entra ID, or Google Workspace, and land in Redmine as a provisioned user. Your IdP remains the source of truth for MFA, password rules, and account disablement.

Compared with custom LDAP-only setups, OIDC gives you modern browser flows, short-lived tokens, and a clear redirect-based login path that security teams already understand.

Capabilities in Community (free forever)

• Authorization code flow with PKCE (S256)
• Automatic issuer discovery via the OIDC well-known endpoint
• JIT provisioning with configurable claim mapping (email, preferred_username, display name)
• Server-side enforce-SSO for non-admins plus admin break-glass password login
• Validated admin settings UI for issuer, client credentials, scopes, and redirect verification
• One active IdP configuration — enough for most single-directory organizations

These Community features are not time-bombed. See Community vs Pro for what stays free and what Pro is planned to add (SAML, multi-IdP, group sync).

Step-by-step: typical OIDC setup

1. Create an OIDC client in your IdP — confidential web client, authorization code + PKCE, redirect URI pointing at your Redmine callback path.
2. Install the Community package on Redmine 5.1+ or 6.x following the SSO install guide.
3. Enter issuer URL, client ID, and client secret in plugin settings. Confirm discovery returns authorization and token endpoints.
4. Map claims so Redmine login and email match your directory (prefer a stable unique claim).
5. Test JIT login with a non-admin account. Confirm a new Redmine user is created or an existing user is matched correctly.
6. Optionally enforce SSO for non-admins after you verify admin break-glass still works on a separate session.

Keycloak

Keycloak is the most common self-hosted IdP for Redmine labs and internal platforms. Create a realm client, set Valid Redirect URIs to your Redmine OIDC callback, and copy the issuer URL from the realm OpenID Endpoint Configuration. Full walkthrough: Keycloak OIDC setup for Redmine.

Azure Entra ID (Azure AD)

Register a web application in Entra ID, add the Redmine redirect URI, create a client secret, and use the tenant issuer URL (https://login.microsoftonline.com/{tenant}/v2.0). Map email or preferred_username so Redmine accounts stay stable across re-logins. No Redmine core patches are required.

Okta and Google Workspace

Both work as standards-compliant OIDC providers. Create an OIDC web app, whitelist the Redmine redirect URI, and paste issuer / client credentials into the plugin settings. Prefer PKCE-enabled code flow; avoid implicit flow.

Security practices that matter

• Keep the client secret only in Redmine settings (or your secret manager) — never in public git.
• Rotate IdP client secrets on a schedule and after staff changes.
• Do not enable enforce-SSO until at least two admins have confirmed break-glass.
• Use HTTPS end-to-end for Redmine and the IdP; mixed content breaks redirects.
• Verify the SHA256 checksum of the downloaded package before extract.

Troubleshooting quick checks

• redirect_uri_mismatch — IdP client redirect must match Redmine’s callback exactly (scheme, host, path, trailing slash).
• invalid_client — wrong client ID/secret or confidential vs public client mismatch.
• User created without email — adjust claim mapping; ensure the IdP returns the email scope/claim.
• Admins locked out — use break-glass password login; disable enforce-SSO until mapping is fixed.

For deeper install help, optional SSO Install Assist ($349 one-time) covers one IdP end-to-end. Download Community from the SSO product page and confirm versions on the compatibility matrix.

OIDC vs SAML on Redmine

Community focuses on OIDC because it is the modern default for browser login and works cleanly with Keycloak, Entra, and Okta app models. SAML 2.0 remains important for some enterprise IdP mandates — that is a Pro roadmap item, not a Community limitation disguised as a trial. If your RFP requires SAML today, review the Pro plan timeline before you commit architecture.

Claim mapping that stays maintainable

Most OIDC failures in production are claim mismatches, not broken redirects. Prefer a stable unique identifier from the IdP (subject or a directory UPN) and map email separately for Redmine notifications. Avoid using display names as login keys — people change names; subjects rarely do.

Document which claim becomes the Redmine login, which becomes the email, and what happens when a claim is missing. Test with a brand-new user and with an existing local Redmine account that should merge cleanly. If merge rules are wrong, you will create duplicates and confuse permission audits.

Staging checklist before enforce-SSO

1. Two admin accounts can still use password break-glass.
2. JIT creates the expected first/last name fields.
3. Revoking the user in the IdP blocks the next login attempt.
4. Redirect URI is identical across staging and production except for host.
5. Client secret rotation procedure is written down.

Only after that checklist should you enforce SSO for non-admins. Rolling it out mid-incident is how teams lock themselves out.

When to choose Install Assist

Choose optional SSO Install Assist if you have a hard cutover date, a single IdP, and limited Redmine plugin experience. Skip it if your team already runs OIDC for other apps and just needs the Community package plus docs. The service does not replace reading the install guide — it accelerates a correct first production config.