Hitobito OAuth tokens inherit the full role set of their user
Hitobito manages hierarchical groups, members, roles and events. Its access model is derived from the roles a person holds in different groups, which makes the API and OAuth token scope an extension of that model rather than a separate permission universe.
The project's JSON API documentation states that personal OAuth access tokens have the same permissions as the corresponding user. It also says the relevant people must have a role in the defined permission range. That is a useful property for integrations and a dangerous one for long-lived tokens created by administrators or power users.
Measurement evidence
On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned zero matches for app="Hitobito", 23 for title="Hitobito" and 115 for http.body="Hitobito". The small counts are discovery leads, not proof of deployment security. A title or body match can be a documentation page or a staging instance.
Trace tokens back to roles
Inventory every OAuth application and personal access token, the user who created it, the roles that user holds and the groups or layers those roles affect. Test a token against a group inside the permission range and a group outside it. Do not assume that an API endpoint is safe because the browser navigation hides it.
Review administrative roles, event management, member data and invoice functions separately. Hierarchical rights can grant visibility across lower layers. A person who is a member in one local group may also hold a regional role that changes what the API returns.
Make lifecycle explicit
Set token expiry, owner and purpose. Revoke tokens when a person changes roles or leaves the organization. Recheck the role set after a group move, because the token remains the same while the underlying abilities may change. Protect API secrets and avoid using a shared administrator account for integrations.
Monitor OAuth grants, token creation, role changes and API calls that cross group boundaries. After an exposure, revoke the token, inspect the user's role history and review API activity in the affected groups. Removing one token does not remove a role that another integration can use.
The effective access question is: which person, which roles, which group hierarchy and which token?
Top comments (0)