On YouTube
197 JSJ Auth0 with Kassandra Perch

02:03 - Kassandra Perch Introduction

02:46 - Auth0

04:10 - Centralized Auth Services: Handing Out User Data to Third Parties

05:32 - Security, Storage, and Compliance

08:48 - Managing Session Data

09:35 - Cookies vs JSON Web Tokens (JWTs)

12:47 - OAuth

14:12 - Identification, Authorization, and Authentication

20:16 - Auth0 Infrastructure

22:10 - Using Node

23:06 - The Backend

24:25 - Documentation and Education

36:42 - The Value of OpenID Connect

38:25 - Identity

Picks

Add AJ on Tri-Force Heroes (AJ)
Making a Murderer (AJ)
Mazie's Girl Scout Digital Cookie Site (Aimee)
React (with Introduction to Flux Architecture) (Aimee)
Jordan Scales: Let’s Make A Webpage In 2016 (Jamison)
building-brooklynjs (Jamison)
Cult of the Party Parrot (Jamison)
CSS-Tricks (Jamison)
Auth0 Docs (Kassandra)
OpenID Foundation (Kassandra)
Mario & Luigi: Paper Jam (Kassandra)

Special Guest: Kassandra Perch.

 

I'm just getting my cat ready. Hold on.

Hello everybody. I am AJ O'Neal and today I am your substitute host on JavaScript Jabber Podcast. It is episode 197 and we are talking today about Auth0. So, I will start by introducing our special guest, Kassandra Perch. Introduction. [Laughter]

Tell us about yourself.

Sure. So, I am a Developer Evangelist for Auth0. I just started there a little while ago. I'm in Austin, Texas. When I'm not doing Auth0 dev evangelism, I'm doing NodeBots and/or crafting and/or video games. So, that's me.

Hey, yay for crafting and for video games and for Hylian Shields.

And then we have of course our regular panelists, Jamison Dance.

Hello.

And Aimee Knight.

Hello.

Alright. And since I am your host today and not a panelist, I won't say yo, yo, yo coming at you live from sunny Utah.

Thanks.

You're welcome. Alright. Should we introduce, what is the purpose of Auth0? What is it about? What do you do? What is the benefit to a person, a developer?

Alright, definitely. So, any developer that's tried to implement OAuth or logins or user management of any kind really, would know that it can be a nightmare. It can be an absolute nightmare. You don't want to get caught storing plain-text passwords. Trying to read the OAuth specification requires a lot more coffee and patience than most people have or would want to drink. And so, what Auth0 does is we offer basically a very easy way to handle user management, user logins, and things like that. The way we do that is we provide a unified sign-on basically. So, you can use Twitter's sign-on. You can use GitHub. You can use a lot of different social providers. Or you can use your existing systems. For instance we support LDAP, XAML, lots of different enterprise solutions.

So, say you're migrating from an older solution to a newer solution you can use Auth0 to bridge the gap. We also offer some user management functionality in the form of rules. So, you can add your own custom rules when someone logs on, say geographical or by username. However really you want to do that. And yeah, we also offer a lot of education through open source and through [inaudible] websites on security. Things like JSON Web Token. Things like OpenID Connect. So yeah, that's what we do.

This is a really interesting topic to me because I feel like building authentication is kind of… it feels like a developer rite of passage where everyone seems like they do it at least once. And some people do it many times. And every time I've done it I'm just like, “Why am I doing this again? [Chuckles] Haven't I done this before? Hasn't someone else done this before who's smarter than me?” So, I'm interested in the idea of centralized auth services. At the same time, it also seems scary to hand over something as sensitive as your auth data and platform to someone else. How do you deal with people who might be reluctant to hand user data over to some third-party like that?

So, we offer a couple of different options in that scenario. So, we are constantly keeping on top of new security. We just got a new certification that I can't remember off the top of my head. And we're constantly striving to be more secure. However if you are a little bit more inclined to keep your data on your own we do offer the ability to keep your user data in your own database, whatever database you'd like. That way it's still yours. It's on your site and you have more control over it. So, there's a couple of different ways we approach that. We try to be as secure as possible but for those who really would like to keep their data on their side we do offer on-site and we do offer allowing you to use your own database.

So, I have a particular interest in security. So, I am curious to know what security measures do you use or what type of things have you specifically avoided? I'll just start with those two questions but I'll probably have some other ones.

Yeah. I can't speak too much to avoidance. I'm still kind of new so I'm still kind of learning about the deep technical history of the company. But what I can say is one of the ways we avoid security issues in general is by educating not only our users but the general public about new security techniques. Our blog is very active on new security breaches and not only what happened but how they could be prevented.

We also do a lot of educational work with JSON Web Tokens, OpenID Connect, all the specifications that are going around about these layers of authentication. And I feel that when we educate the public and developers on how these technologies work we close a lot of the loopholes that cause security issues, especially when it comes to education on social engineering which is one of the more effective ways to get data out of a company. So, I think education is one of our more proactive tools for security. As for technical, like I said before we strive to get as many security certifications as we can to basically show that yeah, your data is safe with us.

Okay. So, one of the reasons that I would want to use a service like Auth0 would be because I don't want to become educated, right? Like, I don't want to have to learn the difference between PBKDF2 and decrypt and scrypt and…

Right.

When to use which. I want to offload that knowledge and expertise to you. So, that's something I'm interested in. Do you know which practices you've used to safeguard things like passwords? Is it PCI compliant? Is it HIPAA compliant? Basically what does it enable me to do if I offload all of that security headache to you? If I just offload the whole thing. I don't want to do self-hosted. I just want to say, “Take it and let me know what I'm legally allowed to do now that I'm using you instead.”

Right. So, we just received our SOC 2 certification so we can speak to SOC. We are SOC 2 certified. I cannot speak to our HIPAA compliance at the moment. I need to ask someone else about that. But what I can say is we do encrypt all our traffic and all of the data is stored in Auth0 is heavily encrypted, yeah. That's pretty much what I can get to at this point. And that we are certified to store your data. But as for HIPAA, can't speak to that right now.

Okay. But yeah, if you're SOC compliant, you're probably… because you're only… you don't store arbitrary data. Or do you? It's just like authentication and permission data, right?

So, the authentication data we store, to be fair, we only store Auth0 users and passwords. Twitter and social providers, we don't store usernames and passwords for those. We simply store who's logged in through those Auth0 providers. We do store some arbitrary data in the form of rules. So, if you program a rule for your users, we do store that data for you. You can add arbitrary fields to Auth0 users. So, those would be stored. But we don't store third-party user data from the social providers that we use. We use their APIs but we don't store their data.

Okay.

I have a totally unrelated question. I mean it's related to Auth0 so I guess it's technically related. Do you also manage the session data like to tell if a user is currently logged in? Or do you have to call back to the application somehow to handle that?

What we do is we provide a JSON Web Token that basically represents that user's authentication. And it has an expiry date or an expiry timestamp or an expiry… basically, yeah an expiry timestamp. And so, your app needs to handle whether that JWT has expired or not. We simply provide the means to check, “Hey is this token expired?” When you use Auth0 it will give you an error if a token is expired. And you can revoke tokens manually from Auth0's dashboard. But as for refreshing tokens, things like that, and actual session data, your app would need to handle that.

Okay. That makes sense.

Before we go too deep, can you talk about the difference between cookies and JSON Web Tokens? Or I guess a lot of people call them 'jawts' or JWTs.

Right. So, cookies are a method of storage whereas JWT, you're probably thinking like the session data stored in a cookie. You can actually store a JWT in a cookie. What a JWT is, it's a method for encrypting data and sending data safely. So, a JWT is simply a self-contained token containing the information that you're trying to send back. In this case, for Auth0 it's usually user authentication data or user data. And it consists of the meta information about the token itself, the information that's encrypted, and then at the end a way of checking to make sure that that data once encrypted is valid. So, the JWT itself is actually just a token of information. Whereas you can store it in a cookie. Some people use headers, et cetera.

You know what? It might actually be good to get just an overview of how authentication works in general because there are a lot of terms. And I still get confused honestly about the flow of authentication. Can you talk about that? Just how authentication in general works?

Sure. From an OAuth perspective, what happens in your app is let's say you want to allow someone to login using their Twitter account, this is when you would implement something like OAuth. What you do is you actually send the user to the originator, the provider, the provider's site to actually login. And they login on the provider's site. And then what the provider sends you back is the information from the authenticated user. Basically a permission slip saying, “Yes, this person has logged in on my provider's site.” And this is either an API token or just information about that user that you can then use.

When you login straight with Auth0 what you do is you give us your Auth0 username and password. And we check to make sure [chuckles] that that's the correct information and then send you back that same authentication token. So, it really depends on whether you're using OAuth, using another provider or using a [straight] provider.

When I'm using Auth0 and I want to use Twitter, am I still handling Twitter myself or am I giving you my Twitter app credentials and then you handle Twitter and wrap it as a JWT?

The latter. You'll give us your app credentials and then that's how we allow your app to login, users of your app to login via Twitter. We handle the OAuth layer for you. All you would need to do is put lock on your site or your own UI for logging in on your site and then basically on your backend all you need to do is check that JWT is valid to your Auth0 account. So, you would not have to touch Twitter other than getting your app ID or secret and putting them into our dashboard and configuring that provider.

I wonder, how many person hours have been lost trying to set up OAuth with Twitter or Facebook or GitHub or something like that? It just seems like everyone does it and it's a pain in the butt for everyone.

For Node users it's kind of nice now. Passport kind of made that a lot easier for at least Node developers. And it's really nice. The person who created Passport works for Auth0. And so, I've learned a lot about how Passport works. But yeah, without tools like Passport and without a lot of help from the open source community [chuckles] implementing any authentication platform can be a nightmare.

So, what is the… it sounds like primarily what you're trying to do is create an OAuth endpoint and wrap different services that either use OAuth or that don't use OAuth, like LDAP doesn't use OAuth, and you want to expose them as OAuth. Tell us a little bit, what is OAuth and what is the advantage of OAuth to whatever not OAuth is?

What OAuth is, is a way to authenticate a third-party identity provider, which in this case should be Twitter, GitHub, or Facebook, allowing you to use that third-party identification provider. So, OAuth is essentially what allows us to login to other sites with credentials from any social provider or GitHub. And so, that's the layer that OAuth gives. We actually use OpenID Connect on top of OAuth.

So, a lot of people use OAuth for more than just authentication. They use it for identification. OAuth was not written with that in mind. That's kind of what OpenID Connect was written for. And so, they kind of work together. And so, we use OpenID Connect to do the identification. And yes, we do a lot of OAuth work to basically make it seem like one unified login. We're very good at single signon. And we're very good at creating a unified experience no matter your identity provider, be it a social network or an LDAP server on the enterprise side, or even just Auth0 usernames and passwords.

So, tell me a little bit more about the distinction. Because we've got a couple of different words we're throwing around. And help me add to this list if it's incomplete. But it sounds like we have identification, authentication, authorization.

Yes. So, authentication and authorization kind of work together. So, you use your authentication to prove you are authorized to do something. Actually, all three of them really work together. So, you are authorizing an application to do something when you are logged in and you complete something. An application is authorizing you to do things when you login for instance. It is authorizing you access to the app when you give it your correct username and password.

Identification is usually what's returned upon initial authorization, that initial login.

Your identification is your user roles, your permissions, your user name, any information about you. That's your identification. So, you authorize against a login screen. It usually provides back an identification, your identification. And you use that to prove you are authorized to do other things around the site. For instance, only logged in users can view this post or make a comment or things like that. You are being… asking for authorization to do those things.

So, authorization is kind of like the permissions part and authentication is like, “Who are you?””

Mmhmm, yes.

Well, it makes sense.

Prove that you are who you say you are.

Yes, that's the initial authorization, authentication. Actually, that's where that comes in, is that you're authenticating yourself.

And I would say that the 'prove you are who you say you are' is essentially 'I say I am user X1MK47653 and I want to prove that I'm whatever I just said'.

Right. You provide you, yeah.

As opposed to, I know one of the dangers early on with OAuth was that a lot of OAuth providers would store something like an email address and then people would assume that because the email address was listed as a property, that that meant that that user owned that email address, which was not necessarily the case. I think most providers that expose an email address nowadays provides some sort of 'we checked this ourselves to make sure first'. But there are parts that I think the average person thinks of an email address as part of an identity. But it isn't unless it's explicitly listed as part of the identity.

Right.

Can you talk a little bit about how authentication works in the world where a lot more with the logic is happening in the browser in JavaScript? It seems like there might be a different model. Or maybe it's the same model. I don't know. But it seems like things could be different when your application lives so much more on the client. And that might change how you deal with security things and stuff like that.

There's a little bit. That's mostly the move away from cookie-based authentication, cookie-based identity, and into a token-based identity, is the fact that not all apps refresh. Every time you click a page, not all apps refresh even when you click login. We're sending tokens back and forth instead of cookies. And while there are a few implementation details that are different on Auth0's end, that's one of the reasons we make Auth0 try to be a unified UI, is whether you're developing a single-page application or a mobile app, or a traditional I guess is what you call it web application, we try to make that experience similar through all platforms with Auth0, at least for your users. Implementation of course for a Swift app versus a single-page JavaScript application would be quite different. But we try to at least provide a unified experience for the users.

Sure, that makes sense.

So, on that note there's one problem that I found particularly troubling and I'd like to hear if you guys have any unique suggestions that you know of about this. But when you have a desktop app or a mobile app, you obviously can't include the client secret because anything that is on a person's device that they have in their hand is something that they could root and discover and use. So, the problem of identifying whether or not a client is an official client or a rogue client seems to be, as far as I can tell unsolvable. Do you guys know or do you know if you guys have any sort of tips or tricks to help with that problem? It's okay if you don't. I mean it's…

Yeah.

Can you lay out the problem again?

Yeah, that's what I going to ask. [Chuckles]

Okay. So, if I have a mobile app on my phone that I've created, there's not really a way for me to tell if the application that is connecting to my server is my mobile app or if it isn't, because anybody can open up the Android APK and take the client ID. And if I had the client secret which would be a terrible thing to include in a mobile or desktop app, but if it was there anybody can open up the APK or just use strings from the command line to look through the binary and find the application ID that's in the code and then use that to spoof that client.

Right. I can't think of anything off the top of my head that we've done that could scratch this problem. Because yeah, if you've got someone who has access to the binaries of your APK you're kind of out in the wind on that one. I mean if they can search your binary, they can find your client secret. And they call it a secret because we don't want to spread it. [Laughs] So, [inaudible] I can think of off the top of my head, yeah.

And I just move divs around on a page. Don't ask me these questions. [Laughs]

Oh no, I mean I'm learning more about security to be fair. I came into this [inaudible].

Oh, I should… yeah, I wish I knew more. But I don't know a ton. And security is scary enough that not being and expert makes me feel like I just should never say anything about it because it's so easy to ruin my life.

I hear you. Security's definitely a scary thing.

This is why Auth0 exists, right?

[Laughs] Sounds about right.

So, I did read… this is changing topics a little bit. But I did read an interesting blog post about your infrastructure. And then I also know that you guys do a lot with Node. I don't know if that's something that you could talk to, specifically some of the stuff that I've been reading on my own for work is about this thing called Chaos Monkey that Netflix uses. And I know in this article that I read about Auth0 they have their own implementation of that. Because obviously with this authentication, authorization, it's vital to a business that users can login and use your service. So, I'm not sure if you would want to talk to that at all if you're able to.

Sure. What I've learned about our infrastructure is yes, we're using a lot of… we're building a lot of our own tools. And we're doing a lot of interesting things with them. Yes, we do have a version of Chaos Monkey. And we do use it to make sure that yes, that our service is available as much as possible. I've only just started working with that tool. So, I'm kind of learning the ropes of it myself. I can also speak to the fact that we are doing a lot of really interesting things with sandboxing and running third-party code safely.

So for instance, our rules engine that you write, when you want to write a rule to say, “If these users are in this geographical location do this, otherwise do something else,” what we're doing is we're actually taking third-party JavaScript code and we are running it. Which sounds terrifying. But the way we worked it out with our infrastructure is we do sandboxing with Docker and CoreOS. And we basically create, we literally… well, not literally… we very metaphorically build a sandbox in which you can run this code that does not impact the rest of the site. It's similar with a lot of our tools. Our tools are based on micro-machines. We want as many little machines running as possible to get things done instead of a monolithic machine that if it goes down, it goes down. And that's why we've built some of our own tools to test that infrastructure.

I know that you guys do a lot with Node. Can you at all speak to why Node is a good choice since this is a JavaScript podcast, for implementing authorization, authentication?

Yeah, I can actually. So, authentication is essentially a feature of the web, or at least the internet itself. You are constantly, you are connected to the internet in any way, shape, or form is how you authenticate yourself. And JavaScript being the language of the web, being the language of the internet, I think it can speak to the fact that that's how we made our platform so ubiquitous. Yes, we cover many backends that aren't JavaScript but we have Lock, we have a ton of web tools, and I think that speaks to a lot of the reasons that we're behind Node and JS is because a lot of us are web developers and a lot of web developers use our products. And so, JavaScript seems like a language that universally reaches a lot of our users.

Speaking of JavaScript and not Node in this case, there is a way with Auth0 to basically have no backend code myself. Like if I just want to host pages on GitHub Pages, I can do that with Auth0, right?

Yes. Lock is available without any backend required. You can drop Lock HTML and our Lock.js script into any frontend page and you will have authorization via Auth0. If you don't want to build a

full backend as well we do offer Firebase as an add-on. You can just, you enter your Firebase keys in. So, if you want to go a little further than just users but you don't want to build your own backend we do offer integration with Firebase services as well.

I would love a link to how to use Auth0 with Firebase authentication in the show notes.

I can totally add that. We just…

Please link to that.

We just went over that documentation again. And so, it should be up to date. And I'll make sure to send you that.

Thanks, yeah. Because I think they changed it within the past six months or so since the last time I'd used it and played with it. And so, I wasn't able to use the code that worked previously.

Yeah.

I'm still getting used to the new Firebase myself. But I like the changes they made. They just took some getting used to for sure.

So, are there any things that we should be talking about, about Auth0 that we haven't hit on yet?

I take a lot of pride in our documentation. And I mentioned education before and open source software. I've mentioned all of these. And these are definitely at the core of our values at Auth0. A lot of our work is open sourced. And we do take a lot of pride in education. One of my first tasks coming onboard was to create a screencast for JSON Web Tokens for our informational site to show users, “This is how you implement a JSON Web Token. This is what it is and why you would want to use it.” So, I definitely think if you're nervous about trying Auth0 or it seems a little complicated or it seems like something that may not even be something you could do, definitely check it out. Lock is a drop in and go sort of situation. The documentation, we even include steps for how to get third-party keys. What menus to go through, what to click through, even if it's not our site. We keep those up to date as well.

That's nice, because like…

Anybody who's ever developed with Facebook before has seen this problem over and over again where you go to the Facebook tutorials and because they change the interface every six months, the button's in a completely different place.

Mmhmm, definitely. And so, I think that's one of the places where we really shine, is developer experience. We make sure our documentation… one thing that's really neat is if you go into any of the quick starts which you get to by clicking documentation and you'll see the quick start, you click a frontend and a backend and you can click download seed project. And you will have in your downloads folder a nice little project that's ready to go with Lock, with JWT. And it's got your client ID auto-populated in there. And so really, you just run it and go.

And you now have a basic app that you can tear apart and see, okay what actual moving parts. If you're not one for reading lengthy documentation and you just kind of want to jump in the code you can download that seed project that's generated for you and rip apart that code instead of walking through the docs. I take great pride in the developer experience that my team has built and that I will be contributing to for the foreseeable future.

That's awesome.

So, I think the topic of documentation is really interesting. It sounds like you have a dedicated team focused to it. Is that correct?

We do have technical writers. And our engineers do take time to check the documentation. I also work on… I think basically at Auth0 it's just about everybody's job to make sure that the documentation is up to date and friendly. So yeah, I think it's one of our core tenants is if it's not documented something's gone wrong. We need it documented immediately. I don't think I've seen anything launched from Auth0 without thorough documentation ready to go along with it, which is something that not every [chuckles] not every service provider can hold up to.

Yeah. I was going to ask about that. If that's your goal how do you coordinate that into your deploy process or something?

First of all at least what I've found from working there is we make editing the documentation very easy. Pull request to master and it goes up. You don't have to worry about contacting 50 people to get the docs updated. Another thing is we do communicate very, very often. We are… a lot of us are remote. We do have offices in Buenos Aires and Belleview. But I'm remote. I'm in Texas. And we have quite a few remote engineers. And so, I think communication which it sounds like a handwavy response but really communication is one of the more difficult parts. And so, while it seems like a hand-wavy response it's one of the most difficult things to implement in reality, [chuckles] is getting engineers and everyone in a company to communicate.

I know from some experience that I feel like if documentation isn't a priority it can lag behind because if you're so focused on building the stuff it can almost feel like, “Well, we don't have time to write it down because that will slow us down and it'll delay the feature getting out.” So, it just kind of sounds like you are aware of that time and you make the investment upfront. Is that correct?

Yeah. That's pretty much what we do, at least for everything I've done here. It's a mandatory part of the minimum viable product to ship with documentation. And it makes a lot of sense considering what we do is if it's not usable by developers, have we really done anything? If an API falls in the woods and a dev can't use it, does it really exist? [Chuckles]

Yeah.

So, yeah.

So, on the topic of documentation I know for me as someone that's still learning a lot I actually look to Auth0 for a lot of your different blog posts and stuff. You do a lot not just about security but a lot of the different technologies coming out. And I love… there are like these little short, like you can read them in five minutes blog posts. And you're just pumping them out constantly. So, I'm kind of curious. I guess my question is, is this like a side-effect of something or is this a strategic thing that you guys are choosing to do to try to help out the community? I just, I've gotten a lot of value out of these little blog posts.

I think it's a mix of both. It's a passion that we curate, is the way I think I'd phrase it. So, we have a very wonderful team here that really likes to learn about these new things and then write about them. And it's great. We like to curate the blog and make sure that it's active. But it's not hard when we've got very interested people writing blog posts like the ones you mentioned, especially the shorter ones about a new topic or a new technology. So yeah, I think the best way to describe it is the passion that we curate.

Well, if we don't have any other questions I think we've covered the topic pretty thoroughly. And so, if we don't have any other questions we can move onto the picks. I got some picks and I'll go first.

So first of all, if you are like Sandra and I, then you are a Zelda fan which means that you probably got yourself Tri Force Heroes for Christmas or had someone close to you get that for you for Christmas. And if so, you should totally click on the little link in the show notes that goes to my tweet where I'm asking people to let me know their friend code so that I can add them and we can play together. Because I don't have any adult friends that waste time on video games near me.

Yet.

Yes, yet. And I want some of those. And I'm always afraid that I'm playing with 13-year-old girls and that just makes me feel a little uncomfortable. So anyway… [Laughter]

Well, it doesn't… Tri Force Heroes is like definitely a Zelda that is more geared towards women anyway. So, there's like, the Link character can wear dresses and also some of the emoticons for in-game game play just seem very feminine. And so, even when you're playing with men, if you don't know for sure it just feels like you're playing with women. Because sometimes you have to wear a particular dress to get a particular power up type thing. And you're sending these signals to people like good job and there are pom-poms cheering and stuff like that. So, you feel like you're in an anime.

Anyway, I'll also pick Making a Murderer which is a Netflix series which is very… if you liked Serial and Undisclosed, if you've listened to those podcasts then you will like Making a Murderer because it is about a false conviction that was later exposed as false. And then the person who was convicted for the one crime he didn't commit was then, the evidence seems to suggest framed for another crime that he didn't commit and then put back in prison again. So, it's just, if you like that kind of thing then you'll like it. And those are my picks.

Aimee, do you want to go?

Sure, I'll go next. So, I have a couple here. My first pick, I want to pick Mandy. I guess her daughter is selling Girl Scout cookies. And as a former Girl Scout I know how important it is to sell a lot of cookies. So, I'm going to put a link in the show notes to hopefully help her daughter sell tons of cookies. So, if you want Girl Scout cookies you should go order them from Mandy who puts together all these episodes. You should go order cookies from her daughter. So, that is my first pick. [Chuckles]

And then my second pick, I had a long weekend. So, I started digging more into React. And I really enjoyed the Frontend Masters course by Ryan Florence. It was just awesome. Super easy to follow. He's live-coding the whole time so I got a lot of value out of it. I can't say enough about it and I am really excited. I'm starting to jump on the bandwagon. [Chuckles] Before work this morning I was building something and staying up late building something. And yeah, I'm hooked now. Anyway [chuckles] so that is my second pick.

And a third pick that's kind of funny is AJ's birds that he's been making with his hands during the episode. I really like those. I think that's a bird. I'm not sure what it is.

That's a turtle.

Is it a turtle? Okay.

Yeah.

It looks like a bird. I don't know. But it's…

Well, because it's sign language. So, this is awkward and then this is turtle.

And I don't know if that's just like a Provo pop culture thing or what, but whenever there's a long silence or a pause people will do this little turtle symbol or the awkward turtle symbol.

Could be that I spent too many years on the ice and not enough time in the halls of high school.

Anyways, that is all for me. [Laughs]

Cool. Well, I've got a hankering for cookies now.

And then Jamison, since you are so ready, so ready.

I'm super ready for picks. I have four picks today. First one is a blog post by Jordan Scales who's this engineer. He works at Khan Academy I think. I have an internet crush on him because he posts a lot of really funny stuff. He wrote a blog post called 'Let's Make a Website in 2016'. It's just like making fun of the whole JavaScript tooling fatigue thing. But in a really nice way. If you're so mad a JavaScript you'll read it and think it's hilarious. If you love JavaScript you'll still read it and think it's hilarious. It's pretty great.

My next pick is a blog post. I think it's a write-up of a talk that he gave by Jed Schmidt called Building BrooklynJS where he talks about basically the BrooklynJS community and all the work he put into making it one of the best meetups. It sounds pretty amazing. And it's cool to hear how he went about approaching it.

My third pick is just a web page called Cult of the Party Parrot. Party Parrot is a GIF of a parrot that is partying. And it has invaded Slack. It's probably 20% of the words I type in Slack. [Chuckles] And Cult of the Party Parrot has even more Party Parrot.

And then my last pick is just CSS-Tricks. Anytime I want to find something out about CSS, CSSTricks has up to date and really clear documentation on it. And I really appreciate that. I struggled for a long time to learn CSS because I couldn't find a good place to learn it. And I think I found it with CSS-Tricks.

Those are my picks.

And then Cassandra.

Yeah. So, my first pick because we've talked about it a lot today and I'm always proud of this, would be the Auth0 documentation. If you'd like to learn more about Auth0, Auth0.com/docs.

My second pick, you know I've really been interested in OpenID Connect. So, there's actually a really great informative page that's popped up, OpenID.net. And if you want to learn more, you don't have to read the specification. It's not just a link to the specification. It's more of like an exploratory site.

Paper Jam coming out on the 22nd, like super excited about that. So, I guess that'd be my third pick. And I think that's what I've got.

I think yeah, that's my list of picks. Yeah, those three things.

That Mario & Luigi one looks solid.

It's going to be great. If you like the RPG Mario and Luigi games it combines… it's a sequel to Paper Mario RPG and the last Super Mario RPG. I'm super excited.

Cool. Well, before we end I actually want to ask you one more question. So OpenID Connect, from what I get from it, it's like OAuth 2 is a framework for building frameworks whereas OpenID Connect is like a framework, not a framework of frameworks, right? Or how would you explain the difference between what the value add of OpenID Connect is?

Yeah. So, basically OpenID Connect… Auth0 allows you to do one-to-one. So, one third-party provider of identity or authentication to one application. What OpenID Connect provides, the way they phrase it is it answers the question what is the identity of the person currently using the browser or native app that's connected to me? It's more of a one-to-many. So, you have one identity that OpenID Connect manages and it logs into any app that supports OpenID Connect. Whereas OAuth is much more one-to-one. Though yes, that's also a good way of putting it is that OAuth is a framework of frameworks and OpenID is, it's a lot more…

It's implementable

Yes. It's much more implementable. It's much more usable. But it also, it solves a bigger version. I call it an updated version of the OAuth problem. So, instead of saying I just want Twitter users to be able to login to my application, what OpenID Connect solves is I want this person to be able to login to my application and it doesn't matter if they also use that identity on this site or that site or the other or whatever site. I just want to be able to use that global identity. It reminds me a lot of the Mozilla Persona push. It reminds me a lot of that except instead of just one implementation of it, it's a specification that you can then implement against.

So, help me understand, because it sound like the one-to-many would be like I own my identity myself. And then I would like the publishing my identity to multiple locations.

Mmhmm.

But how does that work? Because how would I have my own identity? Because on one device it could generate a key pair or a secret or something. But that would stay on the device. How would it associate my own identity with multiple devices and multiple providers?

Right. So, it's similar to the way OAuth works in that respect. So, when you login to Twitter for another application when you're using OAuth, Twitter responds with, “Okay, I'm going to allow this application to see these parts of your Twitter profile,” right? And so, when you're using OpenID Connect what you're doing is you're creating that identity for that website. But you can use that identity in any website that has OpenID Connect.

So, where is the identity being created?

The identity is being created in each app. So, in order to share data between apps they would still need to talk to each other. Basically it really creates a unified experience for the user. And you can still silo off an OpenID Connect to yourself. If you're just saying I want to implement OpenID Connect for my app but I don't want any other OpenID Connect identities to login to my application. You can say that. It's similar to Auth0 in that respect, or OAuth in that respect. If your app has OAuth but you don't allow Twitter's OAuth tokens, you don't allow Facebook, you don't want anybody's, that identity still only exists on your app.

Cool.

Thank you so much for coming, Kassandra.

No problem. Thank you for having me.