In one of the projects Expero worked on several years ago, the client chose to build their own custom authentication solution. For three weeks, one developer’s status at the scrum every morning was “security.” It took that competent developer several weeks to get a very basic custom solution in place. Additionally, that solution didn’t even have integration with other identity providers or any other bells and whistles! You can easily double that estimate if you want even a few providers and a user interface that doesn’t look drab.

In another project that we recently completed, the decision was up to us, so we chose instead to use Auth0. In the time it would have taken us just to implement a non-impressive, custom authentication solution, we had the first version of the application fully working with authentication and a suitable set of new, useful, application-specific features.

What is it?

Auth0 is a single sign-on solution for your application. Think of Auth0 as a one-stop shop for all your user authentication needs. Want to manually create and manage your user’s credentials? Want to allow users to use their Google or Facebook logins on your application? How about some enterprise-based login, like Exchange? Yes to all of the above. It allows you to manage all of that, in addition to many advanced features, all from your project’s Auth0 web portal. It really takes the time and headache out of getting your authentication ready to go. Once set up, it provides a nice login widget for your application as well.

‍Auth0 login widget

How does it work?

The login form hits the Auth0 API, which then returns a token if authentication succeeds. All future communication with your app server can pass that token in the headers so your API knows that an authenticated user is trying to perform some action. At the very basic level, the flow will go something like this:

‍Flow of login requests when using Auth0

This flow can be accomplished fairly easily. A quick ReactJS snippet after the account is set up and proper packages are imported would look something like this (the full code needed can be found in the Auth0 documentation):

var App = React.createClass({

componentWillMount: function() {

},

});

var Home = React.createClass({

showLock: function() {

// We receive lock from the parent component in this case

// If you instantiate it in this component, just do this.lock.show()

this.props.lock.show();

},

render: function() {

return (

<div className=“login-box”>

<a onClick={this.showLock}>Sign In</a>

</div>

);

}

});

There really isn’t much to getting your project talking to Auth0. Yes, there is a cost associated with it, as it is provided as a service, but the time needed to implement a custom solution and then add integrations for each of the many different identity providers, like Google, Facebook, etc., will likely carry a higher cost than simply setting up Auth0. Each of these integrations costs valuable development time. Additionally, where security is crucial, having to test a custom solution very thoroughly would cost a lot of extra time and resources. What initially seems like a very simple login turns out to be much more complicated once you realize all the pieces needed to implement a complete authentication solution, including signup, login and password recovery at the very least.

What are the other benefits of using Auth0?

Portability: As your project’s technology or code base changes over time, a custom solution may need to be redeveloped as well. With Auth0, all it would take is to swap out the small snippet of integration code with the new version.

Simplicity: Maintenance and security issues are no longer your burden; they are offloaded to Auth0.

Better Usability: The widgets available from Auth0 (e.g., login form, forgot password form, etc.) have already been constructed and their look and feel has already been vetted. You can, of course, override the look, but even the defaults look nice and will be straightforward for users.

Faster Prototyping and Delivery: Using a fully developed, existing solution will reduce your time to market. If you’re in the prototyping stage, it enables you to get a prototype in front of your stakeholders more quickly.

Less Damage If Hacked: It seems like every other site is getting hacked nowadays. If you’re ever the target of such an event, you lessen the damage since you do not store any user login credentials on your own servers.

Better User Security: Not storing the user credentials yourself reduces your liability. Additionally, knowing that Auth0 will take all necessary security precautions when handling the credentials gives you and your users even more assurance.

Trivial to Add/Remove Identity Providers: Auth0 includes support for social logins (e.g., Facebook, Twitter, etc.) as well as for enterprise providers (e.g., Microsoft Exchange, etc.). If you want to support a new identity provider, either now or in the future, you simply have to toggle a box in the Auth0 web interface:

‍Configure identity providers in Auth0

On the other hand, implementing a custom solution would require a good amount of extra code per provider. For example, you can see from the Facebook Login for the Web with JavaScript SDK page that it takes many lines of code just to get Facebook integration working. Imagine doing something like this for each provider you want to support. The code grows and adds up quickly.

In the end, it comes down to return on investment. For me, it’s a no-brainer. In order to make quick progress on the features I’m really interested in, I leave the thoroughly tested authentication logic to Auth0 and spend my time and energy on the fun stuff.

We are not affiliated with Auth0. This is not an ad, nor are we compensated in any way from them. We have found that it allows us to deliver better solutions to our clients in a timely manner.

If you have any questions or would like to share your authentication experiences, we’re here to listen and help.