Basic Auth 403 Response to an Unauthorised user

[Technocaveman]

NOTE: GitHub issues are reserved for bug reports only. For anything else,
please join the conversation in Kong Nation https://discuss.konghq.com/.

Please read the CONTRIBUTING.md guidelines to learn on which channels you can
seek for help and ask general questions:

https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#where-to-seek-for-help

Summary

So On Kong 0.14.0 We are trying to use Basic Auth to authenticate the Users.

We have managed to get everything Working, but if the wrong user name and passwors is supplied, the Kong instance responds with 403 Forbidden.

{ "message": "Invalid authentication credentials" }

In my admittedly small amount of knowledge i thought that 403 was for situations when the username and password were correct but the resource requires more permissions than that user has.

So in my mind it should respond with 401. If i am wrong i would love to know why that is.

Thanks

Steps To Reproduce

1. Build an api and link it to kong
2. Enable the Basic auth plugin and Create a consumer and give it a username and password
3. Try to contact the kong API with a wrong username or password
4. the response should be 401 not 403

Additional Details & Logs

• Kong version ($ kong version)
  0.14.0
• A shell script exerpt that sets up our kong
  `echo "Setting up test-api service on Kong..."
  echo ""
  curl -s -X POST
  --url http://localhost:${PORT}/services/
  --data 'name=test-api'
  --data 'url=http://test-api:9000'

echo ""
echo ""
echo "Setting up route for test-api"
echo ""
curl -s -X POST
--url http://localhost:${PORT}/services/test-api/routes
--data 'hosts[]=test-api'

echo ""
echo ""
echo "Configuring the basic-auth plugin for Kong..."
curl -X POST http://localhost:${PORT}/services/test-api/plugins
--data "name=basic-auth"
--data "config.hide_credentials=true"
echo "Configuring a consumer for Kong..."
curl -d "username=test-consumer&custom_id=db-alias-1" http://localhost:${PORT}/consumers/

echo ""
echo ""
echo "Configuring credential for test consumer for Kong..."
curl -X POST http://localhost:${PORT}/consumers/test-consumer/basic-auth
--data "username=${USERNAME}"
--data "password=${PASSWORD}"

CREDENTIAL=$(echo ${USERNAME}:${PASSWORD} | base64)
`

• Operating system
  Mac OS High Sierra 10.13.6 (17G65)
  I am using Docker to bring up kong and the API but it shouldn't really make a massive difference

[bungle]

@Technocaveman, thank you for reporting. I marked it as a bug. I need to check is there some reason for current behavior.

[ralther]

Was going to open up this very bug. Kong should be returning a 401 rather than a 403 if the user enters invalid credentials. 403 tells the browser the userid/password was good, but you're not allowed access to the requested resource. At this point, the browser stores the invalid credentials and there's no way for the user to log into Kong unless they either restart the browser to clear login history.

401 is the proper response for invalid credentials.

[Technocaveman]

so we do not want this current behavior as @ralther commented we want it to respond with 401

[bungle]

@Technocaveman, I think there is no disagreement with that. If you want to hurry this, then I suggest making a PR against next branch. I have seen wrong codes used in some of Kong plugins, and I think we need to revisit those, and fix them.

[Dubrzr]

Any update on this? This is indeed very annoying to have a 403 instead of 401 for our users...
How can I help?
Thanks you!

[p0pr0ck5]

I've labelled this as 'needs investigation'. If anyone in the community is able to propose a PR for this, that would be welcome!

[Dubrzr]

It seems to be this line:

kong/kong/plugins/basic-auth/access.lua

Line 182 in fe83467

return false, { status = 403, message = "Invalid authentication credentials" }

I also found this bug in ldap-auth here:

kong/kong/plugins/ldap-auth/access.lua

Line 222 in 0f2d77b

return false, {status = 403, message = "Invalid authentication credentials" }

It also means tests should be updated but I think this is not a complicated job.

[p0pr0ck5]

It does seem that historically the plugin always returned 403, which was incorrect (and partially solved in #354). A patch for this is still welcome, as we may not have time to resolve it immediately!

[Tieske]

An additional question is whether we want details about why it failed to be returned, or just the "401 Unauthorized" to not leak any info.