Current situation
Authentication against the Admin API is limited to POST /login with username and password, which returns a short-lived JWT (grommunioAuthJwt) used as a cookie, along with a CSRF token for mutating requests.
Problem
For machine-to-machine integrations, this flow has several drawbacks:
- The integrating system must store the full admin password and replay the interactive login flow, including cookie and CSRF handling designed for browsers.
- A leaked credential grants full admin access; there is no way to restrict what an integration may do. Our own integration only needs read access for most operations — today we can only enforce that client-side; the API cannot.
- Credentials cannot be revoked per integration; the only option is changing the password, which affects every consumer.
Proposed feature
Long-lived, revocable API tokens:
- created via the admin UI, the
grommunio-admin CLI, or the API itself,
- sent as
Authorization: Bearer <token> (no cookie/CSRF requirement),
- carrying scoped permissions, reusing the existing role/permission model (
/system/roles/permissions) — e.g. read-only, restricted to an organization or domain,
- with optional expiry, plus endpoints to list and revoke tokens.
Context / offer to contribute
We (Open Circle AG, a Swiss managed services provider) are integrating grommunio into our service platform via the Admin API. We would be willing to contribute to the implementation — happy to align on design (token storage, scope model) beforehand.
Related: dedicated service accounts (see separate feature request) would be the natural owner of such tokens.
Current situation
Authentication against the Admin API is limited to
POST /loginwith username and password, which returns a short-lived JWT (grommunioAuthJwt) used as a cookie, along with a CSRF token for mutating requests.Problem
For machine-to-machine integrations, this flow has several drawbacks:
Proposed feature
Long-lived, revocable API tokens:
grommunio-adminCLI, or the API itself,Authorization: Bearer <token>(no cookie/CSRF requirement),/system/roles/permissions) — e.g. read-only, restricted to an organization or domain,Context / offer to contribute
We (Open Circle AG, a Swiss managed services provider) are integrating grommunio into our service platform via the Admin API. We would be willing to contribute to the implementation — happy to align on design (token storage, scope model) beforehand.
Related: dedicated service accounts (see separate feature request) would be the natural owner of such tokens.