4 ms·

The biggest problem with any of these "login as a service" systems is that on the web, you need to be able to set a secure (HTTPS only), server-only cookie in o

The biggest problem with any of these "login as a service" systems is that on the web, you need to be able to set a secure (HTTPS only), server-only cookie in order to provide a persistent login. You can implement that on your own server on top of this using their API, but it makes the amount of work much closer to "rolling your own" than "paste one line of JS on your static html site hosted in s3." The alternative is to either force a login on every visit, or store a session token in localstorage or similar, where any XSS vulnerability opens your sessions to an easy exploit. Auth0 and Stormpath, which are the 2 of these I have looked at most closely, seem to do the 2nd of those. Not sure what these guys recommend yet but I imagine it is similar. On mobile, this does not matter as much due to better filesystem access that an app will usually be granted compared to JS in a browser tab, where you can save your API key/JSON web token/etc. Auth is hard, but the cost-to-benefit of outsourcing seems fundamentally limited at this time due to the storage problem on the web.

ipapikas 11y ago
Thanks for the comment! At the moment we are focusing on frontend and mobile so we have to be able to access the authentication tokens from the javascript. However, localStorage is an option we are currently exploring to use instead of cookies. For mobile we agree that they have their filesystem to store the tokens securely.
leftnode 11y ago
I built a similar "login as a service" three years ago, and the biggest I came across was that any modern web framework already includes authentication and user management out of the box. And user management that is guaranteed to integrate with the rest of the framework. It was a really difficult sell trying to convince developers to use my service rather than their own framework.
OJFord 11y ago
Login-aaS seems conceptually strange to me. With a tonne of example code for social logins, why do these services' customers prefer to pay for the privilege of trusting the indirect social login to the provider's service? I'm very surprised if there isn't an open-source project with similar 'dashboard' etc. that Auth0 offers - and wouldn't the security-savvy guys prefer that?
deleted 11y ago
[deleted]

ipapikas 11y ago

Thanks for the comment! At the moment we are focusing on frontend and mobile so we have to be able to access the authentication tokens from the javascript. However, localStorage is an option we are currently exploring to use instead of cookies. For mobile we agree that they have their filesystem to store the tokens securely.

leftnode 11y ago

I built a similar "login as a service" three years ago, and the biggest I came across was that any modern web framework already includes authentication and user management out of the box. And user management that is guaranteed to integrate with the rest of the framework. It was a really difficult sell trying to convince developers to use my service rather than their own framework.

OJFord 11y ago

Login-aaS seems conceptually strange to me. With a tonne of example code for social logins, why do these services' customers prefer to pay for the privilege of trusting the indirect social login to the provider's service? I'm very surprised if there isn't an open-source project with similar 'dashboard' etc. that Auth0 offers - and wouldn't the security-savvy guys prefer that?

deleted 11y ago

[deleted]