Hacker News Reader

Comment by agnokapathetic | Hacker News Reader

While this works fine for most single-role customer facing applications (the kind most startups are building), as a security engineer most Single Page Apps (SPAs) which handle authentication like this (client side) have horrible authorization issues.

I've seen many SPAs with totally unauthenticated API endpoints. They'll control what a user's allowed to do with the UI and hide unauthorized functionality, but direct requests to the backend still allow any request.

The thing to keep in mind is: don't trust the client. The final word on authentication and authorization should always be done server-side.

View on HN

I believe your concern is a valid one, end-points of single page apps should respect authorization requirements, and assume the client is always compromised.

Unfortunately, I believe you may have missed the point of this library and blog post. It merely simplifies the developers life when implementing the client side flows and interactions associated with authorization with one or more auth providers.

This does not preclude proper API authorization or loading sensitive modules post authorization from an authorized end-point.

As someone who has implement many very related flows, I am glad to see an effort to unify, share and simplify this experience.

To further your port Agno, you regularly have all of the javascript modules in the browser, even if the user doesn't have the right authentication role to use those modules.

I'm currently trying to find a way to only download the modules only if the user has the proper authentication and then load them into the already bootstrapped angular, but it isn't easy.

This sounds like security through obscurity, made worse by the fact that it is probably difficult to guarantee that users who are shown the 'privileged' modules are somehow to be trusted.

Does it really matter if the user gains access to a part of the app that they don't have authorization for? It's up to the API to enforce what the users are or aren't allowed to see, otherwise they can just by-pass the browser all together and make requests to the API willy-nilly.

It exposes your application structure.

I guess this only matters for specific types of apps (e.g. unlock functionality when a user pays) where most of the action happens client-side? Still seems like security-through-obscurity because eventually the user ends up with the client-side code.

What's the threat model here? That a potential attacker knows more about your application? Then what?

I don't think it's necessary to hide that functionality, unless there are some strings in the post-auth modules that unauthenticated clients should really never be able to see. Security by obscurity is pointless.

You shouldn't be concerned about someone having all of your client-side source code; the worst they could do with it is clone your site and make a bad, hacky reverse engineered attempt at emulating your backend API.

If you think hiding your application structure or references to API endpoints secures you, then you're doing something very wrong.

I believe that you have a misunderstanding regarding 'what is happening here'.

This isn't 'client side authorisation' in the sense you are talking of.

Specifically it still relies on a /session route which only accepts valid authorization objects which can be though of as keys in a more 'traditional' 'server side authentication' approach.

Auth is always a challenge. Simplifying the design of an application's auth solution is a great way to make clear the risks and tradeoffs it presents.

I find that Persona simplifies auth a lot.

https://www.mozilla.org/en-US/persona/

Reply on news.ycombinator.com