
Authentication for Single Page Apps - mixonic
http://madhatted.com/2014/6/17/authentication-for-single-page-apps
======
agnokapathetic
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.

~~~
pedalpete
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.

~~~
pyre
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
It exposes your application structure.

~~~
pyre
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.

------
forgotAgain
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
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.

------
grimtrigger
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
Authic is another option ([http://authic.com](http://authic.com)) for email
auth. It also provides payment gateway integration as well.

~~~
grimtrigger
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
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!

------
qhoc
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.

------
MichaelGG
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.

------
ulisesrmzroche
What do you think about using something like jwt?

------
guidedlight
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
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
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...](https://github.com/Vestorly/torii/blob/master/example/simple-
auth.html)

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

~~~
ipedrazas
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.

------
EGreg
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
I wonder why it's being downvoted

