I’m trying to understand when in a typical auth scenario HTTP Requests are made to Keycloak. For example, consider a simple client / server where the server is a Keycloak resource server. The client makes an HTTP Request to the server without a Bearer token. In this case, the server would redirect to Keycloak so that the client can be authenticated. Once the client is authenticated, it can make future requests with its bearer token set in the HTTP headers.
Now let’s say the client is making another request to the same server with the bearer token set in the headers. How does the server know, typically by way of a Keycloak adapter, whether to authorize the request? I get that the bearer token contains an identity token for authentication and an access token for authorization. But my understanding is that there are 2 things that need to be evaluated: 1 is the policy decision whether or not the request is authorized. 2 is policy enforcement which would be enforcing the decision is applied correctly and possibly performing data filtering of response data.
My question is, does every request therefore need to be sent to Keycloak for the policy decision even if an access token was included in the request? If not, how does the server know that this request is authorized as this request might be different that the initial one that caused the access token to be generated?
I’m trying to figure out how to design my APIs and resources, policies, and permissions so that requests back to Keycloak are limited because my APIs will have heavy traffic and I want to limit the amount of traffic that needs to be sent to Keycloak.
As a result, Keycloak will evaluate all policies associated with the resource(s) and scope(s) being requested and issue an RPT with all permissions granted by the server.
It sounds like you need to configure your client i.e. resource server in Keycloak so that it knows how to map from your REST API to resources and scopes. In this way, it knows for every request what the resource and scope is. Since all of the permissions for the resource/scope are put in the RPT, the next request would have all of this information available to the resource server that includes the RPT. I suppose then that the resource server could just “enforce” the policy decision using the RPT and not need to send a request back to Keycloak. This assumes that the resource server itself also understands the scopes and resources of the request so that it can apply the permissions from the RPT directly. I assume this is all handled seamlessly by the adapter?
If all of that is true, then only when the client is making a new request for a new resource or scope that is not already in an existing RPT would a request need to be sent to Keycloak for the policy decision. If allowed, a new RPT would be issued.
My next question then is what does the client do with all of these RPTs? Does a new RPT replace the existing RPT or are they all concatenated somehow in the headers? Or does the client somehow need to know which RPT to send with which request?
This parameter is optional . A previously issued RPT which permissions should also be evaluated and added in a new one. This parameter allows clients in possession of an RPT to perform incremental authorization where permissions are added on demand.
So it looks like this answers my last question. You can provide the previous RPT when you get a new RPT so that permissions are incrementally added. Is this the default way of doing things when using the Keycloak adapter?