Ep. #29, Identity Management with Auth0

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line, I've got Ado Kukic. I'm having you here because you work for Auth0. So, do you want to explain who you are and what Auth0 is?

Ado Kukic: Sure, absolutely. My name is Ado Kukic. I work as a Developer Evangelist at Auth0. At Auth0 what we do is we are a Authentication and Authorization as a Service startup company.

What we want to do is we want to make it very easy for developers, regardless of stack, regardless of technology, to implement best-in-class authentication, authorization, single sign-on, basically, handle your entire identity management.

So you don't have to be a security expert to have a really good authentication system in place.

What I do with the company is I go out and I talk to developers. I host talks, host workshops on sharing best practices for implementing authentication and authorization the right way. Hopefully, in a way that is not going to get you on the front page of Hacker News or any other site saying that you've been data breached.

Brian: Is your background in security, or cryptography, or did you kind of find your way through another means?

Ado: Interesting story about that. My personal background is not heavily in security. In my past lives, I did build a couple of different authentication and authorization systems for companies that I worked at. But my background has always been more in education and in sharing knowledge.

So when I came onboard on the company, I actually started off as a technical writer, doing a lot of R&D and figuring out how to integrate Auth0 into different frameworks and different technologies, and actually making it digestible for new developers to understand how everything works.

So in the company, I'm not one of the big security experts. But we do have a lot of very well-known programmers who lead our architecture and development.

Brian: With Auth0, and I've got some familiarity with Auth0 because I've used it for some side projects as well as some more serious projects at work.

The beauty of it is you can drop in Auth0 as a solution into any sort of project.

Are there any limitations on projects that you can't use off Auth0 with?

Ado: That's the beauty of Auth0, is that we made it totally platform-agnostic. So whether you're building a single page application with Angular or you have an existing legacy tech stack that's built on Java 6 or any type of framework that you have, you can basically integrate Auth0 in.

We have SDKs, we have Quickstarts for over 50 different languages and frameworks that you can just, like you said, almost drag and drop or in our case, fork the repo, download it to your local machine and get started.

But we also do expose an API where if we don't have an SDK or a Quickstart for a specific language, you can always call our API directly and get the same exact functionality.

Brian: Cool. With Auth0, if I hand over my authentication to Auth0, I don't want the concern that some people might have, that they don't know the code or know what's been written or trust a service like Auth0.

How does security work for that, if I'm trusting Auth0 for the authentication of my customers but also my entire content of my site?

Ado: Absolutely, yeah.

Security and handing off your authentication for your application is probably one of the biggest things that you'll decide to do if you don't want to build it yourselves. Because if your users can't login, then your application is essentially hosed and nobody can access it.

So, the way that we built Auth0 is we built it entirely on open standards. We use JSON Web Tokens. We're using OpenID, OpenID Connect, SAML, and basically, all of the technology that we use is mainly open source, and one of the benefits of actually doing that is that we don't lock you into a specific architecture.

Everything that we're doing is not some custom code, some black box there that you have no idea what's happening. So the benefit that you get there is if down the line, you decide that Auth0 isn't for you, you don't have to re-architect your entire identity infrastructure.

You can just say, "I don't want Auth0 to issue JSON Web Tokens anymore. I'll have my own server do it, or a different provider."

So you're not locked in, you're not handing us over, essentially, the keys to your kingdom. You're basically just using our platform as a proxy for a secure environment.

Brian: My introduction with Auth0 was through the use of JavaScript, but you mentioned, I didn't actually realize this, that you guys have SDKs outside of JavaScript.

How does Auth0 keep up to date with all of that? If you're using all the open source standards, I guess it's easier because all the SDKs do have a language implementation of that. Is that correct?

Ado: Yes. If you go to our docs page, the first thing we ask you is what type of application are you building. And traditionally we have provided a lot more support in the JavaScript lang where we have an SDK for Angular, for React, for Vue, Ember, jQuery.

But we do want to support developers regardless of what their technology stack is. So our team maintains an SDK for every language.

And then if we see that a specific framework for that language is gaining popularity, and in Java lang, we have a standard Java SDK. But then we also have an SDK for Java Spring, or Play, or any number of the other Java frameworks that make it a little bit easier for you to get started.

Because really, what we want to do is

we want to make it effortless for you to implement Auth0 in your applications so you don't have to spend a whole lot of time doing research and figuring out how to write code.

We just want you to get it implemented and focus on building technology that's relevant to your business use case, that's relevant to your application.

Brian: Yeah, it makes a lot of sense, too. So what's your personal opinion between the, in general, when using an API, using the SDK over using just cURL commands, or direct access to HTTP?

I bring this up because I just built a project using GitHub's API, and I found some limitations in their SDK. So I just went back to cURL and started doing cURL commands. So, with your SDKs, are they fully featured or are there some things you're going to have to do directly from the API?

Ado: They are fully featured. All of the SDKs that we do support, and there is a lot of them. So it's a lot of work on our end to support all of them.

Brian: Yeah.

Ado: But we do want to give developers that same level of flexibility and functionality, whether they're using an SDK or whether they're making API calls directly. And the only difference really is we have, when you log into your Auth0 dashboard, you can do a lot of the management tasks there.

You can create clients, get your keys, create new APIs, stuff like that. But there are some additional features that aren't available in the UI dashboard that you can basically activate with the flip of a switch.

Some of those you would have to use the management API directly for, but everything else, when it comes to your application, whether you use the SDK or the API directly, it's the same exact experience.

Brian: So you mentioned, in passing, a couple of times, JavaScript Web Tokens. Can you explain what those are and how important is that to Auth0?

Ado: Sure. Our entire infrastructure, or the way that we want developers to look at security, is through JSON Web Tokens. And what a JSON Web Token is, is essentially, a really long string of characters that means nothing to the end user but contains so much important information when it comes to the identity of the user.

So one way to think about it is if you're building a JavaScript application, or if you're building an application that, whether it's Angular, React, plain old JavaScript, it's going to live entirely in the client.

In the client, you can't have any secrets. You can't have any information that a user shouldn't have, or that a malicious actor shouldn't have, because it's public.

You could try to obfuscate it, you could try to hide it, you can minify your code, but anybody with enough time and enough incentive can decouple your code and kind of understand, if you're trying to hide keys in there or user data that's sensitive.

What a JSON Web Token allows you to do is encode data, or you encode it, but it's also signed. So when a user is authenticated, we'll sign a JSON Web Token and we'll say, "Hey, Brian the user logged in. His name is Brian, and he is user number 1234."

That will be encoded in the JSON Web Token, and that token is going to be stored on the client side in your browser. Traditionally you'll store this token in local storage. You can also store it as a cookie. So in that regard, JSON Web Tokens are not much different from session IDs.

If you've built a traditional web application, when a user logs in, instead of encoding a whole bunch of data on that user, you just encode a single ID, store it in a cookie, and that tells the application that the user is authenticated.

Now, where the difference comes with JSON Web Tokens is they're not specific to a single domain. The traditional way we build applications is we have an API living on one server, our client living on in another, and then we might have a mobile application, we might have an IoT device that all talk to the same API, and trying to do that with cookies, traditional session management, it's very hard, almost impossible.

With JSON Web Tokens, you as the user, and even you as a developer, you don't care where this token was generated, how it was generated. All you care is that a trusted party, whether that's Auth0 or whether that's a server that you stood up that's going to sign these JSON Web Tokens, is providing it and it can be verified by your back end.

Brian: Yeah, that makes a lot of sense. I've done the authentication through cookies in the past. I've actually exploited sites as well who, I guess I shouldn't be talking about this publicly, but exploited sites who also authentication through cookies, like five, six years ago.

I know why you shouldn't do that because I've actually taken advantage of sites that do do that.

But I recently built a site where I was using local storage to pass around secret keys as well, which is probably also a big no.

But I didn't realize that JWT is also not domain-specific as well, because I do make a lot of apps that do need to be on the web, but also in a React Native client, and React Native, if you ever used it, the way you handle local storage or even the idea of cookies is way different.

So you have to change the way you approach things, so having a universal library or a protocol, basically, for it to call JWT makes it a lot easier for that, which I want to point out, too. I actually read the JWT book which is linked somewhere on the web, I'm not sure how I found it. Maybe it's somewhere in Auth0, but it's actually a really good read for anybody who wants to dive deeper into that topic, for sure.

Ado: Yeah, absolutely. The The JWT Handbook was written by one of my colleagues, Sebastian. He really goes into in-depth on what a JSON Web Token actually is, how it works, the different cryptography that makes up how JSON Web Tokens are signed, how they're transmitted, how they're verified.

One thing I do want to point out to the listeners is that a JSON Web Token is signed. It's not encrypted. At Auth0, we actually have a service called JWT.io that you can take any JSON Web Token, just paste in there and be able to read its contents.

JSON Web Tokens, they're not private, they're not encrypted. But what they are is that they are signed by a hashing algorithm like HS256 or RS256. And what this does is it prevents the token from modification. The token is signed with a certain payload with a certain set of data.

If you change even the smallest attribute of that data, instead of "Brian," if you lowercase the B in Brian, then that token is no longer valid. It's not going to be verified by the back end server as a valid token unless it was re-signed again by Auth0 or by a trusted service that had the lowercase B instead of the uppercase B in the word Brian.

Brian: I'm curious about this using JWT, is it .org or .io?

Ado: It's a .io.

Brian: Okay, so if I go there and get a JWT that I have signed, I'm just pasting that and I can see the database on that JWT, or do I have to also provide a signature as well?

Ado: No, you don't have to provide the signature. Basically, what the JWT.io service allows you to do is to see the contents of the JSON Web Token, and then there is a section we have where you can enter a signature to see if that signature can verify the tokens.

If you know what the signature is, you can see that the token was verified. But I guess if you had unlimited amount of time, you can try every possible signature string in the world and try to decode with what password or with what signature this token was signed with.

There are really two ways to sign JSON Web Tokens, two very popular ways. One is with the HS256 signing algorithm, which is basically like a secret key. With this one, basically, when you create the JSON Web Token and you say, "Okay, here's my token. I want to sign it with the password, 'secret'." You shouldn't use a short word like that or a short string like that, but that's usually good enough.

The other way of signing JSON Web Tokens is with RS256, and this is basically a private-public key encryption. We signed a token with a private key, and then you decoded having a public key that was generated from that private key. That's a much more secure way of signing JSON Web Tokens and making sure that they're much more secure and can't be hacked or can't be decoded as easily.

Brian: I have follow-up questions for that, too. Do you guys provide two-factor authentication as part of your identity service?

Ado: Yes, we do. Wanted to build a platform that allows you to manage your entire user identity.

Authentication and authorization are really a means to an end of having a really whole circle, or having the entire identity story figured out.

Authentication, how you login, is one aspect of it, a very important aspect of it. You have authorization, which is making sure that the users have access at the right time. If an admin logs in, they can access admin-level features, if a regular member logs in, they can only access the features that were enabled for them.

But building on top of that is the whole identity aspect and security aspect of it. One of them that you mentioned is two-factor authentication, and we provide this either with our built-in Auth0 Guardian product, or you can use any other two-factor authenticator, like Google Authenticator, Duo Security, or any other platform that provides two-factor authentication, and build it, and basically extend Auth0 with it.

In addition to that, we have a whole suite of features. One of them is our rules extensibility engine that allows you to manage what happens after a user logs in.

When a user successfully authenticates, you can check and see how long has it been since they changed their password. And if it's been a certain amount of time, you can force them to change their password. You can white-list certain domains so users with a Gmail can login, but users without, users with other domains can't.

Another aspect is single sign-on. These days, you have so many different applications that you login. It can be a pain to try to remember all the passwords and you shouldn't use the same password for everything.

We offer a single sign-on for companies that want to integrate it, so that they can have one or many applications, and their users only have to login once, and they'll gain access to all of these various applications.

Brian: Very cool. I wasn't really clear, I'm not sure the listeners are or if this public information, but Auth0, you guys invented this JWT protocol for signatures?

Ado: No, no, no, we didn't invent it. It is an open RFC standard.

The JSON Web Token standard is totally open technology. What we did do, though, is we're helping adopt it and make it much more accessible.

We have over 600 different open source libraries that basically implement what the JSON Web Token standard is, in easy-to-use SDKs that you can use without even using Auth0. So like the node, JSON Web Token libraries, one that we maintain, that we contribute to heavily.

So yeah, we're really trying to drive adoption of JSON Web Tokens, but we did not invent them.

Brian: Okay, yeah, that wasn't actually very clear for me even before our conversation so I'm glad you cleared that up as well.

You guys are doing a very good job driving adoption because I know other libraries and projects that are using this outside of Auth0. But my introduction to JWTs was a couple of years ago when Auth0 was a solution for my project, so that's a good thing to know.

I did want to zoom out real quick too, as a more Auth0 question. How big is the company? And it's only been around for a handful of years, right?

Ado: Yeah, I think we were originally founded in 2013, so we've only been around for about five years now. Since 2013, we've grown to about 260 employees now, and we are still currently hiring.

So if anybody is looking for a job, we're looking for developers, content writers, all sorts of positions, and you can find out all about them at Auth0.com/careers. It's a really, really great company to work for. One of the best that I've been lucky to be a part of.

Brian: And remote-friendly as well, because you're not based in the Bay Area.

Ado: Yes, very remote-friendly. Out of the 260 employees that we have, the vast majority of them work remote. We do have offices in Bellevue, Washington and in Buenos Aires, Argentina. We actually do have an office in London now as well.

These are our gathering spaces where our CEO and our co-founders work out of, and this gives us an office space where everybody can get together and work together, have meetings.

But the company is very remote-friendly. Like me, for example, I work out of Las Vegas, Nevada. So I am almost 100% remote.

Brian: That's awesome. Is there anything else that you want to cover about Auth0 before we transition to JAM Picks?

Ado: One of the biggest questions that I get when folks are asking me about authentication and authorization, and Auth0 specifically is, "How should I login? What's the best way to login?"

For a long time, we at Auth0 had the Lock login widget, which is a React-based application that you just drop into your project, and you can easily have all of the features of Auth0 and control them from the Auth0 dashboard. So if you enable Facebook and GitHub login, the login with Facebook and login with GitHub buttons will show up in Lock.

And for a very long time, this was, and many companies are still using this, but lately we've seen this adopted in a lot of companies, especially companies that are building JAMstack applications, JavaScript applications, is the desire to have a separate login page away from your application. We support this at Auth0.

Basically, what you can do is you just have a login button on your application. The user clicks login, they're redirected to a separate domain, somewhere at Auth0, "Brian.Auth0.com," and the user is logged in there.

And this is kind of a self-contained, secure environment where we can safely collect the user's email and password, or whatever credentials they're using, and then send the user back in the application in a much more secure way than just having, collecting those credentials within your app.

So we support this and we also support a CNAME functionality so you can customize the hosted login page URL. It can be "account.myapplication.com," or ID, or Google does account.google.com. That's one of the big things that we're trying to push people towards.

Brian: Cool, and where can we find out more about that information?

Ado: That is all in our Auth0.com/docs site. All of our Quickstarts have been updated with that terminology and with that reasoning, and you can learn a lot more about why and how this is the way to go for security in 2018 and beyond.

Brian: Cool, sounds good. All right, I'm going to transition us to JAM Picks. These things are things that keep you going, make you excited to work, or just make it be excited not to work. It's a broad scale.

Ado, if you don't mind, I'll go first. Actually, one of my picks was going to be the JWT Handbook. I was going to mention that but it got mentioned naturally in conversation.

My other thing is going to be these things called Turtle Shells. I'm going to have to kind of take off and then land the plane, so bear with me. This whole thing about cryptocurrencies, and I was going to ask, was going to make a joke about Auth0, if you guys are on the blockchain or not. You don't have to tell me if you guys are ICO-ing soon. But I'll be looking for that.

I've been getting really involved in just the whole cryptocurrency space as a spectator, as well as a very, very minimal holder of these crypto coins. And I just recently got into mining as of yesterday.

There's this new coin that showed up on 4chan. I wasn't on 4chan, but I knew somebody who was, who did mention it. 4chan's a very interesting place if you've never been there. Ask your cousin that's in college about it.

But, so this thing called Turtle Shells. So there's been Dogecoin and there's, more recently, there's been Garlicoin, which is based on garlic bread. Dogecoin's based on the Shiba dog.

Now they have Turtle Shells, which are also coins but they're based on turtles. So if you go to turtleturtle.org, it talks all about, it's basically a joke, but it's probably the cleanest code I've seen for getting wallets set up, but also getting involved in mining.

Granted, it also is pretty new, so they were able to make this up at a cleaner fashion, and open source everything like in modern technology, like how you would write code today. So that's mainly the reason why it's a lot easier for me, because I haven't been developing code for that long and know how to read C++.

I can kind of get my way around but they've set up all these makefiles to get stuff started. So within 30 minutes of learning about it, and then five minutes of some makefiles, I've got a mining, my MacBook is a mining rig. Obviously, you can't mine Bitcoin on MacBooks because it takes too much processing power.

Anyway, we don't have to get into all that, but because Turtle Shells are so new, the difficulty is so low that you could actually mine it on your computer right now. Hopefully, by the time this podcast comes out, you can at least make a couple of Turtle Shells a night.

I ran my computer last night for eight hours, and I was able to make 500 Turtle Shells, which was very interesting. I don't think they're going to be very useful ever. But it's got me really interested in the actual code behind this whole cryptocurrency thing. I've been doing a deep dive this morning about how hashing works and how to build your own blockchain in JavaScript.

My second pick would be freeCodeCamp, but actually it does have a link to a tutorial on how to build a blockchain in JavaScript so if you are interested, definitely check that out. Those are all my picks.

I am going to be pennies and pennies rich with these Turtle Shells in the future. So if you don't find me, it's because I'm on some sort of island somewhere, cashing in.

Ado: Well, that's really good to hear. I haven't heard of Turtle Shells before, but I'm a very, very minor player in the whole cryptocurrency thing. I did have a mining rig for a little bit. The thing that turned me off of it was really my computer's fans kept going off 24/7, and it got really annoying, and I wasn't mining enough coins for it to be worth my time.

But at Auth0, we actually did write a series of blog posts, and this was Sebastian again on Ethereum and how it works, and what its future holds with regards to the blockchain and identity. So definitely, if you're interested in cryptocurrency, it's a very good read to at least give you some insight on how it works.

I don't know if identity has a space in the blockchain yet, or has a specific need, but I think it's definitely something to look out for in the future, and if somebody does figure it out, it could be an interesting revelation.

Brian: Yeah, I think someone tried to figure out how to shoehorn it and the speed that these ICOs are coming out and the ideas that are starting to come out, it's almost like the, well, everybody's calling it a bubble.

I know we're transitioning away from Picks and we're kind of waxing poetic, but once you get to the point where now, you're getting all these random ideas based on ICOs, I think we'll hit peak bubble and then maybe, hopefully, the better projects will kind of float to the top on that point. But that's all I'll say about that.

Do you have any any picks that weren't blockchain-related?

Ado: Absolutely, yeah, I mean that I am excited for the future of blockchain and just seeing how it develops. But for my pick, my entire career for the most part, has been in frontend development.

Started off as a frontend dev, and then worked mainly with JavaScript technology: Angular, React, a whole lot of Angular, actually, for better or worse.

Over the last couple of years, I got into more and more full stack development, and Node.js was an obvious choice that I worked with for many years.

I came across Go a couple of years ago, and it has by far been my favorite language to work with.

I don't know if you know a lot about the Go programming language, but it's a language developed by Google, and it's super, super, super fast and really a great programming language.

You can be very, very productive in it in a short amount of time. It's super, super opinionated, so it forces you to actually write code and not spend a whole lot of time figuring out which libraries to bring in, how to structure your code, figure out tabs versus spaces and all of that stuff.

It just really forces you to write code and to build applications which really keeps me focused and I was trying to get a buddy of mine for a long time to give Go a chance and try it. And for the longest time, he's been kind of turned off of it and doesn't see the benefit of it.

So later this year, or in a month or two, I'm hoping to start a blog series called Golang Train. So G-O-lang Train where I'm just going to post a whole bunch of tutorials, and hopefully, get some more people inspired about Go and building Go applications. That's one of my, that's what's keeping me really excited and motivated these days.

Brian: Awesome, yeah, I do have some experience in Go. Netlify, we actually do a lot of open source, as well as our cloud stuff in Go. Our CTO's big into Go, and I've picked up a bit of Go since I've been in Netlify.

I try to do anything that requires scripting, I try to go with Go first just to see what I can do with it, and then I tend to, I don't have any large projects like what you're working on. But I do try to start new projects in Go if I can, and if I can't, then I'll just recede back to JavaScript.

Ado: Awesome, yeah. I mean, Go has been my go-to, I guess, the pun is.

Brian: Yeah, well, everything you try, you learn about Go, it's going to have a pun about going. So no fear there.

Ado: Yeah.

Brian: Well, Ado, thanks for the pick. Thanks for talking about identity and how Auth0 is solving that problem in the JAMstack. Thanks for your time, and listeners, keep spreading the JAM.