Tonight I wanted to write about my current journey with moving our user identity management provider (which shall rename nameless), over to Auth0. I would like to talk about the pitfalls and triumphs as we go. It's mostly all good - a shame we hadn't done so sooner!
Now one of the most attractive attributes is the different methods/connectors that are provided in order to easily integrate your existing system, and I mean they cover just about everything, but this is also a segway to my first - very little - bit of criticism. From what I see there are two main channels to provide some type of form to present to your user to input their credentials. By the way, I'm still learning so please feel free to say I'm wrong at any stage.
There is a mention of a "custom" way to work with Lock, but the customization looks little to be desired. As to the hosted pages, well, again - correct me if I'm wrong - but it looks like the form being hosted has to contain the whole DOM, and if I'm going to make changes to my site's general template, I don't want to have to come back in here and do separate alterations.
I should also give a quick callout for the plugin they have developed for WordPress: Login by Auth0. I've done some intial testing, and it works very well, and with all the functionality WordPress gives you, I understand you would just need to use its existing methods to login and create forms around. Maybe it's just a bad name, but this got me to thinking how I would effectively create users as well using it.
But I digress, for me, I just want to tap in to the API's directly and build the form myself in our own environment - so for our migration, I am using the JS SDK (v9). I've overcome a few hurdles, one of the most confusing aspects is the cross terminology from one type of API call to another.
For instance, take this example from this documentation, covering the use of the userinfo API. After the user has signed in, and they are given an access code, this is the same code you would use in place of the header: Authorization: Bearer {ACCESS_TOKEN}.
However, don't let this confuse you with that if you wanted to do something like a "user search", or "link accounts" etc. This is done with the Auth0 Mangement API. You'll also notice that unlike API's such as userinfo, where the URL is structured like: https://YOUR_DOMAIN/userinfo, the management API uses the format of https://YOUR_DOMAIN/api/v2/....
This management API uses a separate retrieval of an access token, which you can follow this guide on how to retrieve it.
Hopefully this has given some extra food for thought, and I'm sure this won't be the last I write on this subject. Nitty-picking at things aside, I'm very excited our team has collectively decided to use this platform. It's tailored directly for devs!
Now one of the most attractive attributes is the different methods/connectors that are provided in order to easily integrate your existing system, and I mean they cover just about everything, but this is also a segway to my first - very little - bit of criticism. From what I see there are two main channels to provide some type of form to present to your user to input their credentials. By the way, I'm still learning so please feel free to say I'm wrong at any stage.
There is a mention of a "custom" way to work with Lock, but the customization looks little to be desired. As to the hosted pages, well, again - correct me if I'm wrong - but it looks like the form being hosted has to contain the whole DOM, and if I'm going to make changes to my site's general template, I don't want to have to come back in here and do separate alterations.
I should also give a quick callout for the plugin they have developed for WordPress: Login by Auth0. I've done some intial testing, and it works very well, and with all the functionality WordPress gives you, I understand you would just need to use its existing methods to login and create forms around. Maybe it's just a bad name, but this got me to thinking how I would effectively create users as well using it.
But I digress, for me, I just want to tap in to the API's directly and build the form myself in our own environment - so for our migration, I am using the JS SDK (v9). I've overcome a few hurdles, one of the most confusing aspects is the cross terminology from one type of API call to another.
For instance, take this example from this documentation, covering the use of the userinfo API. After the user has signed in, and they are given an access code, this is the same code you would use in place of the header: Authorization: Bearer {ACCESS_TOKEN}.
However, don't let this confuse you with that if you wanted to do something like a "user search", or "link accounts" etc. This is done with the Auth0 Mangement API. You'll also notice that unlike API's such as userinfo, where the URL is structured like: https://YOUR_DOMAIN/userinfo, the management API uses the format of https://YOUR_DOMAIN/api/v2/....
This management API uses a separate retrieval of an access token, which you can follow this guide on how to retrieve it.
Hopefully this has given some extra food for thought, and I'm sure this won't be the last I write on this subject. Nitty-picking at things aside, I'm very excited our team has collectively decided to use this platform. It's tailored directly for devs!
Comments
Post a Comment