Authentication databases and services

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:

• Authentication is identifying the user. It answers the question “Who is this user?”
• Authorization is deciding what the user can do. It answers the question “Can this user perform this action (for this resource)?”. For example, “Can this user change another user’s contact details?”
• IdP is “Identity Provider”, a centralized trusted party and source of user information, often also the user database. IdP is usually accessed over OpenID, SAML or some other similar protocol.
• SSO is short of Single Sign-On. In practice this means that the user signs in once, and can access multiple different services. For example, when you sign in to your Google account, you can use multiple different services — gmail, calendar, contacts etc. — without entering your email and password again.
• OpenID is an authentication protocol. Relatively lightweight. Do note that OpenID Connect is different thing from OpenID 2.0 - OpenID connect is a layer on top of OAuth, and plain OpenID is a separate protocol.
• OAuth is an authorization protocol (but nowadays OAuth is often used for authentication as well). Used “everywhere”.
• SAML is Security Assertion Markup Language, an enterprise, XML-based authentication and authorization protocol, which can do everything but is difficult to setup, configure and maintain.
• JWT: JSON Web Tokens. A really lightweight standard for cryptographically signing data so that changes can be detected.

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
  • Auth0: ready-made or custom
  • Stormpath: must be implemented by the developer
• Two-factor authentication
  • Auth0: built-in, with possibility to add custom rules. If need be, developer can implement a custom one on the application side.
  • Stormpath: must be implemented by the developer (no support APIs, handled on the application side).
• Libraries
  • Auth0: everything Stormpath supports plus iOS and Android libraries for mobile apps support.
  • Stormpath: all major programming languages (Java, node.js, Ruby, PHP, Python). Integrations for mobile apps need to be implemented by developer.
• IDP support
  • Auth0: SAML, OAuth, OpenID, JWT
  • Stormpath:  SAML, OAuth, OpenID, JWT
• Authentication providers (the most important ones):
  • Auth0: Google, Facebook, built-in database, LDAP (connector), AD (connector), OpenID, OAuth, Google Apps
  • Stormpath: Google, Facebook, built-in database, LDAP (sync agent), AD (sync agent)

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.