OpenProject's API supports session authentication, personal API tokens, OAuth 2.0, and external OIDC tokens that follow its access-token validation requirements. A token can authenticate a caller, but project membership and role permissions decide what the caller can see or change. An inventory that stores only token IDs will miss the projects and work packages that make the credential consequential.
The API documentation says all responses use HAL+JSON and that links can differ based on the authenticated user's permission. A work package includes an update link only when the user can update it. That behavior is useful for clients, but it is not a substitute for server-side authorization tests. A client should not infer permission from a cached link after membership changes.
Map user, token and project
Record the token owner, purpose, creation date, storage location, and project memberships. Create dedicated automation accounts where the product permits it. Keep administrator tokens out of routine integrations. If the instance supports OAuth client credentials, bind the application to a least-privileged user and document the authorization flow.
OpenProject memberships connect a user, a project, and a role. The same user may be an administrator in one project and have no access in another. Review the project role and the operation-level permission together. A role that can edit work packages should not automatically require project administration.
Check anonymous and OAuth paths
The API documentation notes that unauthenticated clients receive the permissions of the anonymous user unless the instance requires authentication for all requests. Review this setting explicitly. A public project may be intended, but public access to work packages, attachments, or user lists may not be.
For OAuth, validate the registered client, redirect URI, requested scope, token audience, and token expiry. Test the external OIDC path if it is configured. A valid bearer token still needs a linked user and the expected scope. Never accept a token merely because its signature validates.
What the ZoomEye observation shows
The count-only search used sub_type=all, page 1, and page size 1. app="OpenProject" returned 11,685, title="OpenProject" returned 12,441, and http.body="OpenProject" returned 45,320. The app and title counts are close, which is more consistent than a large body-only match, but neither proves the instance's authentication model or project visibility.
Use the observation to find forgotten public instances, then correlate with the organization's DNS and cloud inventory. Do not enumerate projects or work packages on a deployment you do not own.
Validate the authorization boundary
Test a token as an ordinary project member, as a user with no project membership, and as an administrator. Check project listing, work-package read, update, delete, membership, attachment, and webhook actions. Revoke the token from the account page and confirm that the next API call fails immediately.
Review onboarding and offboarding. A removed employee should lose project membership even if their personal token still exists. A token without membership context is an empty key; a token with excessive membership is a broad API credential.