angular spa, core and authentication – Part 1, The Idea

An increasingly common Single Page Application (SPA) client with server API backend solution is angular 2/4 with core API.  I especially like the approach by Michal Dymel where he creates 2 projects, core server and angular client.  Each project has its own tool set: I use Visual Studio Community Edition for the core server, and use angular command line interface (CLI) and Visual Studio Code for the client.  The angular cli allows for quick scaffolding of client projects, as well as components, directives, services, classes, routing…   When the angular-cli is built (ng build), the files are copied to a destination set in the configuration, and in this case to core wwwroot folder.   Works great.

However, authentication and authorization continue to be road blocks for me.  I have a server and can write code, manage databases and do not want to offload to a Saas solution.  Maybe I’ll implement an Identity Server solution at some point, but for now I want quick, light-weight set-ups, that do not get in the way of the core applications I want to write.

When I used MVC, the authentication solution was available out of the box – simple and easy.   Tokens (JWT) are now the rage for spa client-server, but with this I need to write all my own authentication/login in my client for each client app, and then get the JWT token, client claims to my api calls…

I have looked at microsoft javascript services, Single Page Application (SPA) templates. The team that creates this is lead by Steve Sanderson of KnockoutJs fame.   They combine core with a SPA using your choice of  various frontend frameworks (angular, react…)  I like the idea, but I like Dymel’s 2 project solution  better since the angular-cli tool chain is kept intact, and you can use the most up to date version of the client frameworks.   With Dymel’s 2 project solution, the client build output still ends up in the wwroot folder.

One possible modification to the 2 project solution could be running the client application inside of a MVC view (this is how the MS javascriptservices template is organized).  This would allow me to use MVC for the login/authentication, anti-forgery tokens, and create a backend MVC admin portal, while the remainder of the application is all angular client and core api.  These calls could all rely on the login, as could the authorization which could be role based instead of claims based.  There may still be a CSRF attack risk, and I might still need to work tokens into the mix.

We’ll see how this works.  I plan to blog my experience implementing this in my next post.

This entry was posted in Uncategorized. Bookmark the permalink.

One Response to angular spa, core and authentication – Part 1, The Idea

  1. Pingback: angular spa, core and authentication – Part 2, Authenticating with MVC | Dr Bits

Comments are closed.