Angular comes with a number of baked-in features which are tremendously helpful for handling authentication. I think my favorite is probably its HttpInterceptor interface, but right next to it would be route guards. Let’s take a look at what Angular’s route guards are and how to use them to help with authentication in your Angular apps.
What are Route Guards?
Angular’s route guards are interfaces which can tell the router whether or not it should allow navigation to a requested route. They make this decision by looking for a true or false return value from a class which implements the given guard interface.
There are five different types of guards and each of them is called in a particular sequence. The router’s behavior is modified differently depending on which guard is used. The guards are:
CanActivateCanActivateChildCanDeactivateCanLoadResolve
We won’t get too much into the details of each guard here but you can see the Angular docs for more.
Quick note: I’m writing a book called Securing Angular Applications. It will teach you everything you need to know to about authentication, authorization, and security so you can properly lock down your Angular apps. Check it out if you’re interested :)
Routing Decisions Based on Token Expiration
If you’re using JSON Web Tokens (JWT) to secure your Angular app (and I recommend that you do), one way to make a decision about whether or not a route should be accessed is to check the token’s expiration time. It’s likely that you’re using the JWT to let your users access protected resources on your backend. If this is the case, the token won’t be useful if it is expired, so this is a good indication that the user should be considered “not authenticated”.
Create a method in your authentication service which checks whether or not the user is authenticated. Again, for the purposes of stateless authentication with JWT, that is simply a matter of whether the token is expired. The JwtHelper class from angular2-jwt can be used for this.
npm install --save @auth0/angular-jwt@beta
// src/app/auth/auth.service.tsimport{Injectable}from'@angular/core';import{JwtHelper}from'@auth0/angular-jwt';@Injectable()exportclassAuthService{constructor(publicjwtHelper:JwtHelper){}// ...publicisAuthenticated():boolean{consttoken=localStorage.getItem('token');// Check whether the token is expired and return// true or falsereturn!this.jwtHelper.isTokenExpired(token);}}Note: This example assumes that you are storing the user’s JWT in local storage.
Create a new service which implements the route guard. You can call it whatever you like, but something like auth-guard.service is generally sufficient.
// src/app/auth/auth-guard.service.tsimport{Injectable}from'@angular/core';import{Router,CanActivate}from'@angular/router';import{AuthService}from'./auth.service';@Injectable()exportclassAuthGuardServiceimplementsCanActivate{constructor(publicauth:AuthService,publicrouter:Router){}canActivate():boolean{if(!this.auth.isAuthenticated()){this.router.navigate(['login']);returnfalse;}returntrue;}}The service injects AuthService and Router and has a single method called canActivate. This method is necessary to properly implement the CanActivate interface.
The canActivate method returns a boolean indicating whether or not navigation to a route should be allowed. If the user isn’t authenticated, they are re-routed to some other place, in this case a route called /login.
Now the guard can be applied to any routes you wish to protect.
// src/app/app.routes.tsimport{Routes,CanActivate}from'@angular/router';import{ProfileComponent}from'./profile/profile.component';import{AuthGuardServiceasAuthGuard}from'./auth/auth-guard.service';exportconstROUTES:Routes=[{path:'',component:HomeComponent},{path:'profile',component:ProfileComponent,canActivate:[AuthGuard]},{path:'**',redirectTo:''}];The /profile route has an extra config value now: canActivate. The AuthGuard that was created above is passed to an array for canActivate which means it will be run any time someone tries to access the /profile route. If the user is authenticated, they get to the route. If not, they are redirected to the /login route.
Note: The
canActivateguard still allows the component for a given route to be activated (but not navigated to). If we wanted to prevent activation altogether, we could use thecanLoadguard.
Checking for a User’s Role
The above example works well for scenarios that are fairly straight forward. If a user is authenticated, let them pass. There are many cases, however, where we’ll want to be a bit more fine-grained with our routing decisions.
For example, we may wish to only permit access to a route for users that have a certain role attached to their account. To handle these cases we can modify the guard to look for a certain role in the payload of the user’s JWT.
Install jwt-decode so we can read the JWT payload.
npm install --save jwt-decode
Since there will be times that we want to use both the catch-all AuthGuard and a more fine-grained role-based guard, let’s create a new service so we can handle both cases.
Create a new guard service called RoleGuardService.
// src/app/auth/role-guard.service.tsimport{Injectable}from'@angular/core';import{Router,CanActivate,ActivatedRouteSnapshot}from'@angular/router';import{AuthService}from'./auth.service';importdecodefrom'jwt-decode';@Injectable()exportclassRoleGuardServiceimplementsCanActivate{constructor(publicauth:AuthService,publicrouter:Router){}canActivate(route:ActivatedRouteSnapshot):boolean{// this will be passed from the route config// on the data propertyconstexpectedRole=route.data.expectedRole;consttoken=localStorage.getItem('token');// decode the token to get its payloadconsttokenPayload=decode(token);if(!this.auth.isAuthenticated()||tokenPayload.role!==expectedRole){this.router.navigate(['login']);returnfalse;}returntrue;}}In this guard we’re using ActivatedRouteSnapshot to give us access to the data property for a given route. This data property is useful because we can pass an object with some custom properties to it from our route configuration. We can then pick up that custom data in the guard to help with making routing decisions.
In this case we’re looking for a role that we expect the user to have if they are to be allowed access to the route. Next we are decoding the token to grab its payload. If the user isn’t authenticated or if they don’t have the role we expect them to have in their token payload, we cancel navigation and have them log in. Otherwise, they are free to proceed.
We can now use this RoleGuardService for any of our routes. We might, for example, want to protect an /admin route.
// src/app/app.routes.tsimport{Routes,CanActivate}from'@angular/router';import{ProfileComponent}from'./profile/profile.component';import{AuthGuardServiceasAuthGuard}from'./auth/auth-guard.service';import{RoleGuardServiceasRoleGuard}from'./auth/role-guard.service';exportconstROUTES:Routes=[{path:'',component:HomeComponent},{path:'profile',component:ProfileComponent,canActivate:[AuthGuard]},{path:'admin',component:AdminComponent,canActivate:[RoleGuard],data:{expectedRole:'admin'}},{path:'**',redirectTo:''}];For the /admin route, we’re still using canActivate to control navigation, but this time we’re passing an object on the data property which has that expectedRole key that we’ve already seen in the RoleGuardService.
Note: This scenario assumes that you are using a custom
roleclaim in your JWT.
Isn’t this Easily Hackable?
If you’re like most developers, you’re probably looking at this and thinking that the user could very easily hack their way to a protected route. After all, any knowledgeable user could find their JWT in local storage, head over to jwt.io, plug the token in, and change its payload. For example, they could change the exp in an attempt to extend the token’s lifetime, or they could give themselves a different role.
This is all true–a user could do this and then get past the guards. The key point to remember, however, is that any change the user makes to their token payload will invalidate the signature. JSON Web Token signatures are calculated by including the payload, so any modifications to it will throw the whole thing off. This is good news because it means the user won’t be able to access your protected resources with it.
Any sensitive data that you don’t want unauthorized access to should be kept behind your server. If the user does manage to get to a route they’re not supposed to, it doesn’t matter a whole lot anyway because they won’t be able to see any data that the route normally provides.
But I Want to Lock Routes Down Completely
In some cases, there’s still a strong desire to lock down client-side routes completely. While it’s not possible to have 100% protection of anything on the client side, Angular provides some interesting possibilities through async routing. We’ll have a look at how we can use async routing to our advantage is a future post.
Wrapping Up
Hopefully you’ve been able to see the benefits of using Angular’s route guards to help protect access to client-side routes. Remember that nothing on the client can ever truly be protected. Any code, data, or other assets that are delivered to the user’s browser are accessible by them. Knowing this, be sure to always protect sensitive data on your backend.
If you enjoyed this post, follow me on Twitter and say hi there :)
I’m in the process of writing a book called Securing Angular Applications which covers absolutely everything needed to properly lock down an Angular app. You can check out the early details for the book and sign up to receive sample chapters and content as it becomes available.
