Most, if not all, apps have a requirement to authenticate/authorize user access. We may argue that authentication and authorization are more of a server concern than a client concern, and that is correct. Still, the client side needs to adapt and integrate with the authentication and authorization requirement imposed by the server.

Any typical Angular application first loads partial views and then makes calls to pull data from the server and binds them to the views. Clearly, the views and the remote data API are the two assets that need to be secured.

To guard these resources, you need to understand how a typical application is secured on the server. There are primarily two broad approaches for securing any web applications: cookie-based authentication and token-based authentication. Each of them requires different handling on the client part. The next two sections describe how we can integrate with either of these approaches.

Cookie-based authentication

This authentication mechanism is the easiest to implement if the server stack supports it. It’s non-intrusive and may require the bare minimum of changes to the Angular application. Cookie-based authentication involves setting the browser cookie to track the user authentication session. The following sequence diagram explains a typical cookie-based authentication workflow:

Cookie-based authentication
Here is how a typical authentication workflow works:

  • When trying to access a secured resource from the browser, the server sends a HTTP 401 Unauthorized status code if the user is not authenticated,. As we see later, a user request is an unauthorized request if there is no cookie attached to the request or the cookie is expired/invalid.
  • This unauthorized response is intercepted by the server or, at times, by the client framework (Angular, in our case) and it typically results in a 302 redirect (if intercepted by the server). The redirect location is the URL to the login page (the login page allows anonymous access).
  • The user then enters the username and password on the login page and does a POST to the login endpoint.
  • The server validates the credentials, sets a browser cookie, and redirects the user to the original requested resource.
  • Henceforth, the authentication cookie is a part of every request (added by the browser automatically) and the server uses this cookie to confirm its identity and whether the user is authenticated.


This scenario assumes that the HTML and API exist under a single domain.

As we can see, with this approach the Angular infrastructure is not involved or the involvement is minimal. Even the login page can be a standard HTML page that just sends data to the login endpoint for authentication. If the user lands on the Angular app, it implicitly means that the user has already been authenticated.


The cookie-based authentication flow may vary depending on the server framework, but the general pattern of setting a cookie and attaching a cookie with every subsequent request, remains the same.

In a cookie-based application authentication, if the application wants to get the user context, a server endpoint (such as /user/details) is exposed that returns the logged in user-specific data. The client application can then implement a service such as UserService that loads and caches the user profile data.

The scenario described here assumes that the API server (the server that returns data) and the site where the application is hosted are in a single domain. That may not be the case always. Even for Personal Trainer, the data resides on the MongoLab servers and the application resides on a different server (even if it is local). And we already know that this is a cross-domain access and it comes with its own set of challenges.

In such a setup, even if the API server is able to authenticate the request and send a cookie back to the client, the client application still does not send the authentication cookie on a subsequent request.

To fix this, we need to set a Boolean variable with credentials to true on the $http configuration object:

$http.get('api/users',{ withCredentials : true});

And the client will start attaching the authentication cookie for the cross-domain requests.

The server too needs to have cross-origin resource sharing (CORS) enabled and needs to respond in a specific manner for the request to succeed. It should set the access-control-allow-credentials header to true and the access-control-allow-origin header to the host site making the request.


Check the MDN documentation ( to learn more about this scenario in detail.

Cookie-based authentication is definitely less work on the client side, but there are times when you have to revert to token-based access. This could be because:

  • Cookies and cross-domain requests do not play nicely across browsers. Specifically, IE8 and IE9 do not support it.
  • The server may not support generating cookies or the server only exposes token-based authentication.
  • Token-based solutions are easy to integrate with native mobile applications and desktop clients.
  • Tokens are not susceptible to cross-site request forgery (CSRF) attacks.