why? It's not "a security scheme" by the modern definition of authentication mechanisms, whose weaknesses after 30 years are well documented.
- No defence against MITM - Transmits credentials over the wire; if stolen are gone until you next roll the secre. - Doesn't validate message integrity - etc About the only thing in its favour is the clients don't need to rely on an library to do the auth as it's built into most http clients. But if you only support basic auth then you can only talk to those catalogs that implemented it, so are either restricted to a subset of catalogs or, if the app turns out to be popular, force all implementations to support an auth mechanism which we all agree is flawed. I would personally advocate for the # of auth mechanisms to be kept to an absolute minimum, ideally: 1: 1. Testing interoperability becomes a lot easier as everyone authenticates the same way. 2. If a client has an auth problem, it's likely to surface everywhere i know basic auth is easy to set up so you can deploy a dev system without having to set up a more complex authentication protocol -but requiring those dev systems to use a stricter auth protocol forces everyone to get that implementation right as failures will happen during development, rather than only surfacing in production. >
