23

I wrote the following HttpClient code, and it did not result in an Authorization header being sent to the server:

public static void main(String[] args) {
    var client = HttpClient.newBuilder()
            .authenticator(new Authenticator() {
                @Override
                protected PasswordAuthentication getPasswordAuthentication() {
                    return new PasswordAuthentication("username", "password".toCharArray());
                }
            })
            .version(HttpClient.Version.HTTP_1_1)
            .build();
    var request = HttpRequest.newBuilder()
            .uri("https://service-that-needs-auth.example/")
            .build();
    client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
            .thenApply(HttpResponse::body)
            .thenAccept(System.out::println)
            .join();
}

I'm getting an HTTP 401 error from the service I'm calling. In my case, it's the Atlassian Jira Cloud API.

I have confirmed that my getPasswordAuthentication() method is not being invoked by HttpClient.

Why isn't it working, and what should I do instead?

Naman
  • 27,789
  • 26
  • 218
  • 353
Jonathan Fuerth
  • 2,080
  • 2
  • 18
  • 21

1 Answers1

52

The service I was calling (in this case, Atlassian's Jira Cloud API) supports both Basic and OAuth authentication. I was attempting to use HTTP Basic, but it sends back an auth challenge for OAuth.

As of the current JDK 11, HttpClient does not send Basic credentials until challenged for them with a WWW-Authenticate header from the server. Further, the only type of challenge it understands is for Basic authentication. The relevant JDK code is here (complete with TODO for supporting more than Basic auth) if you'd like to take a look.

In the meantime, my remedy has been to bypass HttpClient's authentication API and to create and send the Basic Authorization header myself:

public static void main(String[] args) {
    var client = HttpClient.newBuilder()
            .version(HttpClient.Version.HTTP_1_1)
            .build();
    var request = HttpRequest.newBuilder()
            .uri(new URI("https://service-that-needs-auth.example/"))
            .header("Authorization", basicAuth("username", "password"))
            .build();
    client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
            .thenApply(HttpResponse::body)
            .thenAccept(System.out::println)
            .join();
}

private static String basicAuth(String username, String password) {
    return "Basic " + Base64.getEncoder().encodeToString((username + ":" + password).getBytes());
}
Eugene
  • 117,005
  • 15
  • 201
  • 306
Jonathan Fuerth
  • 2,080
  • 2
  • 18
  • 21
  • 8
    Thanks for reporting this - it is now logged as https://bugs.openjdk.java.net/browse/JDK-8217237 - The work around you are suggesting looks like the right thing to do. Alternatively, if you don't supply any Authenticator, and wanted to check the server challenge first, you could choose to deal with the 401/407 reply instead of preemptively supplying the Authorization header. – daniel Jan 16 '19 at 10:41
  • Thanks for filing that issue. It will be an important improvement to the standards compliance of HttpClient. I just wanted to clarify, though: the issue here is not the same as the one you described in JDK-8217237. In the case of Atlassian Cloud, the only auth challenge sent by the server is for OAuth. There is no Basic auth challenge. Try `curl -v https://example.atlassian.net/rest/agile/1.0/board/44/issue` to see the response headers HttpClient would be dealing with in this case. – Jonathan Fuerth Jan 16 '19 at 13:43
  • Oh. Well - if the server doesn't send the BASIC challenge there's not much that the HttpClient could do: the HttpClient only implements basic out of the box. The bug (JDK-8217237) is still a bug though. – daniel Jan 16 '19 at 16:29
  • Agreed. Thanks again! – Jonathan Fuerth Jan 17 '19 at 13:03
  • openjdk version "1.8.0_191" receives 407 from Proxy, it only works with setting HttpURLConnection.setRequestProperty("Proxy-Authorization", basicAuth); jdk.http.auth.tunneling.disabledSchemes="" does not help. – weberjn Feb 18 '19 at 13:01
  • 1
    pretty crazy! I can't believe that the fix version for this is `13` :| we hit this one today and I kept saying to the dev that *it's obvious* he is doing something wrong, how wrong was I... – Eugene Feb 20 '19 at 01:17