Hi Lukas,
Hi,
Thanks, that approach makes sense to me overall.
Adding the apiGroup into the token payload and checking it again during
token validation sounds like the right direction. That would make the API
boundary explicit instead of relying only on the URL structure.
One small concern: I think we should avoid defaulting to the default
apiGroup when an unknown apiGroup is provided in the path. For example, if
/rest/{apiGroup}/auth/token receives an unknown group, I think it should
return an error such as 400 or 404. Otherwise, a typo, misconfiguration, or
unexpected client request may silently receive a token for the default API
group.
The default apiGroup fallback should probably apply only when no apiGroup is
provided by the API definition, not when an invalid group is requested
explicitly.
So the flow could be:
- /rest/auth/token issues a token for the default API group, for
backward compatibility
- /rest/{apiGroup}/auth/token first validates that apiGroup is a known
group
- then it checks whether the authenticated user has permission for that
API group
- then it issues a token containing the apiGroup
- later requests must match the token apiGroup with the requested API
group
Also I am sure that we are on the same page: the API group permission check
should complement, not replace, the existing service-level permission
checks. The group-level check can decide whether the user may access that
API boundary, while the invoked service should still enforce its own
business/security permissions.
Regards
--
Divesh Dutta
www.hotwaxsystems.com
On Tue, Aug 25, 2026 at 1:04 PM Lukas Finster <[email protected]>
wrote:
> Hi Divesh,
>
> thanks for the input. Regarding your points:
>
> One implementation point I think is worth clarifying is how apiGroup will
> be represented internally. It may be useful to make it part of the REST API
> model itself, rather than treating it only as a URL prefix, so the same
> value can be used consistently by routing, OpenAPI generation, Swagger UI,
> and security checks.
>
> This was the idea, apollogies if i described it unclear.
>
> The authentication and authorization design may also need some detail. If
> tokens are API-group specific, the token should probably carry the
> apiGroup,
> and request validation should reject a token issued for one group when used
> against another group.
>
> What I am thinking is hosting the authentication endpoint thats currently
> at
>
> rest/auth/token
>
> with a path parameter at
>
> rest/{apiGroup}/auth/token
>
> Inside the Method we then validate apiGroup against all known apiGroups
> (if non match, log a warning and default to the default apiGroup) and
> validate the user has correct SecurityPermission for the given apiGroup.
>
> We create the token with the apiGroup as an additional key:value pair.
>
> When validating the token its then simply an additional check if this
> token was issued for this endpoint.
>
> Best regards,
>
> Lukas
>
>
