key-auth vs basic-auth plugin behaviour

[zpevma]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.6.0

Current Behavior

key-auth and basic-auth plugins behave differently when setting www-authenticate header with anonymous config option:

• key-auth sets www-authenticate: Key realm="kong" header with anonymous option set
• basic-auth doesn't set www-authenticate: Basic realm="service" header with anonymous option set

Expected Behavior

I'm trying to achieve the following behaviour:

• allow all consumers to use key-auth or basic-auth authentication on all services/routes: OR scenario from https://docs.konghq.com/gateway/latest/kong-plugins/authentication/reference/#multiple-authentication
• if client provides valid key-auth header apikey:<key>, access is granted
• if client is a browser, www-authenticate: Basic realm="service" header is returned and browser prompts user with login window

The idea is to use key-auth and basic-auth globally, both configured with anonymous consumer. Based on plugin ordering documentation, key-auth is evaluated first, sets www-authenticate: Key realm="kong" header, then basic-auth plugin is evaluated and overwrites www-authenticate header with Basic realm="service" value. The last step fails as we can see below.

Steps To Reproduce

Following declarative configuration

_format_version: "3.0"

services:
- name: test.service
  url: https://upstream.internal
  routes:
    - name: basic.route
      paths:
        - /basic
      plugins:
        - name: basic-auth

    - name: key.route
      paths:
        - /key
      plugins:
        - name: key-auth
    
    - name: basic-anon.route
      paths:
        - /basic-anon
      plugins:
        - name: basic-auth
          config:
            anonymous: anonymous
    
    - name: key-anon.route
      paths:
        - /key-anon
      plugins:
        - name: key-auth
          config:
            anonymous: anonymous
            

consumers:
- username: anonymous
  plugins:
  - name: request-termination
    config:
      status_code: 401
      message: Unauthorised

Produces following behaviour:

test~ % curl -s -D - -o /dev/null -k https://kong/basic   
HTTP/2 401 
date: Sat, 17 Feb 2024 17:53:13 GMT
content-type: application/json; charset=utf-8
www-authenticate: Basic realm="service"
content-length: 81
x-kong-response-latency: 1

test~ % curl -s -D - -o /dev/null -k https://kong/key  
HTTP/2 401 
date: Sat, 17 Feb 2024 17:53:19 GMT
content-type: application/json; charset=utf-8
www-authenticate: Key realm="kong"
content-length: 96
x-kong-response-latency: 1

test~ % curl -s -D - -o /dev/null -k https://kong/basic-anon
HTTP/2 401 
date: Sat, 17 Feb 2024 17:53:28 GMT
content-type: application/json; charset=utf-8
content-length: 26
x-kong-response-latency: 1

test~ % curl -s -D - -o /dev/null -k https://kong/key-anon  
HTTP/2 401 
date: Sat, 17 Feb 2024 17:53:34 GMT
content-type: application/json; charset=utf-8
www-authenticate: Key realm="kong"
content-length: 26
x-kong-response-latency: 

test~ %

As we can see, route with basic-auth plugin together with anonymous config doesn't return any www-authenticate header.

I'm not sure what correct behaviour should be (returning www-authenticate header in all cases would solve my issue 😉 ), but I would expect consistency between key-auth and basic-auth plugins.

Anything else?

No response

[nowNick]

Hi @zpevma !

Thank you for bringing that up :) ! There's an ongoing effort to keep auth plugins behaviour consistent and compliant with RFC7235

A change for basic-auth was introduced with 3.6 and there's an open PR that consolidates this behaviour between key-auth and basic-auth: #11794

Maybe to sum it up - all auth plugins are planned to return www-authenticate header with 401 response. In that header there's also optional realm that can be included if the plugin was configured with it. The only exception will be basic-auth where realm is required and by default it's set to service.