Redmine

I've added this to 7.0.0 for now to discuss it, but I strongly believe we should implement this in some way.

https://github.com/jcatrysse/bless-this-redmine-sso/tree/feature_version_2.0.0

This is what I have been using (I added a version 2.0.0 feature branch).

Yes please. The lack of support for modern auth / Single Sign On (SSO) is really a problem for Redmine to move forward.

The OAuth side of the force is a bit disorderly, with several plugins more or less trying to do the same thing, most of the time confusing OAuth and its subset OpenID Connect. Kontron/redmine_oauth is the only one I was able to use properly.

The SAML side of the force was, until recently, somewhat clearer : a bunch of abandoned plugins, and the last one standing being the one from AlphaNodes : https://github.com/AlphaNodes/redmine_saml. But this last one went in public archive mode on Github this fall, so I think this is not an option anymore.

Jan, will your plugin support OIDC access for the Rest API?
That is, will it allow to use the access token via bearer authorization?

See https://github.com/kontron/redmine_oauth/issues/34 for the discussion!

Short answer: not in the current patch — but there's a well-scoped way to get there, and I'd like feedback on it.

The current implementation is intentionally scoped to browser-based login only (OAuth2 Authorization Code + PKCE, the interactive flow). The access token Redmine obtains from the IdP during that flow is never accepted back as a credential against Redmine's own REST API — it's used only for session revalidation and revocation at the provider, never presented to a resource server. That's a deliberate scope boundary, not an oversight; it's recorded as such in this branch's own audit notes.

So: no, you can't currently take the access token issued during a user's interactive login and use it as Authorization: Bearer <token> against /issues.json etc. REST API auth stays exactly as it is today (API key, or Redmine's own Doorkeeper OAuth2 provider if enabled) — this patch doesn't touch that path at all.

That said, I don't think "Bearer auth for the REST API" and "OIDC login" should be the same mechanism anyway, and I think that's part of why this keeps coming up unresolved elsewhere too — see kontron/redmine_oauth#34, which is the same request against a different plugin and has sat open for over a year without an implementation.

What I think would actually fit well — as a separate, follow-up feature, not part of this patch — is the OAuth2 Client Credentials grant for machine-to-machine access:

- An admin registers a confidential client in the IdP (e.g. Keycloak) with service-account/client_credentials enabled, and hands that client_id/secret to the external service — no user, no browser, no redirect involved at any point.
- The external service calls the IdP's own token endpoint directly to get a short-lived access token, and sends it to Redmine as a Bearer token.
- Redmine validates the token's signature against the same JWKS already fetched for the provider, checks iss/aud/exp, and maps the client identity to a Redmine service-account user via a small new mapping (client_id → user), conceptually similar to an API key but centrally revocable from the IdP.

This reuses most of the existing JWKS/discovery machinery, keeps the interactive login flow untouched, and — unlike a static API key — lets an admin kill access centrally by disabling the client at the IdP. I think it's worth proposing as its own issue once this patch has landed, rather than bundling two different grant types into one review.

Happy to write that up properly if there's interest.

Jan thank you for your feedback.

Why confine it to a client credentials grant? It wouldn't matter anyway - as long as one can provide an
access token with a valid issuer and the redmine client mentioned as aud it should not be relevant which way the
token was created. (well you could dive deeper and confine it with checking the azp but i don't really
see this happening on most projects).

Why do you see a separate service-account user? We e.g. don't use it that way. If have standard users, that
currently have to use the redmine api key, which are using a keycloak idp for everything else. That is
we have a small app, that communicates with Redmine directly using the REST API, but it needs to be done
with the identity of the user.

• There exists a user on a separate IdP
• Redmine should accept this user's bearer token either by verifying the JWT against the IdP issuer (or calling the introspection endpoint, and optionally verifying the aud claim
• The preferred_username should map to a possibly existing user (if not - leave option to create or no create)
• The roles or groups should map to groups membership on redmine with the IdP being the authoritative roles

If one would you could add a special role that maps to admin rights?!

Thanks for pushing back on this, it's a fair point and I think it actually resolves cleanly.

You're right that, mechanically, it doesn't matter which grant produced the token — Redmine would only need to check iss/aud against a configured provider and resolve identity from claims, same as the interactive login path already does. And there's a detail that makes your proposal and mine converge more than I first thought: when a Keycloak client has "Service Accounts Enabled", the client_credentials token it issues still carries a resolvable identity (sub, preferred_username: service-account-<client-id>), assignable to groups/roles like any other user. So the mechanism — accept a valid bearer token, resolve it via the existing claim-mapping logic (uid_claim → user, groups/roles → Redmine groups/roles, IdP authoritative) — can cover both "delegated on behalf of a logged-in human" and "pure machine access" without the Redmine-side code needing to distinguish how the token was minted.

Where I think your example specifically assumes something that won't generally hold: it requires Redmine and the calling application to already sit behind the same IdP, so that extending an existing client with an audience mapper is enough. In practice that's the exception, not the rule — most integrations are either on a different IdP entirely, have their own auth mechanism with no OIDC relationship at all, or are backed by something like LDAP. For those, there's no existing client to extend; you'd have to provision one specifically for the Redmine integration regardless, which is exactly the client-credentials/service-account pattern.

So I'd frame it this way: a general solution has to support provisioning a dedicated client purely for the integration, independent of however the calling application authenticates its own end users (or whether it does that via OIDC at all). "Accept any valid bearer token from the same IdP Redmine already uses for login" is then a narrower convenience for the specific case where an organization happens to be IdP-aligned already — worth allowing, since it's nearly free once the claim-resolution path exists, but not sufficient as the answer on its own.

Concretely, I'd design it as: Redmine validates a Bearer token's signature against the JWKS of whichever configured provider's iss it matches, requires aud to name this Redmine instance, and resolves the resulting claims through the exact same uid_claim/role-mapping machinery the login flow already uses — regardless of whether the token came from an authorization_code flow (your delegated case), or client_credentials against a dedicated service-account client (the general case, and the one I'd treat as primary since it doesn't assume any pre-existing identity relationship between the calling app and Redmine's IdP).

Happy to write this up properly as a follow-up proposal once the current patch lands.

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.

Supporting OAuth2 providers should be a pretty important feature. Even with redmine.org, its be great being able to login via Google OAuth instead of via password.

Thanks for the input. I'd like to push back gently on "OAuth2 providers" as the framing here, because Google specifically is actually already covered by the OIDC-only scope we're proposing — it's not a reason to widen it.

Google's OAuth2 implementation is fully OIDC-compliant: it has a discovery document (accounts.google.com/.well-known/openid-configuration), issues signed ID tokens, and publishes a JWKS. Our OidcProvider config is fully generic (issuer URL, client_id/secret, scopes, claim mappings — nothing Keycloak-specific), and "Google" is already a built-in preset in this patch, tested against the real Google endpoints and covered in the test fixtures. So logging into redmine.org via Google is something this MVP already supports, purely through configuration — no code changes needed, and no scope widening required.

The actual scope question is narrower than "Google vs. no Google": it's whether to also support IdPs that only do plain OAuth2 with no ID token and no JWKS — GitHub's OAuth being the clearest example (GitLab and Google both do publish OIDC metadata, so they're not actually in this bucket). For those, there's no signed identity assertion to validate at all; you'd have to call a provider-specific profile endpoint (e.g. GitHub's /user REST API) and trust its response over plain TLS instead of a cryptographically signed token. That's a materially different trust model, not just "fewer fields to fill in" — it needs its own validation path per provider rather than one standards-based OIDC client, and it removes the signature-verification guarantee the rest of this design relies on.

So I'd still keep this MVP OIDC-only, since the concrete examples raised (redmine.org wanting Google login) are already satisfied — and treat broader plain-OAuth2 support (GitHub-style) as a separate follow-up issue, scoped and reviewed on its own, rather than folding a weaker trust model into this patch.

I have implemented a solution, that uses an intermediate nginx server, using nginx-auth-jwt by adding a location like this

location = /jwks_uri {
    internal;
    proxy_cache default_cache;
    proxy_cache_valid 200 60m;
    proxy_read_timeout 5s;
    proxy_pass_request_body off;
    # Using the SSL a resolution problem was faced, where the DNS is resolved to IP
    # when there is a body, which fails, so we contact keycloak via the internal net
    proxy_pass http://keycloak:8080/realms/my-realm/protocol/openid-connect/certs;
}

# Allow to use an access token to connect to the redmine api
location /redmine/ {
    auth_jwt "closed site";
    auth_jwt_key_request /jwks_uri;
    auth_jwt_require_claim resource_access.redmine.roles intersect json=["user"];

    satisfy all;
    include /etc/access/admin_key.conf;
    proxy_pass http://redmine:3000/; # the real redmine service
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Redmine-API-Key $admin_api_key;
    proxy_set_header X-Redmine-Switch-User $jwt_claim_preferred_username;
}

Now using an access_token against this endpoint and some redmine rest api url will lead to an admin api key call,
switched to the resp. user of the access token.

What I will do now, is adding a cron script that regularily refreshes the apikey of the admin user used for this
process, updates admin_key.conf and then restarts nginx. This should be a solid security solution.

Any thoughts?