5 Auth0 Gotchas to Consider

Using an identity provider (IDP) for user management has become the norm these days. And while it can get daunting to choose the best idp from the ala carte, it could help identify some of the shortcomings beforehand.

Given below are a few of Auth0's gotchas that I have come across and sincerely wish I knew them earlier.

Configurability Compromises:

Well, this could be a tough one for many, as the one thing that developers value the most is the power of configurability. Auth0 does offer decent configurations; however, if one really wants to tweak something, the API sometimes falls short.

Some of the limited or non-configurable features that I have faced are:

1. Customisations offered around their universal login
2. Changes around the rate limits and throttle
3. Email templates for sending out notifications (I have a whole other blog right here where I have a workaround for this.)

Forgotten Flows:

Auth0 has this concept of actions, which are basically functions that execute at a certain point. A flow would have a set of actions that would get triggered as a result of an event. Auth0 has flows for login and a couple of other events, but surprisingly, it doesn't have one for logout. Now this is a pain point because there could be actions that you would want to trigger once a user logs out. Sure, you could depend on the SLO event, but it would make more sense if they had a separate flow for logout.

Awkward Apis

I have seen many, but the ones that definitely need a rewrite are their passwordless apis. Here, fields like the email or phone number of the users can be compromised way before they have logged in, thereby paving the way for brute force and other attacks. In fact, Auth0 can easily solve this problem by simply replacing these fields with user_ids, just like in their other APIs.

This is what the one of the passwordless api looks like:

POST https://{yourDomain}/passwordless/start
Content-Type: application/json
{
  "client_id": "{yourClientID}",
  "client_secret": "{yourClientSecret}", // For Regular Web Applications
  "connection": "email|sms",
  "email": "{email}", //set for connection=email
  "phone_number": "{phoneNumber}", //set for connection=sms
  "send": "link|code", //if left null defaults to link
  "authParams": { // any authentication parameters that you would like to add
    "scope": "openid",     // used when asking for a magic link
    "state": "{yourState}"  // used when asking for a magic link, or from the custom login page
  }
}

Insufficient Information

Teams that use Auth0 heavily rely on their logs and log event type codes when it comes to debugging and monitoring. And yet, Auth0 doesn't send user_id when there is a password leak (pwd_leak) or when an IP address is blocked because it has reached the maximum number of failed login attempts on a single account (limit_wc). Now, this is concerning because tying the event back to the user_id could get really cumbersome, as then we need to rely on other attributes. This can be easily solved if user_id is also included in these events.

Documentation Daze

I found that sometimes Auth0 documentation can be really confusing, and it could take hours to find relevant information. Most often than not, I have found leads in their community support channel (which is very active and helpful) rather than the documentation. This also proves that many have been in or are in the same boat as me, so hopefully this blog helps at least some of them.

These gotchas are honestly head-ups that should be considered while working with Auth0. No software is perfect. Having said that, knowing the imperfections in advance surely ensures quicker workarounds, lesser bewilderment, and, most importantly, a good night's sleep.

P.C. unsplash