Recent issues with Auth0 and How I Solved Them

I have watched a number of courses and tutorials online, from great providers such as Udemy, Pluralsight, Front-End Masters, Egghead, Treehouse and others.  I’ll be mentioning some of these from time to time, but today I want to mention what they never talk about in Angular 2+ courses:  user login/authentication/authorization.  At least not in a way that relates to the Real World.

I have struggled with protocols such as OAuth 1.0 and 2.0 and OpenId and others, but after hours of combat laid down my sword and walked away.  It’s not that I couldn’t get them to work, but it was so much work it wasn’t worth it, for me, working alone on a personal project.

And then one day I discovered Auth0, and the angels sang.  You may have discovered it too.  My point today is not to talk about how to implement it– their own tutorials are quite good at that, but to mention something that frustrated me for a while recently.

In the last four months of 2016 I had done a lot of work on my app and implemented Auth0.  It worked fabulously.  Then I had to attend to moving 3000 miles across the country, and couldn’t spend time on it.  Once I got moved and had my computers up and running in June of 2017, I got back to it.  I updated my libraries, and authentication no longer worked.

There were three reasons for this.  One was my fault, and the others were not.

At some point in the last four months, Auth0 changed a couple of things.  You may know that to determine whether a user has been authenticated, you write a little function in the auth service, usually called isAuthenticated(), and this code checks to see if your JWT token is expired or not (this requires the use of the angular2-jwt library):

public isAuthenticated() {
    return tokenNotExpired();
}

The tokenNotExpired method previously checked for an item in localStorage called idToken.  You put that token into local storage in the callback method for the Auth0 authenticated event, by getting it from the authResult.idToken.

The thing is, they changed the name of the localStorage value that the tokenNotExpired method checks.  Instead of being idToken as it formerly was, it is now just “token“.  However, the name in the authResult remains as idToken.  So now you do this:

this.lock.on('authenticated', (authResult) => {
    localStorage.setItem("token", authResult.idToken); ...

and that part works.  I understand that the reasoning behind changing the name had something to do with “idToken” implying that this identified the user, but since the token is used to authenticate and not identify, Auth0 changed its name, at least for the JWT check.

I am all about making sure that the words you use in your code represent what is contained.  I applaud the decision to change it.  I do not applaud the decision not to let everyone know it changed! And I wonder why they did not go a bit further and change the property of authResult from idToken to token.

The second thing Auth0 changed was they deprecated the use of the lock.getUserProfile method and changed it to lock.getUserInfo.  This wasn’t a breaking change, but good to know about.

And the one that was my fault?  I ignored my MacBook for days, maybe weeks, when it alerted me that I needed to update.  Meanwhile, libraries for the new version of Chrome were installed in my node modules.  For some reason, this caused my localStorage not to actually set items.  So even though my code was correctly setting items in localStorage, they were never persisting.  Once I updated the computer, everything magically worked.

And we all lived happily ever after.

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s