Identity as a Service: Auth0 vs Okta vs Azure AD B2C – First Look

Note: this blog post is a first look!  I haven’t had enough time to compare all of the features and capabilities so go easy on me!

This isn’t the first time I’ve blogged about SSO, but this is the first time that I’m taking a look a deeper look at the Identity-as-a-Service space (IdaaS as it’s known).

For the typical enterprise use cases I’ve encountered previously, I’ve been totally satisfied with AD FS and Microsoft’s now retired Windows Azure Access Control Service product, which was retired this April.  I find that to be a shame because it really was “AD FS in the cloud”. It was extremely easy to use, easy to setup, and easy to manage — even in the old, gen 1 Silverlight based console that never got updated.  Of course it lacked a lot of features compared to Auth0, Okta, and even Azure AD that define this emerging space.  Tools like Auth0, Okta, and Azure AD add many integrated capabilities that enterprises expect today in an identity management platform such as multi-factor authentication, activity tracking, anomaly detection, and user management among other things.

There is currently no production ready functionality that matches Azure ACS.  Instead Microsoft somewhat fragmented their offerings with Azure Active Directory, Azure Active Directory B2B (a subset of Azure AD), and Azure Active Directory B2C.  Of these three solutions, only B2C offers true federation capabilities which is still in preview mode using what is known as Custom Policies.  Azure AD and B2B work great — as long as you don’t need/want direct federation.  Microsoft has a handy page with a good comparison of the two (note that direct federation is a future feature of Azure AD B2B so we could see B2C eventually folded into a single offering) and Tomasz Onyszko has a good write up with details that I’ll quote:

• Azure AD is an identity as a service provider aimed at organization users to provide and control access to cloud resources
• Azure AD B2B is not a separate service but a feature in Azure AD. It allows cross-organization collaboration in applications from an identity standpoint.
• Azure AD B2C is an independent service for building consumer application identity repository. If you need a service to handle email or Facebook login – it is there for you.

Of course, the question is what if you have a product that bridges external users with cross-organization and enterprise users — a true cloud SaaS?

This is, then, a scenario where federation is required and described in the Azure AD B2C documentation:

In planning for the future of innovoPOINT, my team has started to investigate options for more modern authentication to offer our customers as we move the product forward.  Ideally, we can satisfy the needs of our organizational customers as well as their external collaborators while offering an easy to use, secure, and easy to manage solution.

Let’s take a look at some first impressions.

Azure AD B2C Custom Policies

By far, this is the most immature solution of the three at this time.  Operations that are straightforward in Auth0 are straight up clunky in B2C requiring modifications of multiple XML files with not enough depth in the documentation to really give you a good idea of what’s going on.  From the very moment that you create the B2C tenant, it starts to get confusing because you have to go back to your main directory and link the B2C tenant to it for billing purposes.

Don’t get me wrong, for Microsoft documentation, it’s pretty good.  The code and configuration even works once you get it all wired up correctly.  But it took me the better part of two days and multiple tries before getting things working right due to instructions which were too straight forward and lacked a high level conceptual description.  For example, when setting up B2C custom policies, there are 4 places where it’s possible to set up app registrations.  There’s the top level app registration and you can register an app under your AAD (they’re actually the same).  Then when you create your B2C tenant, it actually exists as an entirely separate container. So there’s an entirely separate set of app registrations.  But you need both for the setup to work.

In an attempt to help clarify how all of the pieces are linked together, I hope someone (perhaps me in a few weeks) finds the following diagram useful:

While I give credit to Microsoft’s documentation for being direct and accurate, the problem is that when you’re working in two directories in Azure, you’re working in two directories and you have to switch your workspace back and forth and it’s super easy to do app registration in the wrong browser window.  This alone caused me at least a half days worth of work as I retraced my steps (tends to happen when you’re manually editing XML files) just to find out that I was referencing the app registration in the wrong directory.  In some sense, I feel like if Microsoft wants to separate B2C from Azure AD, they should use different terminology so it’s more clear (for example, Auth0’s usage of “client”).

Here’s what you see when you log into your main Azure portal and try to access B2C:

To actually switch into your B2C directory, you have to go to your profile and pick one:

Once you get to the Identity Framework Experience where the custom policies are managed, you’re left with a very sparse interface where you’re going to be editing and uploading a bunch of XML files and follow along with the ASP.NET Core MVC 2.0 guide since a lot of the authentication code has changed between Core 1.x and 2.0.  By the way, there’s no direct link from the Azure AD B2C configuration guide to the code, which would have been helpful!  There’s a very important note in that guide that is buried 2/3’s of the way down the page and that’s that the Authority must have tfp in the path like this:

It’s a small detail that’s very easy to miss.

Auth0

After getting the Azure AD B2C scenario working, the Auth0 experience was a breeze.  Basically, all of the editing and setup in the B2C tenant is nicely configured in two screens.  First, the Enterprise Connections:

And the documentation and guide for how to set it up is crystal clear.  And there’s a really nice touch in their documentation:

The next step is to set up the “client” (the terminology here is simply much, much clearer):

And then follow the easy to access guide for hooking up your application:

While I mentioned above that the documentation for B2C was “good”, that’s relative to a lot of the documentation you tend to get from Microsoft.  The Auth0 documentation is next level stuff.

It was a relative cakewalk; I was able to get it up and kinda working within 2 hours of starting.  The problem is that it didn’t work.  When I get to the login screen, nothing happens.  No console errors logged, no observable HTTP requests going out.  It seemed like a script error on their side.

I posted a question and waited several hours with no response until it clicked that I had forgotten to set a domain alias to serve as a home realm.  Once that was set, everything worked as expected.  A helpful console error or other notification would have been great!

Okta

After my successful outing with Auth0, I felt it was a good time to keep chugging and try out Okta, one of the industry leaders in this space according to Gartner:

As our customers are in life sciences, it was promising to see both Shire and Allergan in their customer list; pharma and cloud have traditionally been like oil and water.  Like Auth0, its clean, modern, and logically oriented UI is refreshing after dealing with Azure blades (can’t believe that that thought it was a superior design).

The only problem is that there’s seemingly no way to add Azure AD as an IdP:

Is this a result of my “Developer” account?  I’m not sure; the pricing page seems to indicate it should be available.  I posted a question in their developer forums, but as with Auth0, there was no feedback at all!  Thinking that I missed something, I Googled various combinations of Okta Azure AD to no avail; there was no link to any documentation that documented this scenario.  The guide linked from the Okta interface sends me here:

This application registration portal seems tied to my Azure AD tenant, but it doesn’t show up anywhere in my Azure portal once registered and there’s no documentation that walks through if/how this ties back to my Azure AD tenant.

I gave up at this point because I was expecting better documentation and a better overall experience from an industry leader.  I don’t know how many employees Auth0 has, but Okta is a publicly traded company; I’d sure hope they’d be able to put together some better documentation on common scenarios (you know, like connecting to your enterprise Azure AD).  Not only that, it felt a bit stingy to not provision a fully featured developer preview; how can one be expected to evaluate the product with a partial set of features?

First Look Conclusions

They say that first impressions are important and Auth0 definitely impresses with the ease of use, well designed interfaces, and superb investment in documentation.  I will continue to try to figure out Okta, but perhaps I expected more from them given their positioning in the market and premium price; I expected to breeze through it after using Auth0.

Both Auth0 and Okta are more like a hybrid of Azure AD and B2C; it’s not clear to me why Microsoft chose this two pronged approach to what should be a unified identity management platform (seems to be coming in the future).  Both seem to more or less abstract the clumsy XML editing of B2C custom policies with very well designed interfaces with Auth0 being particularly easy and accessible.

Auth0 also has one particularly interesting feature: the ability to provision their capabilities on premise.  Still getting more info on this so it’s something to keep an eye on.

Look for future posts that focus more on the management features and additional capabilities like MFA and user management (login tracking, anomaly detection, etc).  After all, if not for these additional features, we could just directly add the Azure AD IdP to our application and skip the middle man.