Problem/Motivation
Many platforms and development environments use Basic Auth configured on the server to provide a Site Lock. This allows making sites available to select people via the public web without exposing the site to the public in general. For example, https://pantheon.io/docs/lock-environment/.
This might manifest if you are not thinking about it as though the user/login form itself is throwing an access denied, or on further investigation and confirmation of permissions that all pages are mysteriously throwing an access denied.
Per http://drupal.stackexchange.com/a/212800/394 and an examination of the Basic Auth provider code, what's happening is that if you use Basic Auth headers, PHP will pick them up and the Basic Auth module in core will be "triggered' to attempt authentication with those credentials. If it fails, the response will be redirected to access denied. After all, a login attempt just failed.
The frustration level this issue can cause makes it a major DX issue when the stars align, and while I marked it as a bug, you could argue it's a support request.
Proposed resolution
This issue is complicated because it could be considered a feature, not a bug. However, there is a common expectation that a "site lock" can be configured without regard for the application configuration.
One solution could be a simple configuration option that allows checking to see if the user account does not exist, and if not treat it as an anonymous request.
Another possibility would be supporting the Drupal site issuing Basic Auth challenges, allowing the site itself to provide the "lock UI".
Remaining tasks
Decide if this is a problem that should be solved. If not solved, this becomes a documentation problem to explain what's going on and recommended workarounds.
User interface changes
?
API changes
?
Data model changes
?