OpenProject API Tokens Need Project Membership Context

OpenProject's API authentication methods include session authentication, personal API tokens, OAuth 2.0, and external OIDC tokens. While tokens can authenticate a user, project membership and role permissions determine what actions the user can perform. An inventory limited to token IDs fails to reflect the significance of the projects and work packages associated with those credentials.

The API documentation specifies that responses utilize HAL+JSON, with links potentially varying based on the authenticated user's permissions. A work package's update link is only available to users who have permission to modify it. Although this behavior aids clients, it should not replace server-side authorization checks. Clients should not assume permission based on cached links following membership changes.

To better manage API tokens, record the token owner, purpose, creation date, storage location, and project memberships. For instances that allow it, establish dedicated automation accounts. Refrain from placing administrator tokens in routine integrations. If the platform supports OAuth client credentials, assign the application a least-privileged user and document the authorization flow.

Project roles and permission levels must be considered together. A role that enables editing work packages should not inherently grant project administration. When testing OAuth, validate the registered client, redirect URI, requested scope, token audience, and token expiry. If external OIDC is configured, thoroughly test its path. Remember, a valid bearer token must still be linked to a user with the correct scope.

Following ZoomEye's observations, run a count-only search using the parameters sub_type=all, page 1, and page size 1. The app=OpenProject, title=OpenProject, and http.body=OpenProject searches returned 11,685, 12,441, and 45,320 results respectively. While these counts are close, they do not confirm the authentication model or project visibility. Use these findings to identify instances with forgotten public access, then correlate the results with the organization's DNS and cloud inventory.

Avoid enumerating projects or work packages on a deployment you do not own. Validate the authorization boundary by testing a token as an ordinary project member, a user without project membership, and an administrator. Check actions such as project listing, work-package read, update, delete, membership, attachment, and webhook operations. Upon revoking a token from an account page, ensure the next API call fails immediately.

Onboarding and offboarding processes should ensure that a removed employee loses project membership, even if their personal token remains active. A token lacking membership context is ineffective, while a token with excessive membership provides broad access.