Logo / Docs

FusionAuth Typescript Client Library

Typescript Client Library

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

Regardless of the fact that this is written in TypeScript, this client supports both Node.js and Browser environments without requiring that your application is also written in typescript.

Installing

Source Code:

NPM Package:

To install the FusionAuth Typescript Client package run:

npm install @fusionauth/typescript-client

Browser bundle:

We also release a prebundled version of the client for the browser on our GitHub releases page. This version can be simply included as an HTML <script> and FusionAuthClient will be available to any scripts on the page.

Examples

Please note that if you will be using this client library in front end code such as a web browser you will not have a secure way to store an API key. You may optionally pass a value of null for the API key parameter and still make API requests that do not require an API key.

The following examples assumes FusionAuth is running on http://localhost:9011 and uses an API key bf69486b-4733-4470-a592-f1bfce7af580, you will need to supply your own API key, and if you are not running FusionAuth locally, your host parameter may be different.

The following examples all use retrieveUserByEmail as a basic use case of FusionAuth. Additionally, while the examples are written in TypeScript, this does not prevent you from using raw JavaScript instead in your own application.

Node.js

import {FusionAuthClient} from '@fusionauth/typescript-client';
const client = new FusionAuthClient('bf69486b-4733-4470-a592-f1bfce7af580', 'https://local.fusionauth.io');
client.retrieveUserByEmail('user@example.com')
      .then(clientResponse => {
        console.log("User:", JSON.stringify(clientResponse.response.user, null, 2));
      }).catch(console.error);

You can also find this example’s source code in the typescript repo.

Browser

In the browser, all of the exported objects are under the namespace FusionAuth to prevent polluting the global namespace.

<script src="fusionauth-typescript-client.min.js"></script>
<script>
const client = new FusionAuth.FusionAuthClient('bf69486b-4733-4470-a592-f1bfce7af580', 'https://local.fusionauth.io');
client.retrieveUserByEmail('user@example.com')
      .then(clientResponse => {
        console.log("User:", JSON.stringify(clientResponse.response.user, null, 2));
      }).catch(console.error);
</script>

You can also find this example’s source code in the typescript repo.

Hybrid

You can write the hybrid exactly the same as the Node.js example (but keep in mind that API keys will be exported so it is not recommended to use API keys at all). The key difference in this case is the build script. Instead of just using tsc to compile and running Node.js on the resulting JavaScript, you will instead use a tool like browserify or webpack to build your script. This example uses browserify for simplicity.

We can easily build a hybrid project using one of two commands, each associated with the target

# Compile for Node.js
tsc
# Compile for browser
npm run build-browser
# AKA
npx browserify example.ts --debug -p tsify -t browserify-shim -o dist/example-browser.js

You can also find this example’s source code in the typescript repo.

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.

Client Authentication

You may use this client library in an application that cannot securely store secrets, such as a native mobile application or a single page application running in the browser.

In this scenario, you should disable Require authentication in the FusionAuth Application configuration and use PKCE to secure communication with the Token endpoint.

You can use the exchangeOAuthCodeForAccessTokenUsingPKCE client method to do so.

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.