Authentication is an essential part of most web applications. These days, the most common way single-page applications know whether the user is currently logged in is by saving his JWT (JSON Web Token) in the browser’s local storage. It’s worth mentioning that there are claims that using local storage is not secure enough; For more information on this subject we recommend you read this article.

In this article we’ll learn how to set up authentication with Akita with all the necessary functionality that entails. It assumes some basic knowledge of the Akita state management pattern.

Building the Session Store

First, we’re going to start by creating a store for the session. Since we don’t need to maintain a collection of entities, we’ll use the regular Akita store rather than the more commonly used entity store:

The login function updates the session in the store as well as saves it in storage (which is denoted here by the storage object — we won’t get into the implementation of the storage functionality, and leave it to you to select the method). The logout does the opposite — clears the session data from the store and the storage.

Building the Session Query

Our component will query the store to get the logged in status via the query class:

The query is how we communicate with the store and get an updated status on the user’s login state. It can be done either through an observable monitoring the store’s status, or a regular function.

Building the Session Data Service

Interaction with the backend is done via a data service:

Here we’ve placed an observable simulating a successful login response from the server.

Building the Session Service

Our components will manage the store contents through the service, which calls the data service and populates the store with its response.

Building the Login Component

Now we can use everything we’ve created in a login component:

The component passes the form value as credentials to the service, which in turn passes them to the data service to attempt to get the session data. In this example a successful process redirects the user to the home page.

Building the Session Directive

We might need to toggle the visibility of certain elements based on the user login status. In order to keep our code DRY, we’ll create a structural directive with this functionality.

It’s placed in an ng-template tag, and monitors the user’s login status via the query’s observable. It’s value, along with the value passed to the directive in the tag, determines whether the directive creates the template or clears the container. This allows the template to appear only to logged in users, or only to logged out users.

Building the Navigation Component

Here’s an example of a navigation component which uses the directive to offer different navigation options to users, based on their login status:

Building the Session Guard

We may want to prevent the user from navigating to certain routes when he isn’t logged in. In order to achieve this functionally in Angular we can create a Route Guard:

The guard uses the query’s function to determine whether to allow user navigation; Logged out users are redirected to the login page.