401 is no authentication information or wrong authentication information, then the client can modify the authentication information to retry;

403 is the client with the correct authentication information, but the server believes that the authentication information corresponding to the user does not have the corresponding resource access rights, so there is no need to retry before obtaining the relevant rights from the administrator.

The logic of using 401 instead of 403 here is actually to hide the message. It is possible for an attacker to determine whether the account password is correct by judging the status code.

@tzssangglass

403 is the client with the correct authentication information, but the server believes that the authentication information corresponding to the user does not have the corresponding resource access rights, so there is no need to retry before obtaining the relevant rights from the administrator.

Yes, this is the case for the place I want to change. So it should use 403.

The logic of using 401 instead of 403 here is actually to hide the message. It is possible for an attacker to determine whether the account password is correct by judging the status code.

I don't understand here. The place to change is when accessing resources, which should have nothing to do with authentication. So there will be no account password operation.

The place to change is when accessing resources, which should have nothing to do with authentication. So there will be no account password operation.

If it returns 403, then the reverse proves that the account password is correct, just without permissions.

This is to prevent password blasting.

Previously, APISIX had a focused change to the auth class plugin to reduce the amount of internal information exposed to the client.

But I'm not so strict about it, so let's hear what others think.

I think 403 can give better support to the client in terms of semantics. The security issues it may cause are less important than changing from 401 to 403.