Hi team. I have a basic question regarding authen...
# help
d
Hi team. I have a basic question regarding authenticating aux data (JWT token). I have read this page: https://docs.cerbos.dev/cerbos/latest/configuration/index.html & https://docs.cerbos.dev/cerbos/latest/configuration/auxdata.html#_jwt I'm trying to implement using a local data key set, but I have a hard time to understand what is the actual intended input here. Based on the key-set information, it seems that it want the
Base64-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:
Copy code
sign(payload, tokenSecret, {}); // Utilizing default settings for jsonwebtoken
This utilizes the default algorithm
HS256
Then we define the jwt keySet as following:
Copy code
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:
Copy code
const buildJWKFromSecret = (tokenSecret: string) => ({
  k: Buffer.from(tokenSecret, 'utf-8').toString('base64'),
  alg: 'HS256',
});
Or just the secret
Copy code
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.
Another topic, I read the following:
Copy code
When 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).
o
Hi @David Nilsdotter, This page describes how to configure cerbos. An example cerbos configuration would be:
Copy code
---
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:
Copy code
{
  "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.
d
Thanks for the response, and the example of defining the
keySetId
👍 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,
cerbie 1