AngularJS Authentication + RESTful API

Question

Angular+RESTful Client-side Communication w/ API for Auth/(re)Routing

This has been covered in a few different questions, and in a few different tutorials, but all of the previous resources I've encountered don't quite hit the nail on the head.

In a nut-shell, I need to

• Login via POST from http://client.foo to http://api.foo/login
• Have a "logged in" GUI/component state for the user that provides a logout route
• Be able to "update" the UI when the user logs out / logs out. This has been the most frustrating
• Secure my routes to check for authenticated-state (should they need it) and redirect the user to the login page accordingly

My issues are

• Every time I navigate to a different page, I need to make the call to api.foo/status to determine whether or not user is logged in. (ATM I'm using Express for routes) This causes a hiccup as Angular determines things like ng-show="user.is_authenticated"
• When I successfully login/logout, I need to refresh the page (I don't want to have to do this) in order to populate things like {{user.first_name}}, or in the case of logging out, empty that value out.

// Sample response from `/status` if successful   {    customer: {...},    is_authenticated: true,    authentication_timeout: 1376959033,    ... } 

What I've tried

• http://witoldsz.github.io/angular-http-auth/¹
• http://www.frederiknakstad.com/authentication-in-single-page-applications-with-angular-js/²
• https://github.com/mgonto/restangular (For the life of me I could not figure out how to POST with post data and not query params. The docs turned up nothing on the matter.

Why I feel like I'm losing my mind

• It seems as though every tutorial relies on some database (lots of Mongo, Couch, PHP+MySQL, ad infinitum) solution, and none rely purely on communication with a RESTful API to persist logged-in states. Once logged in, additional POSTs/GETs are sent with withCredentials:true, so that's not the issue
• I cannot find ANY examples/tutorials/repos that do Angular+REST+Auth, sans a backend language.

I'm not too proud

Admittedly, I'm new to Angular, and would not be surprised if I'm approaching this in a ridiculous way; I'd be thrilled if someone suggest an alternative—even if it's soup-to-nuts.

I'm using Express mostly because I really love Jade and Stylus— I'm not married to the Express' routing and will give it up if what I want to do is only possible with Angular's routing.

Thanks in advance for any help anyone can provide. And please don't ask me to Google it, because I have about 26 pages of purple links. ;-)

---

¹This solution relies on Angular's $httpBackend mock, and it's unclear how to make it talk to a real server.

²This was the closest, but since I have an existing API I need to authenticate with, I could not use passport's 'localStrategy', and it seemed insane to write an OAUTH service...that only I intended to use.

Answer 1

This is taken from my blog post on url route authorisation and element security here but I will briefly summaries the main points :-)

Security in frontend web application is merely a starting measure to stop Joe Public, however any user with some web knowledge can circumvent it so you should always have security server-side as well.

The main concern around security stuff in angular is route security, luckily when defining a route in angular you are create an object, an object that can have other properties. The cornerstone to my approach is to add a security object to this route object which basically defines the roles the user must be in to be able to access a particular route.

 // route which requires the user to be logged in and have the 'Admin' or 'UserManager' permission     $routeProvider.when('/admin/users', {         controller: 'userListCtrl',         templateUrl: 'js/modules/admin/html/users.tmpl.html',         access: {             requiresLogin: true,             requiredPermissions: ['Admin', 'UserManager'],             permissionType: 'AtLeastOne'         }); 

The whole approach focuses around an authorisation service which basically does the check to see if the user has the required permissions. This service abstract the concerns away from the other parts of this solution to do with the user and their actual permission that would have been retrieved from the server during login. While the code is quite verbose it is fully explained in my blog post. However, it basically handle the permission check and two modes of authorisation. The first is that the user must have at least on of the defined permissions, the second is the user must have all of the defined permissions.

angular.module(jcs.modules.auth.name).factory(jcs.modules.auth.services.authorization, [   'authentication',   function (authentication) {    var authorize = function (loginRequired, requiredPermissions, permissionCheckType) {     var result = jcs.modules.auth.enums.authorised.authorised,         user = authentication.getCurrentLoginUser(),         loweredPermissions = [],         hasPermission = true,         permission, i;      permissionCheckType = permissionCheckType || jcs.modules.auth.enums.permissionCheckType.atLeastOne;     if (loginRequired === true && user === undefined) {         result = jcs.modules.auth.enums.authorised.loginRequired;     } else if ((loginRequired === true && user !== undefined) &&         (requiredPermissions === undefined || requiredPermissions.length === 0)) {         // Login is required but no specific permissions are specified.         result = jcs.modules.auth.enums.authorised.authorised;     } else if (requiredPermissions) {         loweredPermissions = [];         angular.forEach(user.permissions, function (permission) {             loweredPermissions.push(permission.toLowerCase());         });          for (i = 0; i < requiredPermissions.length; i += 1) {             permission = requiredPermissions[i].toLowerCase();              if (permissionCheckType === jcs.modules.auth.enums.permissionCheckType.combinationRequired) {                 hasPermission = hasPermission && loweredPermissions.indexOf(permission) > -1;                 // if all the permissions are required and hasPermission is false there is no point carrying on                 if (hasPermission === false) {                     break;                 }             } else if (permissionCheckType === jcs.modules.auth.enums.permissionCheckType.atLeastOne) {                 hasPermission = loweredPermissions.indexOf(permission) > -1;                 // if we only need one of the permissions and we have it there is no point carrying on                 if (hasPermission) {                     break;                 }             }         }          result = hasPermission ?                  jcs.modules.auth.enums.authorised.authorised :                  jcs.modules.auth.enums.authorised.notAuthorised;     }      return result; }; 

Now that a route has security you need a way of determining if a user can access the route when a route change has been started. To do this we be intercepting the route change request, examining the route object (with our new access object on it) and if the user cannot access the view we replace the route with another one.

angular.module(jcs.modules.auth.name).run([       '$rootScope',     '$location',     jcs.modules.auth.services.authorization,     function ($rootScope, $location, authorization) {         $rootScope.$on('$routeChangeStart', function (event, next) {             var authorised;             if (next.access !== undefined) {                 authorised = authorization.authorize(next.access.loginRequired,                                                      next.access.permissions,                                                      next.access.permissionCheckType);                 if (authorised === jcs.modules.auth.enums.authorised.loginRequired) {                     $location.path(jcs.modules.auth.routes.login);                 } else if (authorised === jcs.modules.auth.enums.authorised.notAuthorised) {                     $location.path(jcs.modules.auth.routes.notAuthorised).replace();                 }             }         });     }]); 

The key here really is the '.replace()' as this replace the current route (the one they have not got rights to see) with the route we are redirecting them to. This stop any then navigating back to the unauthorised route.

Now we can intercept routes we can do quite a few cool things including redirecting after a login if a user landed on a route that they needed to be logged in for.

The second part of the solution is being able to hide/show UI element to the user depending on there rights. This is achieve via a simple directive.

angular.module(jcs.modules.auth.name).directive('access', [           jcs.modules.auth.services.authorization,         function (authorization) {             return {               restrict: 'A',               link: function (scope, element, attrs) {                   var makeVisible = function () {                           element.removeClass('hidden');                       },                       makeHidden = function () {                           element.addClass('hidden');                       },                       determineVisibility = function (resetFirst) {                           var result;                           if (resetFirst) {                               makeVisible();                           }                            result = authorization.authorize(true, roles, attrs.accessPermissionType);                           if (result === jcs.modules.auth.enums.authorised.authorised) {                               makeVisible();                           } else {                               makeHidden();                           }                       },                       roles = attrs.access.split(',');                     if (roles.length > 0) {                       determineVisibility(true);                   }               }             };         }]); 

You would then sure an element like so:

 <button type="button" access="CanEditUser, Admin" access-permission-type="AtLeastOne">Save User</button> 

Read my full blog post for a much more detailed overview to the approach.