User authentication and sign-ups are a thing that comes up in many web services. Nowadays it is often “sign in/up with Facebook/Twitter/Google account”, but also signing up with email address, and storing some custom information, such as shipping address or other preferences.
This is basic functionality that is offered by many (backend) frameworks. However, things get more complicated if there is more than one service, possibly implemented in different platforms, using the same authentication system. Furthermore, there’s plenty of other components: “forgot your password”, probably two-factor authentication, management UI for users and so on.
Identity Access Management (IAM) SaaS (software as a service) have advanced to a level where building a custom solution (on top of an existing framework and using appropriate libraries) for all this is no longer an obvious choice.
First, some terminology and technologies:
Then, what you should check and determine first when choosing authentication system:
Authentication sources and integrations: will you have your own user database, or will it be an existing AD/LDAP or something else? Do you need to support external logins such as Facebook, Google or Twitter?
Single Sign-on: do you need single sign-on now or in the foreseeable future? If you do, you shouldn’t integrate the authentication database, login form etc. tightly to your first application. Instead, all your applications should use some authentication protocol, such as OpenId, to authenticate.
Can you use a cloud service? Are there legal or contractual limitations? Do you (really?) need customizations that can’t be done on top of a cloud service? Customizations even in a locally run SSO service might not be trivial to implement.
How complex will the authorization logic be? Do you have a huge number of role-based rules, or is it something closer to “there’s users and admins. Users can touch their own data and admins can do everything”? If you have something this simple (or on similar level), ready-made SaaS might be a good match for your needs. Even if your authorization logic is really complex, you can still outsource authentication to SaaS.
Should you support two-factor authentication? In short, yes you should. Properly implementing two-factor authentication, including robot calls or SMSes, by yourself is a huge effort.
These are just a starting point, but already a long way towards evaluating different alternatives.
Several Google searches and browsing through forums, email lists and blogs revealed a large selection of IAM SaaS solutions: Auth0, AuthRocket, DailyCred, OneLogin, PortalGuard, Stormpath, and UserApp. In the end, only two of the services seemed to be serious contenders: auth0 and Stormpath. At this point, it is important to disclose that this comparison is based entirely on providers’ documentation - due to time constraints, neither service was actually used before writing this blog post.
Login and sign-up forms
Authentication providers (the most important ones):
Auth0 and Stormpath take rather different approaches to the functionality and libraries. Auth0 tries to implement everything needed for an authentication system, while Stormpath just provides the APIs and the backend, but requires the developer to implement everything on top of that.
From a security point of view, probably the most problematic part is the missing two-factor support in Stormpath. For anything sensitive, allowing users to take two-factor authentication into use is considered the norm nowadays. However, implementing a robust two-factor authentication with all the corner cases handled properly is a surprisingly complex task. Auth0 offers two-factor authentication support with custom rules (for example, the second-factor is only required if the location does not match, or if the user’s location changed too much), which improves the usability greatly, as entering a one-time password is not always required.
At least on paper, Auth0 is more attractive: it offers everything Stormpath has plus some more.