Make Authentication Fun Again

First things first..I’m a coder. From the time I first learned to code, I was hooked. The ability to create whatever you want by giving a computer instructions was absolutely amazing to me. I gobbled up every book I could find, learned every language and design pattern I could, because I wanted to be the best coder in the world!

Then I came to the real world and started writing production code… and it sucked.

Granted this was at a looong time ago.

But there was sooo many steps you had to do before you could get to the fun stuff in coding.

AND THEN..you had to worry about security, and do fun things like Authentication, and Authorization, and ya know create secure code. Where is the fun in that!?!?

Fast foward a number of years that I don’t want to write, and we are in 2024. An absolute coding nirvana. AI has revolutionized the way you code, and truly made it a pair programming experience, and security companies have made cumbersome things like authentication actually fun to implement.

Yeah, never thought I would say that.

More importantly ( in my opinion) security companies have realized that in order for things to really be secure, end users have to use it, and developers have to be able to work it into their coding efforts. It can’t be a huge uplift and an expectation of every developer to be a security architect over night. They ( devs) needs access to best practice security standards in a consumable way.

Enter our friends at Descope.

A couple of months ago I was introduced to the crew over at Descope, and one of the things that I absolutely loved about their product was that it was the “No-Code” style builder that allowed anyone to build user journeys. We are seeing more and more of this show up in enterprise style security tools, because WE HAVE to move security closer to the business. I firmly believe that it’s our job as practitioners/developers/ and overall tech nerds to create things that are easy to use, but robust behind the scenes. To do that we have to not just get the users input, but allow them to guide and create right along with us. But, I’ll get off that soapbox for now. Let’s get back to Descope and what I’ll be doing with this blog.

A couple of months ago I started down the path of creating an AI Virtual Consultant that specializes in identity. I called it Franklin. ( You can check it out here). After talking with the Descope crew, I decided to switch over the authentication from Kinde, over to Descope, and I would document the experience here in the Identity Jedi Universe. So over the next couple of weeks, I'Il be making updates to Franklin and “live blogging” about the experience here!

( It’s going to be weeks, because unfortunately I’ve also go to do 9-5 stuff)

So I’ll update this blog with screenshots, and commentary as I make the changes, and you can follow along here, or by logging into Franklin and seeing the changes for yourself. And then once I’m done, I’ll do a wrap up article to summarize the experience. I can’t tell you how excited I am for this!

Huge shoutout to the Descope crew for being apart of this! Thanks so much for the partnership!

Ok back it! It’s Friday December 20th..here’s what we got.

I needed to update all references in my code to now use Descope instead of Kinde. That’s done, and I’m getting ready to run a quick test locally to see where we are at, and then I’ll push to prod.

I have a feeling I’m not exactly handling the backend checks for authentication users “correctly”, but we’ll just see if this works.

It bombed..lol

But the login user journey was working! That’s a start! Looks like I ‘ve still got some Kinde references in there…going to update those..and also grab my Chick-Fil-a order..cuuz coding requries fuel.

What’s going to be interesting with this whole project is how much I end up refactoring the application, while implementing this new auth. Which I totally shouldn’t do, I should just focus on one thing at a time, but where is the fun in that?

Also seeing a weird error about failed to validate JWT in my Middleware stack…that’s probably important

Ok first error is Kinde hade a lovely LogoutLink component that I could use for having a Logout Button, so I need to replace that with Descope functionality, simple task just create a function and button, however I’ll add to my “Nice to Have List” an action to create my own custom component for this later.

Meh..wasn’t that hard so I just went ahead and made it a component..figured I’m going to need to call that functionality again some where.

The joys of coding….running into an Ecmascript error where it keeps thinking my “use server” directive isn’t at the top of the file… 🙄

This error is kicking my ass…found a thread that said it may have something to do with using hooks. I removed the Descope calls just to see if that was it..no dice….may be end of the coding for today..

Ok last update. Think I figured out the issue. Basically you can’t use hooks in server actions with NextJS..so I have to use Descope’s Backend SDK to validate the session when calling my server actions. So I got one of my server actions fixed, but my next server action needs to know the user id of the logged in users, and it doesn’t seem like the backend SDK let’s you do that..easily.

Refactoring here I come…Originally I was using the unique-Id of the user and adding it to the db records and using that to look up specific records. ( Yeah not the best I know, but hey this is Hackathon level coding here). So what I’m thinking of doing instead is to re-architect how I’m doing authorization, and move that into descope. Basically my functions should just load data, and use Descope to handle authorization. But not doing that tonight, College Football is on and Notre Dame just scored a 99 yard touchdown. So that’s it for this Friday night.. Ba