When building angular apps, here’s my general philosophy in a nutshell. I can add more clarification if necessary.

All actual security must be implemented server-side. Any security logic you put in the angular app (and it should be there) is for convenience and usability only, not actual security.

You must gate your REST api calls in nodejs using some kind of authentication and authorization scheme, and you should return a 401 to any client asking for data or trying to save data they don’t have access to.

At the same time, it’s a bad idea to show users functionality that will not work (ie, will return a 401). So if there’s a button that does something a user isn’t allowed to do, you should hide it from them before they have a chance to click on it and receive an error.

To do this, you’ll need to send the client information about the currently authenticated users access-level, and drive visibility of features/behavior off of that. But understand that this is easily circumvented by a sophisticated user (using the F12 Developer Tools, for example). So this is not something that secures your application, per se, but something that makes your application more user-friendly.

You have to decide how important it is to keep the admin functionality secret. Is it a secret that there exists an admin function that your users can’t use? Or do you need to just secure the functionality itself? If you are serving static files, then a clever user can get any of those files from the server. But of what value is that? Those files will not contain any actual data, and clicking the buttons won’t do anything (because you secured your api calls on the server). All our hacker can see is an angular html template. That’s not worth very much. Some sucker spent all that energy trying to figure out the names of the files to download and all s/he sees are a bunch of mustaches and ng-* directives. Whoopdedoo.

But if you want to secure even that, you’ll need to gate access to the static files. There’s no reason you have to serve those to freely. You can implement security on the server and check authorization before returning html and js. It’s a bit more work to do this, so it isn’t worth it unless it’s necessary, but it’s possible.

One final thought: there’s no reason you are limited to a single angular app for your application. You might want to try a setup that looks like this:

• Landing Page (rendered server-side, public)
• About Page (rendered server-side, public)
• Any other server-side pages to market your app
• App (index.html, the entry point to your main angular app)
• Admin App (index.html, the entry point to your admin angular app)

Here you have two SPAs being served from the same webserver. This structure separates your admin functionality cleanly. From a security standpoint, you still have all the same considerations, but this might make it easier to implement your security rules.