6 ms·

Authentication for Single Page Apps

105 points by mixonic 12y ago

agnokapathetic 12y ago
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.
- mixonic 12y ago
  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.
  - scrollaway 12y ago
    I find that Persona simplifies auth a lot. https://www.mozilla.org/en-US/persona/ https://www.mozilla.org/en-US/persona/
- pedalpete 12y ago
  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.
  - avoid3d 12y ago
    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.
  - pyre 12y ago
    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.
    - crudbug 12y ago
      It exposes your application structure.
      - pyre 12y ago
        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.
      - bmm6o 12y ago
        What's the threat model here? That a potential attacker knows more about your application? Then what?
  - meowface 12y ago
    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.
- avoid3d 12y ago
  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.
- iamstef 12y ago
  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.
EGreg 12y ago
Why is this a big deal? Obviously OAuth can be done with a popup. What we really need is instant and anonymous personalization when a user enters the app.
- EGreg 12y ago
  I wonder why it's being downvoted
qhoc 12y ago
Firebase has very good implementation on Simple Login for authentication. Check out AngularFire project. But I have to agree with some of the comments, backend authentication should be recommended. I can't get away from being nervous about password as text or session hijacking, etc.. with frontend authentication.
forgotAgain 12y ago
I prefer having the authentication in a separate page. Single page apps ( +1 for auth) have a lot of complexity. I find that breaking out the onetime use authentication code and markup makes the main application page somewhat less complex.
- lukenyc 12y ago
  If you can get away with that, it's certainly a way to reduce complexity. However, providing in-flow auth without a page reload is undoubtedly a nicer, faster experience. This library seems like a good way to lower the effort for Ember app developers.
guidedlight 12y ago
From a coding perspective. I find that using 'Annotations' for security works really well in SPA and is extremely simple. It means that every RPC from the client has authorised checks. I also assume that every unauthenticated request is forbidden, unless I have explicitly annotated the RPC method with anonymous access.
pyre 12y ago
I've had good results with: http://ember-simple-auth.simplabs.com/ http://ember-simple-auth.simplabs.com/ in Ember, though most of what it's good at is managing the session on the client-side.
- mixonic 12y ago
  We discussed dropping Torii's simple session manager in favor of recommending Simple Auth, but after discussing it with @marcoow decided we had slightly different goals. Torii's session manager imposes structure and terminology on your code, but had no specific conventions around how to pass request authorization to API calls, how to store a session, etc. Torii's providers are designed to be re-usable without the session manager though, and they work just great with Simple Auth. Check this out: https://github.com/Vestorly/torii/blob/master/example/simple-auth.html https://github.com/Vestorly/torii/blob/master/example/simple...
grimtrigger 12y ago
I think http://DailyCred.com http://DailyCred.com has a good solution for this. They host the entire front end during authentication and shoot you back an auth token which you can then grab the user info from. Surprisingly, its the only one service I could find in the space that supports email login. There's lots of providers for social login, but as far as i can tell DC is the only one doing email.
- zizee 12y ago
  Authic is another option (http://authic.com http://authic.com) for email auth. It also provides payment gateway integration as well.
  - grimtrigger 12y ago
    Very cool. Wish I knew about this a few days ago. Based on the pricing page (https://www.authic.com/pricing https://www.authic.com/pricing), it looks like you're capped at 100 paying users. Is that right?
    - zizee 12y ago
      Hey, Sorry I didn't respond earlier. Thanks for the praise! We definitely support more that 100 paying users (we really have no limits). We're still exploring our pricing options but we'll be releasing our larger plans soon. The next plan up will be something like 1000 paying users for $99/month soon. I have always found it difficult to keep monitor HN for responses to my comments!
ulisesrmzroche 12y ago
What do you think about using something like jwt?
MichaelGG 12y ago
Please don't require a "session" unless it's possible to set an infinite timeout. It makes writing an API client very difficult, because before every request, you've gotta go check to see if your session is valid. In a backend scenario, this adds retry complexity that wouldn't be there otherwise. It's so much easier if the request can contain an auth header/parameter pointing to a long-term API key or equivalent.
Kiro 12y ago
I thought you were supposed to avoid sessions and states in apps built on top of RESTful APIs. What am I missing?
- ipedrazas 12y ago
  Well, you can always protect an endpoint by requiring "whatever" condition. Impossing conditions for requests is different than "having a state". State happens in the client, requests to the backend come with pre-conditions.
- coldtea 12y ago
  That this is not REST api level session/state. It's an auth session, which is orthogonal (and transparent) to the REST api (e.g with cookies).

105 points by mixonic 12y ago

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.

mixonic 12y ago
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.
- scrollaway 12y ago
  I find that Persona simplifies auth a lot. https://www.mozilla.org/en-US/persona/ https://www.mozilla.org/en-US/persona/
pedalpete 12y ago
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.
- avoid3d 12y ago
  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.
- pyre 12y ago
  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.
  - crudbug 12y ago
    It exposes your application structure.
    - pyre 12y ago
      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.
    - bmm6o 12y ago
      What's the threat model here? That a potential attacker knows more about your application? Then what?
- meowface 12y ago
  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.
avoid3d 12y ago
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.
iamstef 12y ago
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.

EGreg 12y ago

Why is this a big deal? Obviously OAuth can be done with a popup. What we really need is instant and anonymous personalization when a user enters the app.

EGreg 12y ago
I wonder why it's being downvoted

qhoc 12y ago

Firebase has very good implementation on Simple Login for authentication. Check out AngularFire project. But I have to agree with some of the comments, backend authentication should be recommended. I can't get away from being nervous about password as text or session hijacking, etc.. with frontend authentication.

forgotAgain 12y ago

I prefer having the authentication in a separate page. Single page apps ( +1 for auth) have a lot of complexity. I find that breaking out the onetime use authentication code and markup makes the main application page somewhat less complex.

lukenyc 12y ago
If you can get away with that, it's certainly a way to reduce complexity. However, providing in-flow auth without a page reload is undoubtedly a nicer, faster experience. This library seems like a good way to lower the effort for Ember app developers.

guidedlight 12y ago

From a coding perspective. I find that using 'Annotations' for security works really well in SPA and is extremely simple. It means that every RPC from the client has authorised checks. I also assume that every unauthenticated request is forbidden, unless I have explicitly annotated the RPC method with anonymous access.

pyre 12y ago

I've had good results with: http://ember-simple-auth.simplabs.com/ http://ember-simple-auth.simplabs.com/ in Ember, though most of what it's good at is managing the session on the client-side.

mixonic 12y ago
We discussed dropping Torii's simple session manager in favor of recommending Simple Auth, but after discussing it with @marcoow decided we had slightly different goals. Torii's session manager imposes structure and terminology on your code, but had no specific conventions around how to pass request authorization to API calls, how to store a session, etc. Torii's providers are designed to be re-usable without the session manager though, and they work just great with Simple Auth. Check this out: https://github.com/Vestorly/torii/blob/master/example/simple-auth.html https://github.com/Vestorly/torii/blob/master/example/simple...

grimtrigger 12y ago

I think http://DailyCred.com http://DailyCred.com has a good solution for this. They host the entire front end during authentication and shoot you back an auth token which you can then grab the user info from. Surprisingly, its the only one service I could find in the space that supports email login. There's lots of providers for social login, but as far as i can tell DC is the only one doing email.

zizee 12y ago
Authic is another option (http://authic.com http://authic.com) for email auth. It also provides payment gateway integration as well.
- grimtrigger 12y ago
  Very cool. Wish I knew about this a few days ago. Based on the pricing page (https://www.authic.com/pricing https://www.authic.com/pricing), it looks like you're capped at 100 paying users. Is that right?
  - zizee 12y ago
    Hey, Sorry I didn't respond earlier. Thanks for the praise! We definitely support more that 100 paying users (we really have no limits). We're still exploring our pricing options but we'll be releasing our larger plans soon. The next plan up will be something like 1000 paying users for $99/month soon. I have always found it difficult to keep monitor HN for responses to my comments!

ulisesrmzroche 12y ago

What do you think about using something like jwt?

MichaelGG 12y ago

Please don't require a "session" unless it's possible to set an infinite timeout. It makes writing an API client very difficult, because before every request, you've gotta go check to see if your session is valid. In a backend scenario, this adds retry complexity that wouldn't be there otherwise. It's so much easier if the request can contain an auth header/parameter pointing to a long-term API key or equivalent.

Kiro 12y ago

I thought you were supposed to avoid sessions and states in apps built on top of RESTful APIs. What am I missing?

ipedrazas 12y ago
Well, you can always protect an endpoint by requiring "whatever" condition. Impossing conditions for requests is different than "having a state". State happens in the client, requests to the backend come with pre-conditions.
coldtea 12y ago
That this is not REST api level session/state. It's an auth session, which is orthogonal (and transparent) to the REST api (e.g with cookies).