When building a distributable package (likely a Managed Package) that must securely communicate back to a central "Hub" org, the architect must use a framework that supports OAuth 2.0 flows. Storing plain-text or even encrypted passwords (Option B) is a security violation and is brittle across different environments.

The architecturally sound solution is to leverage the Authentication Provider and Named Credentials framework. In the central org, a Connected App is created to act as the OAuth endpoint. In the package, an Authentication Provider is configured using the Consumer Key and Consumer Secret from that Connected App. This setup allows the administrator in the "Subscriber" org (the org where the package is installed) to initiate an OAuth flow.

When the security team "authorizes" the integration after installation, they are essentially completing the OAuth handshake. This grants the subscriber org an Access Token and a Refresh Token associated with the specific integration user in the central org. This mechanism ensures:

Credential Security: No passwords are ever stored in the code or metadata.

Centralized Control: The security team in the central org can revoke the Refresh Token at any time to kill the integration.

Scalability: The same package can be distributed to hundreds of orgs, each with its own unique, secure connection to the central Hub.

By using an Authentication Provider combined with a Named Credential, the Apex code in the package can simply call the endpoint by its developer name, and Salesforce handles the entire authentication header injection automatically, ensuring a robust and secure cross-org integration.