using yaml for token config

[gfrankliu]

I tried below yaml token config:

# use jwt token from auth provider 1 if exists, otherwise trigger oauth from provider 2
eas:
  plugins:
    - type: jwt
      header_name: my-jwt-header
      config:
        secret: https://www.provider1.com/public_key-jwk.json
        options:
          audience: /special/audience/for/me
          issuer: https://www.provider1.com
      pcb:
        skip:
          - query_engine: jp
            query: $.req.headers.my-jwt-header
            rule:
              method: regex
              value: /^bearer/i
              negate: true
    - type: oidc
      issuer:
        discover_url: https://www.provider2.com/.well-known/openid-configuration
      client:
        client_id: aaaaa
        client_secret: bbbb
      scopes:
        - openid
        - email
        - profile
      pkce:
        enabled: true
        code_challenge_method: S256

When I test to send a curl request with header my-jwt-header, external-auth-server throws below errors about json:

{"level":"info","message":"starting verify for plugin: jwt","service":"external-auth-server","timestamp":"2023-07-25T23:12:10.380Z"}
{"level":"error","message":"Lexical error on line 1. Unrecognized text.\n$.req.headers.my-jwt-header\n---------------^","service":"external-auth-server","stack":"Error: Lexical error on line 1. Unrecognized text.\n$.req.headers.my-jwt-header\n---------------^\n    at Parser.parseError (/home/eas/app/node_modules/jsonpath/generated/parser.js:166:15)\n    at Parser.parser.yy.parseError (/home/eas/app/node_modules/jsonpath/lib/parser.js:13:17)\n    at Object.parseError (/home/eas/app/node_modules/jsonpath/generated/parser.js:341:28)\n    at Object.next (/home/eas/app/node_modules/jsonpath/generated/parser.js:595:25)\n    at Object.lex (/home/eas/app/node_modules/jsonpath/generated/parser.js:605:22)\n    at lex (/home/eas/app/node_modules/jsonpath/generated/parser.js:194:28)\n    at Parser.parse (/home/eas/app/node_modules/jsonpath/generated/parser.js:207:26)\n    at JSONPath.nodes (/home/eas/app/node_modules/jsonpath/lib/index.js:118:26)\n    at JSONPath.query (/home/eas/app/node_modules/jsonpath/lib/index.js:94:22)\n    at Assertion.jsonpath_query (/home/eas/app/src/assertion/index.js:41:23)","timestamp":"2023-07-25T23:12:10.380Z"}

Is query_engine jp not supported in yaml format?

BTW, our jwt header doesn't have "bearer" in it. I manually added it in my manual curl test. If the real client sends the jwt header without "bearer", will that be a problem for external-auth-server? Is there a query rule that can check the existence of a header?

[travisghansen]

$ is a special char in yaml so you may need to quote or escape it in your yaml.

As long as the header_name is not authorization I think you can set the scheme attribute to empty string "" and it should work (https://github.com/travisghansen/external-auth-server/blob/master/PLUGINS.md?plain=1#L157)

[gfrankliu]

I tried quoting the string: query: "$.req.headers.my-jwt-header" but got the same error.

[gfrankliu]

Is below ok to check if the header doesn't exist?

          - type: jwt
            header_name: my-jwt-header
            scheme: ""
            pcb:
              skip:
                - query_engine: jp
                  query: "$.req.headers.my-jwt-header"
                  rule:
                    method: regex
                    value: /./
                    negate: true

[travisghansen]

Actually, I just tested it and you've found a bug in the library (https://github.com/dchester/jsonpath) the problem has nothing to do with the $ it's the - in the query. Based on my research this should work $.req.headers."my-jwt-header" but does not. Further it appears that library has fallen into bitrot so it seems unlikely to get fixed anytime soon :(

As an alternative use another query engine. For example if you allow eval you can use the js engine:

            query_engine: js
            query: "try { return data.req.headers[\"my-jwt-header\"]; } catch (e) { return undefined; }"

[gfrankliu]

Glad you were able to reproduce and thanks for the alternative way. I tried it and got:

{"level":"error","message":"cannot use potentially unsafe query_engine 'js' unless env variable 'EAS_ALLOW_EVAL' is set","service":"external-auth-server","stack":"Error: cannot use potentially unsafe query_engine 'js' unless env variable 'EAS_ALLOW_EVAL' is set\n    at Object.json_query (/home/eas/app/src/utils.js:425:15)\n    at Assertion.query (/home/eas/app/src/assertion/index.js:63:29)\n    at Assertion.assert (/home/eas/app/src/assertion/index.js:78:28)\n    at Function.assertSet (/home/eas/app/src/assertion/index.js:18:36)\n    at processPipeline (/home/eas/app/src/server.js:392:42)\n    at /home/eas/app/src/server.js:483:7\n    at new Promise (<anonymous>)\n    at _verifyHandler (/home/eas/app/src/server.js:313:12)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async verifyHandler (/home/eas/app/src/server.js:97:12)","timestamp":"2023-07-29T04:25:28.859Z"}

Then I set env EAS_ALLOW_EVAL to 1, but got another error when sending a request without jwt header:

{"level":"error","message":"Cannot read properties of undefined (reading 'case_insensitive')","service":"external-auth-server","stack":"TypeError: Cannot read properties of undefined (reading 'case_insensitive')\n    at Assertion.assert (/home/eas/app/src/assertion/index.js:83:14)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async Function.assertSet (/home/eas/app/src/assertion/index.js:18:20)\n    at async processPipeline (/home/eas/app/src/server.js:392:26)","timestamp":"2023-07-29T04:27:45.564Z"}

Finally sending a request with real jwt header:

{"level":"error","message":"Cannot read properties of undefined (reading 'case_insensitive')","service":"external-auth-server","stack":"TypeError: Cannot read properties of undefined (reading 'case_insensitive')\n    at Assertion.assert (/home/eas/app/src/assertion/index.js:83:14)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async Function.assertSet (/home/eas/app/src/assertion/index.js:18:20)\n    at async processPipeline (/home/eas/app/src/server.js:392:26)","timestamp":"2023-07-29T04:39:11.117Z"}

(seems same error as if I were to not send jwt header at all.

[travisghansen]

Did you remove the rule block?

[gfrankliu]

Yes I did:

          - type: jwt
            header_name: x-goog-iap-jwt-assertion
            scheme: ""
            config:
              secret: https://www.gstatic.com/iap/verify/public_key-jwk
              options:
                audience: /projects/1111111111/global/backendServices/222222
                issuer: https://cloud.google.com/iap
            pcb:
              skip:
                - query_engine: js
                  query: "try { return data.req.headers[\"x-goog-iap-jwt-assertion\"]; } catch (e) { return undefined; }"

[gfrankliu]

BTW, the bug you found in jsonpath doesn't seem to exist in jsonata, so if I use query_engine: jsonata, I am able to use $.req.headers."my-jwt-header" like you suggested. Now the question is how I can have a pcb rule like:

                  rule:
                    method: eq
                    value: undefined

so I can skip if the header doesn't exist. I tried but the engine seems to treat "undefined" as literal string match :(

[travisghansen]

You still need the rule with the js engine as well FYI. I think the regex syntax you had may work if you simply to /.*/ but I would need to test to be sure..

[gfrankliu]

Tried but didn't work.

[travisghansen]

I’ll look at this later in the day and get you a working example.

[travisghansen]

I think this will work with the existing codebase:

                - query_engine: js
                  query: "try { return data.req.headers[\"my-jwt-header\"]; } catch (e) { return ''; }"
                  rule:
                    method: regex
                    value: /\w/i
                    negate: true

Give it a try and let me know. I have some minor fixes to commit to make this work better due to javascript oddities but the above should do what you want.

[gfrankliu]

It doesn't seem to work. When I send a request without jwt header, I expect to see "skipping plugin due to pcb", something like:

{"level":"info","message":"starting verify for plugin: jwt","service":"external-auth-server","timestamp":"2023-08-02T05:11:39.347Z"}
{"level":"info","message":"skipping plugin due to pcb assertions: jwt","service":"external-auth-server","timestamp":"2023-08-02T05:11:39.348Z"}

but I saw below instead:

{"level":"info","message":"starting verify for plugin: jwt","service":"external-auth-server","timestamp":"2023-08-02T05:26:56.251Z"}
{"level":"warn","message":"failed assertion: {\"query_engine\":\"js\",\"query\":\"try { return data.req.headers[\\\"my-jwt-header\\\"]; } catch (e) { return ''; }\",\"rule\":{\"method\":\"regex\",\"value\":\"/\\\\w/i\",\"negate\":true}} against value: undefined","service":"external-auth-server","timestamp":"2023-08-02T05:26:56.251Z"}

[gfrankliu]

Maybe I don't need this pcb rule. I assume the default jwt plugin will already do the same: skip to next plugin if jwt header doesn't exist.

[travisghansen]

Yes it will. I typically would use the skip also with a stop (this helps ensure the response to applicable clients is more focused and relevant to the client). For example you don’t really want to redirect a machine to an oauth endpoint.

I think I know why you’re getting that, let me try 1 more variation and send it your way.