Modular design of authentication schemes for a http client

I want to make a httpClient wrapper that is able to use a predefined set of authentification methods: basic, digest, token (oauth), ntlm just to name a few that I will have to implement.

My approach to this was inspired by the Apache implementation of Authentication Schemes in java, which is creating an Auth class, and adding it to the http client, which makes it very easy for the user to assign a authentification method:

main.cpp:

ApiClient api_client;

ApiClient::api_client_config_t config = {};
config.host = "https://en52ztuigmv6x.x.pipedream.net";
config.auth = std::unique_ptr<AuthMethod>
    (new AuthMethodBasic("foo", "bar"));

api_client.init(std::move(config));     
api_client.get("/anything");

Though, to make this work, on the backend, I’ve had to create forward declarations and friend all derived classes of AuthMethod that will need access to the ApiClients internals.

api_client.h:

class AuthMethod;
class AuthMethodInternal;
class AuthMethodToken;
class AuthMethodNtlm;

class ApiClient {
friend class AuthMethod;
friend class AuthMethodInternal;
friend class AuthMethodToken;
friend class AuthMethodNtlm;

Reading through a answer on friend inheritance I do seem to follow those requirements, specifically:

Any change in the internal representation of a class will require a modification to anything that is dependent on that representation. Thus all members of a class and also all friends of the class will require modification.

As I’m the only one able to create new authentication methods, or modify the internals, a change in the internal design of ApiClient wouldn’t be an issue. But there also seem to be opinions about friend inheritance being a sign of bad design.

At this point I’ve decided to ask for suggestions to see if there is a different design architercure I might be able to use, as this current design is starting to stink.

My requirements are quite simple honestly:

• Modular, so I can easily add new authentication methods – (this means they would probably have to be self-contained, so that it doesn’t require modifying the base ApiClient code)

Reasoning behind AuthMethod having to access the internals of ApiClient:

• Only the client knows the host url, port, certificate, etc
• By the time authentication kicks in, the ApiClient has already created a httpClient instance handle, and properly configured it. Creating another one would be a waste of resources (which on a embedded platform is double not good)