Logo / Docs

FusionAuth Java Client Library

Java Client Library

The Java client library allows you to integrate FusionAuth with your Java application.

Source Code:

Maven Dependency

<dependency>
  <groupId>io.fusionauth</groupId>
  <artifactId>fusionauth-java-client</artifactId>
  <version>${fusionauth.version}</version>
</dependency>

When building your application, utilize the version that corresponds to the version of FusionAuth your running. View all available versions on https://search.maven.org.

Using the FusionAuth and consuming the ClientResponse

The Java client has two styles of use, the first return a ClientResponse object. This object contains everything that occurred while communicating with the FusionAuth server. If the communication with the server encountered a network issue, the ClientResponse.exception might contain an IOException.

The following code assumes FusionAuth is running on http://localhost:9011 and uses an API key 6b87a398-39f2-4692-927b-13188a81a9a3, you will need to supply your own API key, and if you are not running FusionAuth locally, your host parameter may be different.

Here is an example of using the retrieveUserByEmail method to retrieve a User by an email address.

import com.inversoft.error.Errors;
import io.fusionauth.client.FusionAuthClient;
import io.fusionauth.domain.User;
import io.fusionauth.domain.api.UserResponse;
import com.inversoft.rest.ClientResponse;
public class Example {
  private final FusionAuthClient client;

  public Example() {
    client = new FusionAuthClient("6b87a398-39f2-4692-927b-13188a81a9a3", "http://localhost:9011");
  }

  public User getUserByEmail(String email) {
    ClientResponse<UserResponse, Errors> response = client.retrieveUserByEmail(email);
    if (response.wasSuccessful()) {
      return response.successResponse.user;
    } else if (response.errorResponse != null) {
      // Error Handling
      Errors errors = response.errorResponse;
    } else if (response.exception != null) {
      // Exception Handling
      Exception exception = response.exception;
    }

    return null;
  }
}

Using the Lambda Delegate

The Java Client may also be used along with our Lambda delegate that provides exception handling and allows you to write code assuming a happy path. Here is the same example from above using the lambda delegate:

import com.inversoft.error.Errors;
import io.fusionauth.client.LambdaDelegate;
import io.fusionauth.client.FusionAuthClient;
import io.fusionauth.domain.User;
import com.inversoft.rest.ClientResponse;
public class Example {
  private final String apiKey = "6b87a398-39f2-4692-927b-13188a81a9a3";

  private final String fusionauthURL = "http://localhost:9011";

  private final FusionAuthClient client;

  private final LambdaDelegate delegate;

  public Example(String apiKey, String fusionauthURL) {
    this.client = new FusionAuthClient(apiKey, fusionauthURL);
    this.delegate = new LambdaDelegate(this.client, (r) -> r.successResponse, this::handleError);
  }

  public User getUserByEmail(String email) {
    return delegate.execute(c -> c.retrieveUserByEmail("user@example.com")).user;
  }

  private <T, U> void handleError(ClientResponse<T, U> clientResponse) {
    if (clientResponse.exception != null) {
      // Handle the exception
      ...
    } else if (clientResponse.errorResponse != null && clientResponse.errorResponse instanceof Errors) {
      // Handle errors
      ...
    }
  }
}

As you can see, using the lambda delegate requires less code to handle the success response and the error handling code can be re-used.

Usage Suggestions

FusionAuth client libraries are a thin wrapper around the REST API. Client libraries are typically used in two different ways.

First, they can be used to access the FusionAuth APIs in a familiar format, leveraging language features like auto-completion. When used for this, they can be helpful to script FusionAuth configuration, automate common tasks, and create copies of existing applications, groups and more.

To use the client libraries effectively in this way, it is helpful to review the source code of the client library and the API documentation, which contains the JSON structure. The API documentation is very thorough about the JSON objects it expects as part of the payload as well as what parameters are required when.

Second, client libraries can exchange a token to let a user to log in via the Authorization Code Grant. This is a secondary use of these libraries. This process is best done by using a language specific OAuth library, which will work with FusionAuth. Here is a community curated list of such libraries.

Client libraries do not currently provide higher level functionality such as token management. Here is an open issue detailing some requested higher level functionality. Please feel free to file an issue or upvote this one if you desire it.

You can always directly call the REST API if the client library functionality doesn’t work for you. All the client libraries use the REST API.

In general, the request object will either be string parameters or a complex object depending on the type of API call being made. Any request object will be mapped by the library to a JSON object required by the corresponding API method. Examining the API documents for the operations you’re trying to call will therefore be useful, especially if you are using language without static typing.

The response object will typically contain:

  • a status corresponding to the HTTP status code returned by the API. It may also be -1 if no HTTP request was successfully made
  • a JSON success object if the call succeeded.
  • a JSON error object with an intelligible message if the status code is 4xx or 5xx.
  • an exception object if there was no HTTP request sent or there was no reasonable response from the server.

PATCH requests

Available Since Version 1.14.0

PATCH requests are handled differently than you might expect. PATCH operations allow you to modify only parts of an object in FusionAuth.

In client libraries with static typing, such as this one for Java, there are no strongly typed objects set as part of a PATCH request. Instead, a hash, dictionary or map object is used. Ensure that you are using multi level dictionaries that create JSON with nested keys, otherwise the PATCH request will fail. This allows use of key value pairs to build a PATCH request.

For example, if you want to change only the name of an application using PATCH, you would want the JSON that is sent across the wire to look like this:

Example PATCH Application JSON

{
  "application": {
     "name": "hooli-bought-us"
   }
}

If you built a typed application request object and then serialized it, it would contain empty arrays or other default values. This would modify the object you were changing in ways you didn’t expect. This would likely cause the system behave in ways you don’t want.

By requiring you to build nested key value pairs, the JSON serialization works correctly. This is essentially a limitation of the current implementation in Java and FusionAuth PATCH support.

For this behavior to work correctly with typed objects, FusionAuth would need to ensure the domain object had no default values, and then instruct the serializer to omit empty objects, empty arrays and other values from the resulting JSON. This would ensure that the PATCH was performed correctly with no unwanted side effects.

Once support for RFC 7396 lands in FusionAuth, there may be some additional options for configuring a JSON serializer to allow use of typed domain objects for PATCH.

An alternative that allows you to use typed objects immediately is to perform a retrieve operation, modify the object in memory, and then execute an update operation. These are functionally equivalent to a single PATCH operation.

Example Apps

Upgrade Policy

Besides the releases made to keep track of the FusionAuth API as mentioned above, SDKs and Client Libraries may periodically receive updates with bug fixes, security patches, tests, code samples, or documentation changes.

These releases may also update dependencies, language engines, and operating systems, as we’ll follow the deprecation and sunsetting policies of the underlying technologies that the libraries use.

This means that after a language, framework, or operating system is deprecated by their own maintainer, our SDKs and Client Libraries that depend on it will also be deprecated by us, and will eventually be updated to use a newer version.