Kusk Gateway Support for JWT

[jasmingacic]

No description provided.

[aabedraba]

We should investigate for either JWT or API Keys. Let's have a discussion about it soon.

[jasmingacic]

API Keys are already handled by header auth JWT is something esle.

@mbana do you agree?

[aabedraba]

We should really rename "Header auth" to "Custom Auth Upstream" or something of that sorts, because that really reflects what it is.

But in any case, it is possible to achieve now API Keys through custom upstream... In fact even JWT would be possible to achieve with the same method...

I was thinking we should have a dedicated auth policy for both JWT and API Keys. Question is which one is first.

[jasmingacic]

Refreshing this issue and putting it in our scope.

Essentially we'd have to do something similar to this:

x-kusk:
  auth:
    jwt: 
        providers:
          provider1:
            issuer: https://provider1.com
            local_jwks:
              inline_string: PUBLIC-KEY
          provider2:
          issuer: https://provider2.com
          local_jwks:
              inline_string: PUBLIC-KEY
        rules:
        - match:
            prefix: /any
          requires:
            requires_any:
              requirements:
              - provider_name: provider1
              - provider_name: provider2
        - match:
            prefix: /all
          requires:
            requires_all:
              requirements:
              - provider_name: provider1
              - provider_name: provider2
       
...

We should adhere how it is done in envoy see below
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter#config-http-filters-jwt-authn

The easy thing is that JWT implementation is very granular and is handled by "prefix" filter.

[jasmingacic]

Thinking of this we should maybe do something like

x-kusk:
  auth:
    jwt: 
        providers:
          provider1:
            issuer: https://provider1.com
            local_jwks:
              inline_string: PUBLIC-KEY
          provider2:
          issuer: https://provider2.com
          local_jwks:
              inline_string: PUBLIC-KEY 

    paths:
      /hello:
     x-kusk:
         jwt:
          rules: | # logical OR  in Envoy terms this would match requires_any
             - provider1 
                provider2
# alternatively for logical AND or in Envoy requires_all 
              - provider1
              - provider2 
              -

[mbana]

Worthy of mention: https://docs.mia-platform.eu/docs/development_suite/api-console/advanced-section/api-gateway-envoy/jwt-authn.

What do you think?

[jasmingacic]

Let's take inspiration from anywhere.

This is an important feature needed to enable another user.

[aabedraba]

openapi: 3.1.0
info:
  title: My API
  version: 1.0.0
x-kusk:
  auth: 
    jwt: 
      issuer: https://my-issuer.com # required 
      
      jwks: https://my-issuer.com/.well-known/jwks.json
      # either/or
      jwks_config_ref: 
        name: my-secret
        namespace: jwks

      audience: my-audience #optional
paths:
  /:
    x-kusk:
      auth: 
        jwt: 
          issuer: https://my-issuer.com
          jwks: https://my-issuer.com/.well-known/jwks.json
    get:
      x-kusk:
        auth: 
          jwt: 
            issuer: https://my-issuer.com
            jwks: https://my-issuer.com/.well-known/jwks.json
      operationId: get-root
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                    example: Hello World!