FusionAuth Angular SDK

This SDK helps manage authentication state for your Angular app and provides functionality to login, register, and logout users. It also can be configured to automatically manage your refresh token.

Your users will be sent to FusionAuth’s themeable hosted login pages and then log in. After that, they are sent back to your Angular application.

Once authentication succeeds, the following secure, HTTP-only cookies will be set:

  • app.at - an OAuth Access Token

  • app.rt - a Refresh Token used to obtain a new app.at. This cookie will only be set if refresh tokens are enabled on your FusionAuth instance.

The access token can be presented to APIs to authorize the request and the refresh token can be used to get a new access token.

There are 2 ways to interact with this SDK:

  1. By hosting your own server that performs the OAuth token exchange and meets the server code requirements for FusionAuth Web SDKs.
  2. By using the server hosted on your FusionAuth instance, i.e., not writing your own server code.

If you are hosting your own server, see server code requirements.

You can use this library against any version of FusionAuth or any OIDC compliant identity server.

Getting Started

Installation

NPM:

npm install @fusionauth/angular-sdk

Yarn:

yarn add @fusionauth/angular-sdk

Configuring FusionAuthModule

Usage

FusionAuthService

The injectable FusionAuthService class provides observable properties to which components may subscribe.

Note, you can also use the non-observable getUserInfo method if you wish to implement your observables.

Pre-built buttons

There are three pre-styled buttons that are configured to perform login/logout/registration. They can be placed anywhere in your app as is.

State parameter

The startLogin and startRegistration functions both accept an optional string parameter called state. The login and register components can also be passed the state as an input. The state that is passed in to the function call will be echoed back in the state query parameter of the callback uri specified in redirectUri on the FusionAuthConfig used to initialize the FusionAuthModule. Though you may pass any value you would like for the state parameter, it is often used to indicate which page the user was on before redirecting to login or registration, so that the user can be returned to that location after a successful authentication.

SSR

The SDK supports Angular applications using SSR. No additional configuration is needed.

Known Issues

None.

Quickstart

See the FusionAuth Angular Quickstart for a full tutorial on using FusionAuth and Angular.

Documentation

Full library documentation

Usage With FusionAuth Cloud

When developing against a FusionAuth Cloud instance with a hostname ending in fusionauth.io, unless your application shares the same domain of fusionauth.io attempts to use these endpoints will fail with a 403 status code.

These endpoints do not work correctly for cross origin requests. Cross origin requests occur when the application making the request to FusionAuth is using a separate domain. For example, if your application URL is app.acme.com and the FusionAuth URL is acme.fusionauth.io requests from your application to FusionAuth will be considered cross origin.

If possible, have FusionAuth and your application served by the same domain, using a proxy if needed. For example, serve your app from app.acme.com and FusionAuth from auth.acme.com.

If this configuration is not possible, use one of these alternative methods:

Modifying FusionAuth CORS configuration options does not fix this issue because the cookies that FusionAuth writes will not be accessible cross domain.

Source Code

The source code is available here: https://github.com/FusionAuth/fusionauth-javascript-sdk/tree/main/packages/sdk-angular/

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.