...
Backend services can invoke APIs such as system APIs, metadata APIs etc anytime within the system (say backend batch job)
The services will be either injected with a token that is commonly accepted by all services (and also passes the OPA and envoy checks) OR they will be routed via a separate service like private ingress where the ingress service will have a token as a config which will be attached which will attach a token to the request before forwardingand forward to the backend
This injected token will have no expiry and can be used only for invoking the system, meta APIs
Using this token, user context APIs cannot be invoked. User context APIs will always require a user token
Registered users can obtain a token
As a registered user on the system you can obtain access tokens to invoke APIs for use cases like development, bulk content creation etc
There are two ways you can invoke the APIs
First option is to login on the system using Portal and use the
connect.sidcookie for all your APIs via postman / curl. These APIs need to be routed via Portal endpoing and cannot use the/apiendpointSecond way is to obtain a token first from keycloak, then use the keycloak’s refresh token to obtain a new token from adminutils which will have your roles information. You can use the access token issued by adminutils to invoke APIs using the
/apiendpoints
In either approach, what APIs you can access is decided by what roles you have on the system
...
Note: Kong validating the refresh token is not yet tested. But since the refresh token from keycloak is of type HS256, and we know the secret to be used to verify the HS256 signature, so we should be able to validate the keycloak token in kong
Design discussion that is yet to be done
...