Make your Angular app a max security prison by Matias Woloski & Martin Gontovnikas at ng-europe 2014

By: ng-europe

259   9   35531

Uploaded on 10/31/2014

Matias and Martin explain how to secure your angular SPA app using JWT auth and more.


Comments (2):

By anonymous    2017-09-20

OK, there is a lot to answer. But the short answer is to just keep things simple and authenticate like you would a regular web app.

In a regular web app :

  • In a regular web app you would send a request to a server and check the credentials with a database to authenticate the user

In a mobile app :

  • In a mobile app you will do the same via ajax requests (using $http in the case of angular).
  • After authentication is complete on the server send a response back to the app( eg. json/xml) indicating to the front end the result of the authentication.

What is the standard approach ?

  • I'm not sure about standard, but this seems to be the easiest approach. Standards always change because there's always a better way to do it. So as long as it gets the job done go for it, improve on it later.

Should i be using Node.JS as a proxy to the databse?

  • I haven't used much of nodeJs so i don't know what you really mean. But if it helps to know - i use php on the server that receives the ajax request, handles the authentication with the mysql database and returns the response to the mobile app.

Am I going about this all the wrong way?

  • I haven't seen your initial setup. As far as authenticating whenever you're changing states in the app goes, you can use localStorage to store the user info after a successful login. On logout clear the localStorage. So all you need to do is to check if the value exists in the localStorage to confirm if the user is logged in.

What are my potential road-blocks?

  • I suggest you start making your app and you'll know soon enough. On the whole ionic+cordova makes things quite simple and removes most of the roadblocks for app development.

How does CORS work with hybrid applications?

  • Cordova allows cross domain request by default so you won't have any problems with cross domain requests and thus you can access your server for authentication directly.

Anything I'm missing?

  • IonicFramework is just a front end HTML5 framework. It alone cannot make you a mobile app.It will just give you nice UI to work with. IonicFramework provides you with some nice javascript features which it implements using angular. Thus, to get the most out of ionic you should be proficient with angularJs. Learning angular is well worth the effort so go for it.

  • The actual app is compiled by Cordova. Cordova takes your regular html/css/javascript files and packages them into the android apk or iphone ipa so that they can be installed on the respective os as native apps.

  • Cordova is what will allow you to access native phone features like the camera,gallery,contacts etc.

Updated 3rd June 2015

Token Based Authentication : i believe is an alternative. It is a cleaner and more secure way of handling authentication that is now easily available.

For more information check out the following links:

What are the benefits of using a token-based approach?

Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX calls to any server, on any domain because you use an HTTP header to transmit the user information. Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contanined entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.

CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API. Decoupling: you are not tied to a particular authentication scheme. The token might be generated anywhere, hence your API can be called from anywhere with a single way of authenticating those calls.

Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a secure API (you have to deal with cookie containers). Adopting a token-based approach simplifies this a lot. CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to your site, generate a POST request and re-use the existing authentication cookie because there will be none).

Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database) is likely to take more time than calculating an HMACSHA256 to validate a token and parsing its contents.

Login page is not an special case: If you are using Protractor to write your functional tests, you don't need to handle any special case for login. Standard-based: your API could accepts a standard JSON Web Token (JWT). This is a standard and there are multiple backend libraries (.NET, Ruby, Java, Python, PHP) and companies backing their infrastructure (e.g. Firebase, Google, Microsoft). As an example, Firebase allows their customers to use any authentication mechanism, as long as you generate a JWT with certain pre-defined properties, and signed with the shared secret to call their API.

Original Thread

Submit Your Video

If you have some great dev videos to share, please fill out this form.