I think there may be a misunderstanding (quite possibly on my part): you seem to be talking about two different components.
The first is Graphite (https://graphite.readthedocs.io/en/latest/install.html):
Graphite renders graphs using the Cairo graphics library
In other words, while we usually call the whole setup graphite, graphite is actually the front-end to the database carbon stores data in (Whisper or Ceres).
Basic-Auth, as you say, is for the web interfaces graphite offers, notably the render API (and more generally, services the graphite process/daemon offers over HTTP).
To put that in place (generally - I don't know the details for your specific situation), you could check this question: Graphiti / Graphite using Apache with Proxy and BasicAuth requests auth for every URL / request - they have the opposite issue where they have to authenticate constantly (and an answer about why that might be).
They provide their full config, but in general, the following block is what matters:
Allow from all
However, you also mention port 2003, which is not related to any of the web APIs or pages.
Port 2003 is instead used by carbon-cache (or carbon-relay), to receive metric data.
carbon-cache.py accepts metrics over various protocols and writes them to disk as efficiently as possible
It does not use HTTP, which is why Basic-Auth is not working.
I am not sure what best-practice or convention is for securing carbon, but I had always thought it was a matter of restricting access to the service (i.e. port) in the first place.
You could add a layer that spoke HTTP between your metric sources, and your carbon-cache, in order to have Basic Auth in place for it.
You could also add something like HAProxy to do SSL termination and client validation, but I am not sure how easy it would be to make metric sources use SSL/TLS in the first place.