David Nilsdotter
09/18/2024, 6:51 AMBase64-encoded key data defined inline.
What is the key data? Just the token secret, or the whole JWK? If it is the JWK, should the key also be base64-encoded, when defined in teh JWK?
I think I have tried all the different setups, but it continously returns NotOK: gRPC *error* 3 (INVALID_ARGUMENT): invalid auxData
We are signing using the sign function from jsonwebtoken
like the following:
sign(payload, tokenSecret, {}); // Utilizing default settings for jsonwebtoken
This utilizes the default algorithm HS256
Then we define the jwt keySet as following:
const buildJWKFromSecret = (tokenSecret: string) => ({
k: tokenSecret,
alg: 'HS256',
});
...
auxData: {
jwt: {
keySets: [
{
id: 'default',
local: {
data: Buffer.from(JSON.stringify(buildJWKFromSecret(tokenSecret)), 'utf-8').toString('base64'),
},
},
],
},
},
Here I have tried most configurations:
const buildJWKFromSecret = (tokenSecret: string) => ({
k: Buffer.from(tokenSecret, 'utf-8').toString('base64'),
alg: 'HS256',
});
Or just the secret
local: {
data: Buffer.from(tokenSecret, 'utf-8')).toString('base64'),
},
But all configurations result in NotOK: gRPC *error* 3 (INVALID_ARGUMENT): invalid auxData
What am I missing here? If I turn the validation off, the aux data is accessible, and my checks pass, so the JWT token is correctly added to the policy requests. It seems that it is the validation that fails.David Nilsdotter
09/18/2024, 7:00 AMWhen multiple keysets are defined in the configuration file, all API requests must include the keyset ID along with the JWT. When only a single keyset is defined in the configuration, then the keyset ID can be dropped from the API requests.
But I have yet to see how the key set id is added to the policy request?
As I only have one key set, I have not added the key set id "default" in my request (as of yet).oguzhan
---
auxData:
jwt:
disableVerification: false
keySets:
- id: ks1
local:
file: "${HOME}/cerbos/ks1.jwks"
engine:
defaultPolicyVersion: default
server:
grpcListenAddr: ":3593"
httpListenAddr: ":3592"
storage:
driver: disk
disk:
directory: "${HOME}/cerbos/store"
watchForChanges: true
This page shows how to include JWT token (number 16) in a check resources request. An example CheckResources request would look like this:
{
"requestId": "1",
"principal": {
"id": "alex",
"roles": [
"user"
]
},
"resources": [
{
"resource": {
"id": "lr_1",
"kind": "leave_request"
},
"actions": [
"create"
]
}
],
"auxData": {
"jwt": {
"token": "<jwt token here>",
"keySetId": "ks1"
}
}
}
With this configuration and request, cerbos will verify the jwt token provided in the CheckResources
request against the key resting at ${HOME}/cerbos/ks1.jwks
.
Keep in mind that if the request doesn’t include the auxData
block, cerbos will not return an error. Because cerbos is not trying to authenticate the incoming requests from your backend. auxData
is only a convenience to allow the app to forward the client JWT to Cerbos instead of validating, parsing and adding the attributes from jwt into principal attributes.David Nilsdotter
09/18/2024, 8:59 AMkeySetId
👍
It is a good thing that the Cerbos check fails, if the JWT token cannot be verified. This ensures that request comming from our frontend (where the payload can be manipulated) have not been tampered with.
The issue I have is that I would like to inline the jwk-content during Cerbos-deployment, to simplify the process. But here is where I come up short, as I do not seem to understand how the local data content should be defined.
I will try to create a jwk file, and see if it manages to verify the jwt-token,