[Hsnmohd]

SystemDefaultCredentialsProvider, the default credentials provider of every client builder, falls back to asking java.net.Authenticator for RequestorType.PROXY credentials for whatever host issued the challenge, so with the common getRequestorType() == PROXY authenticator any origin server that answers 401 Basic is sent the JVM's proxy credentials (reproduced with HttpClients.createDefault() and HttpAsyncClients.createDefault(), direct and behind a proxy); skip the PROXY lookup when the auth scope is the host:port of the request being executed, which leaves 407 handling for forwarded and CONNECT requests unchanged.

[ok2c]

@Hsnmohd HttpClient always requests credentials for a given authentication scope consisting of a combination of a host name, a port, a realm and a scheme.

Conceptually, would consider it possible for a proxy and a server to use the same port on the same host and have different security model and access control?

[Hsnmohd]

Not really. A host:port is one listener. It can act as both a proxy and an origin (httpd with mod_proxy, say), but that's still one endpoint under one admin, and the realm is what separates its protection spaces. Keying credentials on (host, port, realm, scheme) is right, and this PR doesn't change that.

The leak comes from the requestor type, not the scope. On a 401 from an origin, the provider asks the Authenticator for SERVER and then for PROXY at the origin's host:port, which tells the Authenticator the origin is a proxy. The JDK's own clients only ask for PROXY on a 407 from the configured proxy, so the usual Authenticator hands out the proxy password whenever getRequestorType() == PROXY and never checks the host. With HttpClients.createDefault(), any server that answers 401 Basic gets that password.

getCredentials can't see whether the challenge was a 401 or a 407, so the PR relies on the point above: the host:port the current request is addressed to is the origin for that request, not its proxy, so it only gets the SERVER lookup. A 407 is scoped to the proxy's host:port, which differs from the request target for both forwarded requests and CONNECT, so proxy auth works as before.

[ok2c]

The leak comes from the requestor type, not the scope.

@Hsnmohd There is no leak as long as proxy / server share the same host and port.

[ok2c]

@Hsnmohd You still want the requester type to be factored in when requesting credentials, this needs to be solved differently. The correct way would be by extending AuthScope.

[Hsnmohd]

@ok2c Fair, the host:port check was the wrong tool for that. Reworked it the way you suggested: AuthScope now carries an optional ChallengeType (null applies to both), Basic, Digest, Bearer and SCRAM set it from the challenge they processed, and SystemDefaultCredentialsProvider asks the Authenticator for SERVER on target challenges and PROXY on proxy challenges. Untyped scopes keep the existing SERVER-then-PROXY lookup.

The challenge type is left out of equals/hashCode/match, since including it breaks exact-scope lookups in existing providers (it tripped the eq(new AuthScope(...)) stubs in TestAuthenticationHandler). I can make it part of match if you want BasicCredentialsProvider to honor it too.

[ok2c]

The challenge type is left out of equals/hashCode/match, since including it breaks exact-scope lookups in existing providers

@Hsnmohd These two scopes being equal, does not feel right. I think challenge type must be included in #equals, #hashCode and #match. If that breaks existing providers we need to figure out how to un-break them.

final AuthScope authScope1 = new AuthScope(host, getRealm(), getName(), ChallengeType.TARGET);
final AuthScope authScope2 = new AuthScope(host, getRealm(), getName(), ChallengeType.PROXY);

[ok2c]

@Hsnmohd Please review #934

[Hsnmohd]

Reviewed #934, comments are there. Short version: Bearer and SCRAM drop the challenge type, and it outweighs host in match. #934 doesn't touch SystemDefaultCredentialsProvider, so the leak is still there with it alone. Once it lands I'll rebase this down to the provider change and its tests.

[ok2c]

@Hsnmohd Please re-base your change-set on the latest master.

[Hsnmohd]

@ok2c Rebased. It's down to the SystemDefaultCredentialsProvider change and its tests on top of #934: SERVER for TARGET scopes, PROXY for PROXY scopes, and untyped scopes keep the old SERVER-then-PROXY lookup. The new tests fail against master's provider and pass with this, and HttpClients.createDefault() / HttpAsyncClients.createDefault() no longer send the system proxy credentials to an origin answering 401 Basic, while 407s from the proxy still get them.