Authentication in Angular, why it is so hard to wrap your head around it

anchorAuthentication ingredients

A full cycle of authentication and authorization in an SPA may go through the following factors:

• User login: getting an access token, and possibly a refresh token.
• Storing on client: in local storage along with minimal details
• Login resolver: to direct away from the login page if the user is already authenticated
• Router auth guard: to direct to login page if user is not authenticated
• Logout: remove storage

Use cases:

• Http interceptor: to use the token for API calls
• 401 handling: to request a new token
• User display: getting extra details to display on the screen
• Redirect URL: an extra piece of information to track

Other concerns:

• Third-party: how much do we need to change to adapt
• Server-side rendering: getting the access token by other means

We should always remind ourselves as we build authentication that:

• Not all routes go through an auth guard
• Some components display user status anyway
• There is a sequence of events taking place in an Angular app

anchorThe simplest login

Let us begin with the simplest format of authentication, a form with user name and password, that returns a profile with an access token, and possibly a refresh token. Over the years, I have come to terms with a few things and tend to never argue about them:

• Yes sign the token on the server and return both access token and refresh token to the client
• Yes, save them both in LocalStorage
• Yes, extract and save everything you need on the client
• No, you don’t have to have a server for the front end

The API is a simple POST that accepts username and password and returns a dummy access token and a refresh token. First, let’s get one thing out of the way. A login button.

We are creating a route from application root, /public/login

// components login.component.ts
login() {
	// we are going to mimic a click of a login button
	someAuthService.login(username, password).subscribe()
}

Let’s create the AuthService to handle the login.

anchorAuth Service

The AuthService has everything that needs to be done on the server. We will send a request to our API, and in future episodes touch on third-party auth servers. The bare minimum is a service that logs user in and returns a typed object of, let’s call it, IAuthInfo.

// Auth service
@Injectable({ providedIn: 'root' })
export class AuthService {
  private _loginUrl = '/auth/login';
  constructor(private _http: HttpClient) {}
  // login method
  Login(username: string, password: string): Observable<any> {
    return this._http.post(this._loginUrl, { username, password }).pipe(
      map((response) => {
        // prepare the response to be handled, then return
        return response;
      })
    );
  }
}

Assume the body of the response to be as follows. Notice that detailed user information is usually not the responsibility of an authentication server, so the payload is slim.

{ accessToken: 'some_acces_token',
	refreshToken: 'some_refresh_token',
	payload: {
		"id": "841fca92-eba8-48c8-8c96-92616554c590",
		"email": "aa@gmail.com"
	},
	expiresIn: 3600}

Let us build proper models to set authentication information apart from user information (the payload).

// user model
export interface IUser {
  email: string;
  id: string;
}
// auth model
export interface IAuthInfo {
  payload?: IUser;
  accessToken?: string;
  refreshToken?: string;
  expiresAt?: number
}

Back in our service, when login is successful we need to save information in the localStorage.

Login(username: string, password: string): Observable<any> {
  return this._http.post(this._loginUrl, { username, password }).pipe(
    map((response) => {
      // prepare the response to be handled, then return
      // we'll tidy up later
      const retUser: IAuthInfo = <IAuthInfo>(<any>response).data;
      // save in localStorage
      localStorage.setItem('user', JSON.stringify(retUser));
      return retUser;
    })
  );
}

Direct cast to IAuthInfo and using localStorage without a wrapper is not ideal, but we have more important issues to cover.

When the user visits the site again, I need to populate user information from localStorage. If not found, there are two scenarios

• if private route: return to a safe route
• if public route: allow user in, but flag user as not logged in

With many hidden caveats and twists and turns, it is easier said than done.

anchorThe bottom line

Here is a diagram of different elements of a random app.

Reading the user state from localStorage needs to happen as early as possible, because the rest of the app depends on it.

Let me demonstrate.

Let’s create a couple of routes, and a partial component to display user info in the root application component. I choose the root because it is the most extreme location to display anything. Under private/dashbaord we’ll have a component, that login redirects to.

// login component
login() {
  this.authService.Login('username', 'password').subscribe({
    next: (result) => {
      // redirect to dashbaord
      this.router.navigateByUrl('/private/dashboard');
    },
   // ...
  });
}

Our app module now looks like this

// app module
const AppRoutes: Routes = [
	// ...
	// add private path for dashboard
  {
    path: 'private',
    loadChildren: () =>
      import('./routes/dashboard.route').then((m) => m.AccountRoutingModule),
  },
  // and throw in another public route
  {
    path: 'projects',
    loadChildren: () =>
      import('./routes/project.route').then((m) => m.ProjectRoutingModule),
  },
];

@NgModule({
  imports: [...,
    // import standalone component to be used in root
    AccountStatusPartialComponent
  ],
  // ...
})
export class AppModule {}

The status component in its simplest format should read localStorage and decide what to do with it.

// components/private/status.partial
@Component({
  selector: 'cr-account-status',
  template: `
  <div class="box">Email: {{ s.email }}</div>
  `,
  //...
})
export class AccountStatusPartialComponent implements OnInit {
  s: any;
  ngOnInit(): void {
    // the simplest case, get localstroage and parse it, then read payload
    this.s = JSON.parse(localStorage.getItem('user') || '').payload;
  }
}

In our application component, we add our partial component.

// app.component.html
<header>
 // ...
<cr-account-status></cr-account-status>
</header>

After clicking on login, and redirecting to dashboard, this component should reflect the new value. It doesn’t. Normally. We need a way to listen and update. State management is in the house.

anchorAuth State

The first issue we are facing is the responsiveness of the status component right after login. To fix that we are going to use RxJS state management: a behavior subject, and an observable. (This is the most repetitive pattern of auth state in Angular). Let’s adjust the AuthService to carry the state item.

// update services/auth.service
export class AuthService {
  
  // create an internal subject and an observable to keep track
  private stateItem: BehaviorSubject<IAuthInfo | null> = new BehaviorSubject(null);
  stateItem$: Observable<IAuthInfo | null> = this.stateItem.asObservable();

  constructor(private _http: HttpClient) {}

  // login method
  Login(username: string, password: string): Observable<any> {
    return this._http.post(this._loginUrl, { username, password }).pipe(
      map((response) => {
        // ...

        // also update state
        this.stateItem.next(retUser);
        return retUser;
      })
    );
  }
}

Our status partial component is fed in two ways:

• From AuthService stateitem$ observable: after user login
• From localStorage: after page hard refresh

Our status partial should only read the observable.

// components/account/status.partial
// this is not the place to intialize state, only read state
export class AccountStatusPartialComponent implements OnInit {
	status$: Observable<IUser>;
	constructor(private authService: AuthService) {
	    
	}
	ngOnInit(): void {
		// read only the payload for this component
		this.status$ = this.authService.stateItem$.pipe(map(state => state?.payload));
	}
}

We need to think of another place to initialize state from localStorage. This place must be on the root of all evil, I mean, application. We need to make sure the state is initialized immediately before any other checks. And what better place to do that than APP_INITIALIZER token provider?

anchorAuth State in APP_INITIALIZER

In our app module, we provide a service for this token:

// app.module

@NgModule({
 // ...
// add a provider to array of providers
  providers: [
		{
	    provide: APP_INITIALIZER,
	    useFactory: authFactory,
	    multi: true,
	    deps: [AuthService],
	  }
	],
})
export class AppModule {}

And for now, let’s dump everything in the AuthService (this soon shall move to its own state service)

const CheckAuth = (auth: IAuthInfo): boolean => {
  // check if accesstoken exists and that it has not expired yet
	// ...
  // return if profile is valid
  return true;
};

export const authFactory = (authService: AuthService) => () => {
  // initialize auth state

  // check item validity
  const _localuser: IAuthInfo = JSON.parse(localStorage.getItem('user'));
  if (CheckAuth(_localuser)) {
    authService.SetState(_localuser);
  } else {
    // remove leftover
    authService.RemoveState();
    // and clean localstroage
    localStorage.removeItem('user');
  }
};

export class AuthService {
  // ... add two more methods that shall move soon to auth state service
  SetState(item: IAuthInfo) {
    this.stateItem.next(item);
  }
  RemoveState() {
    this.stateItem.next(null);
  }
}

For the sole purpose of demonstrating that we got the sequence right, this should be enough. Now testing in our app, with no login, then login, then refresh. It works. The authentication state is always up to date.

anchorAwait remote configuration

There could be another initializer in line, let’s imagine the key of the localStorage is stored in a remote configuration file, which we load via an Http request (read about loading external configurations via http using APP_INITIALIZER). Not only is the sequence of initializers important, but the async nature of the Http request adds a slight complexity, let’s fix it. We should wait for the configuration to be ready before we attempt to use it.

// auth factory change
// add second attribute for config service which has the config$ observable
export const authFactory = (authService: AuthService, configService: ConfigService) => () => {
  // wait for config to be ready
   configService.config$.pipe(
      filter(config => config.isServed)
   ).subscribe({
      next: config => {
         // do the rest using config key
         const _localuser: IAuthInfo = JSON.parse(
            localStorage.getItem(config.Auth.userAccessKey)
         );
         if (CheckAuth(_localuser)) {
            authService.SetState(_localuser);
         } else {
            // remove leftover
            authService.RemoveState();
            // and clean localstroage
            localStorage.removeItem(config.Auth.userAccessKey);
         }
      }
   }
   );
}

In our provider, we add ConfigService to the deps array. We also can make this initializer above the configuration initializer, since it has to wait for it anyway.

We can enhance this a little: move everything into the AuthService (or future AuthState service), and clean up our code. The token in app module would look this dumb:

// app.module, providers
{
  provide: APP_INITIALIZER,
  // dummy factory
  useFactory: () => () => {},
  multi: true,
  // injected depdencies, this will be constructed immidiately
  deps: [AuthService]
},

Now we can move the logic to AuthService (or our future AuthState)

// auth.service constructor can have everything we need
constructor(private configService: ConfigService) {
  this.configService.config$.pipe(
     filter(config => config.isServed)
  ).subscribe({
     next: config => {
        // ...
    }
  );
}

anchorLogin Resolve

A login resolve is to redirect user away from the login page, if user is already logged in.

// services/login.resolve
@Injectable({ providedIn: 'root' })
export class LoginResolve implements Resolve<boolean> {
 // bring in Auth future State service
 constructor(private authState: AuthService, private router: Router) { }
 resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> {
    // listen to state changes
    return this.authState.stateItem$.pipe(
      // if item exists redirect to default
      // later we will enhance this with a redirect url
       map(user => {
          if (user) {
             this.router.navigateByUrl('/private/dashboard');
          }
          // does not really matter, I either go in or navigate away
          return true;
       })
    );
 }
}

// in public route:
{
  path: 'public/login',
  component: PublicLoginComponent,
  resolve: {
    ready: LoginResolve,
  },
},

There is no magic there, since the AuthService used is ready at this point.

anchorAuth Guard

This is to guard private routes and redirect back to login if user is not logged in.

// services/auth.guard
@Injectable({ providedIn: 'root' })
export class AuthGuard implements CanActivate, CanActivateChild {
	// bring in our Auth future State
	constructor(private authState: AuthService, private _router: Router) {}
	
	canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> {
	  return this.secure(route);
	}
	
	canActivateChild(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> {
	  return this.secure(route);
	}
	
	private secure(route: ActivatedRouteSnapshot | Route): Observable<boolean> {
		// listen to auth state
	  return this.authState.stateItem$.pipe(
	     map(user => {
	        // if user exists let them in, else redirect to login
	        if (!user) {
	           this._router.navigateByUrl('/login');
	           return false;
	        }
	        // user exists
	        return true;
	     })
	  );
	}
}

Before we go on, let me inspect another choice that would have been tempting, just to demonstrate how terrible it is.

Inject in root component

There is a slight difference for this one, it really is late enough the configuration is definitely be loaded by then. But the login resolve and auth guard are usually faster than root component, so this might be a bit too late. Let’s inspect.

// app.component
	export class AppComponent {
	constructor(
	    private authService: AuthService
	) {
	
	  // initiate state of auth
	  const _localuser: IAuthInfo = JSON.parse(
	     localStorage.getItem('key here from config')
	  );
	  if (this.authService.CheckAuth(_localuser)) {
	     this.authService.SetState(_localuser);
	  } else {
	     this.authService.RemoveState();
	     localStorage.removeItem('key here from config');
	  }
	}
}

The configuration is guaranteed to be loaded at this point. We can also place this logic in the AuthService constructor, but we still need to inject it in the app root component. I don’t know about you, but I don’t like injecting something I am not going to use!

Now running with LoginResolve, and AuthGuard, I can immediately spot the problem. They are too early. Refreshing the URL /login will not redirect to dashboard even if the user is found. To fix that, the logic must be in the AuthService constructor, which is — messy.

anchorLogout

Logout is as simple as removing state, and localStorage. The Logout feature itself can be placed anywhere it is needed, but the true user-triggered logout, needs an extra redirect to close the cycle. We already have the logic in AuthService we just need to move it to its own method.

// services/auth.service
// add another method, and use it when needed
Logout() {
  // remove leftover
  this.RemoveState();
  // and clean localstroage, you can use static configuration at this point
  localStorage.removeItem(ConfigService.Config.Auth.userAccessKey);
}

In our root component I will add a link that calls a logout function, which uses the AuthService Logout, and then reroutes:

// app.component
export class AppComponent {
  constructor(private authService: AuthService, private router: Router) {}
  Logout() {
    this.authService.Logout();
    // also reroute to login
    this.router.navigateByUrl('/public/login');
  }
}
// in HTML templte: (click)="Logout()"

anchorUse cases

Let us add the access token to our API Http calls, and deal with a 401. That and a few other use cases will have to wait till next week. 😴

Thank you for reading this far, did you check your injections?