Redmine

API authentication currently relies on a static API key assigned to each user account, with no expiration date and no second factor requirement.

In my organization, with the recent enforcement of mandatory 2FA for administrator accounts (#35439), there is now a significant security gap between web access and API access: a user's web session is protected by 2FA, but the very same user's API key provides full, unrestricted access without any second factor.

This proposal complements the OAuth2 provider shipped in 6.1 (#24808), which addresses third-party application authentication.

Main identified issues¶

• 2FA bypass — Since #35001, basic authentication with username/password is blocked when 2FA is active. However, API keys still provide full access without any second factor, effectively bypassing the 2FA protection that administrators have required.

• Static keys with no expiration — API keys never expire. Once generated, they remain valid indefinitely until manually reset. A leaked key provides permanent access.

• Excessive privileges — Each API key inherits all permissions of the associated user account, with no ability to restrict access to read-only operations, specific projects, or specific API endpoints.

• No request rate limiting — There is no built-in protection against brute-force attacks on API keys or bulk data extraction.

• Insufficient traceability — API calls are not logged in a structured way (beyond standard application logs).

Proposed improvements to Redmine Core¶

I would like to work on this topic, but these changes should be discussed with Redmine maintainers and integrated into upcoming official releases.

1. Personal Access Tokens with a hybrid management model¶

I propose to replace the current single static API key with Personal Access Tokens, following the hybrid self-service + admin governance model used by GitHub, GitLab, and other major platforms.

Core features of Personal Access Tokens¶

• Multiple named tokens per user
• Mandatory expiration date
• Hashed storage — Token values are stored as SHA256 hashes, consistent with the approach used by Doorkeeper for OAuth2 tokens in #24808. The plaintext is shown only once at creation.
• Last-used tracking
• Management UI — Users manage their tokens in "My account". Administrators have a dedicated panel in Administration to view and manage all tokens across users.
• Backward compatibility — The existing single API key mechanism continues to work during the transition period.

2. Scoped permissions per token¶

• Each token can be restricted to specific permissions (read-only, specific trackers, time logging only, etc.)
• Reuse the scope mechanism already implemented for OAuth2 via Doorkeeper (#24808)
• Optionally restrict a token to specific projects only
• Administrators define which scopes are available globally

3. Rate limiting¶

• Limit the number of API requests per token (and maybe per IP address and/or per endpoint)
• Return standard HTTP 429 (Too Many Requests) responses when limits are exceeded

4. Structured API audit logging¶

• Log all API calls in a dedicated, queryable format (not just standard application logs): token used, endpoint, HTTP method, source IP, timestamp, response status
• Provide an admin UI or API to query and export audit logs
• Enable notifications for anomalous activity: excessive request volume, requests from unknown IPs, repeated authentication failures

5. Granular API endpoint control¶

• Currently, the REST API can only be enabled or disabled globally — it is all or nothing
• Add the ability to disable specific API endpoints or groups of endpoints (e.g. allow issue read but disable user management API)
• This allows administrators to expose only the API surface area that is actually needed

6. CORS configuration?¶

• Allow administrators to define which domains are authorized to access the API from a browser context
• Currently there is no CORS configuration, which means either all origins are allowed or administrators must handle this at the reverse proxy level

How to start?¶

Given the scope of these changes, I propose to start small with a step-by-step approach.

We could start by adding Personal Access Tokens with

• self-service creation,
• expiration,
• multiple tokens per user,
• hashed storage,
• admin max-lifetime policy,
• admin token overview panel,
  and keep backward compatibility with legacy keys

Other features could be added later.
I am willing to provide patches for these first steps.

I would welcome feedback from the core team on the overall direction before starting implementation, in particular:

• Whether the hybrid self-service + admin governance model seems appropriate
• Whether legacy API key deprecation is desirable, and what transition period would be reasonable