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 Tokenapp.rt
- a Refresh Token used to obtain a newapp.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:
- By hosting your own server that performs the OAuth token exchange and meets the server code requirements for FusionAuth Web SDKs.
- 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
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppRoutingModule } from './app-routing.module';
import { FusionAuthModule } from '@fusionauth/angular-sdk';
@NgModule({
declarations: [],
imports: [
FusionAuthModule.forRoot({
clientId: '', // Your FusionAuth client ID
serverUrl: '', // The base URL of the server that performs the token exchange
redirectUri: '', // The URI that the user is directed to after the login/register/logout action
shouldAutoRefresh: true // option to configure the SDK to automatically handle token refresh. Defaults to false if not specified here.
}),
],
providers: [],
bootstrap: []
})
export class AppModule { }
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.
class AppComponent implements OnInit, OnDestroy {
private fusionAuthService: FusionAuthService = inject(FusionAuthService);
isLoggedIn: boolean = this.fusionAuthService.isLoggedIn();
userInfo: UserInfo | null = null;
isGettingUserInfo: boolean = false;
subscription?: Subscription;
ngOnInit(): void {
if (this.isLoggedIn) {
this.subscription = this.fusionAuthService
.getUserInfoObservable({
onBegin: () => (this.isGettingUserInfo = true),
onDone: () => (this.isGettingUserInfo = false),
})
.subscribe({
next: (userInfo) => (this.userInfo = userInfo),
error: (error) => console.error(error),
});
}
}
ngOnDestroy(): void {
this.subscription?.unsubscribe();
}
}
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.
import { Component } from '@angular/core';
@Component({
selector: 'app-login',
template: `<fa-login></fa-login>`,
styleUrls: []
})
export class LoginComponent {}
@Component({
selector: 'app-logout',
template: `<fa-logout></fa-logout>`,
styleUrls: []
})
export class LogoutComponent {}
@Component({
selector: 'app-register',
template: `<fa-register></fa-register>`,
styleUrls: []
})
export class RegisterComponent {}
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
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:
- Develop using a local FusionAuth instance, so both your webapp and FusionAuth are running on
localhost
. - Do not use the FusionAuth hosted backend, and instead write your own backend with a cross origin cookie policy: here’s an example.
- Configure a custom domain name for the FusionAuth Cloud instance (limited to certain plans).
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.