#292: Pythonic identity (auth in Python ecosystem) Transcript

00:00 So you're excited about that next app you're about to build, you can visualize the API's with smooth scalability, talking to the mobile apps, you can see Finally, this time, you'll get deployment, right? And it'll be pure, continuous delivery to GitHub with zero downtime, but you're probably not dreaming about is writing yet another password reset form, in integrating the mail capabilities just to send those reset emails, or how you'll securely store user accounts the right way this time. Don't worry, we got you covered. Our guests. Christos mascus and john Patrick Dennison, are here to cover a bunch of different libraries and techniques we can use for adding identity to our Python applications. This is talk Python to me, Episode 292, recorded Friday, October 2 2020.

00:58 Welcome to talk Python to me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy, follow me on Twitter, where I'm at m Kennedy, and keep up with the show and listen to past episodes at talk python.fm and follow the show on Twitter via at talk Python. This episode is brought to you by linode and Talk Python Training. Please check out the offers during their segments, it really helps support the show. Here's an unexpected question for you. Are you a C# or dotnet developer getting into Python? Do you work at a company that used to be a Microsoft shop, but is now finding their way over to the Python space. We built a Python course tailor made for you and your team. It's called Python for the dotnet developer. This 10 hour course takes all the features of C# and dotnet that you think you couldn't live without Entity Framework, lambda expressions, ASP. net and so on. And it teaches you the Python equivalent for each and every one of those. This is definitely the fastest and clearest path from C# to Python. Learn more at talkpython.fm/dotnet. That's talk Python, FM slash d o t n et Christos john, welcome to talk Python to me. It's nice to be here. Thanks for having us. Yeah, it's great to have you guys here. We're going to talk about identity at all the different levels. And I think that's something we really haven't covered that deeply on the show not in a standalone sense anyway. And so I'm looking forward to covering these topics. Because we've got some interesting and strong opinions about different things that we're going to cover. And it's going to be a lot of fun. I can tell already.

02:32 Hey, we're open. We're open to all and every opinion here, right? We just want to make sure that people are doing it safely and right. What if they're building apps? Right? So yeah, that's our goal. That's right. Yeah. So let's start with the beginning with setting stage just personally, for you to Christos, I guess we'll start with you first, how did you get into programming? And then how do you find your way over to being interested in Python at least as part of the one of the languages? You're right? That is correct. So it's funny because I was thinking back how I started with programming. And I was saying yesterday that I actually want to be a hiker. At some point in my life, the crossroads of what do I want to do? I think it was the 10th, the age of 20, or 21. I was like, What do I want to do with my life, I can choose anything I want. I want to be a hiker. So I'd like to be a hiker get into you know how to write code. So I was like, Okay, I'll go and get the green coating. So I did a software engineering degree. And then I thought, you know what, if you want to be a good hiker, you need to know about networking. So I want to do the networking degree, and designing TCP stacks, OSI and what have you. And then I went back to programming because I fell in love with it. Initially, I became a dotnet fanboy from the early days, because I did that in uni, and then the market was ripe for that. So I ended working with that stock for very long. So since 2004, I've been writing code in dotnet. But over the years, I worked as a consultant. So I got the chance to dabble with Python know Java. And that polyglot experience brought some interesting bits, like, Oh, I like this bit from node i like this bit from Python. dotnet doesn't do everything, then dotnet core came around. So I fell in love with dotnet core again, and pulled me back into the dotnet ecosystem. And then I joined Microsoft in 2016, working as a consultant helping customers. And since March, I moved into the identity be more I work as a program manager for the developer advocacy team. And this gives me the opportunity to actually go and play around with all the languages and see how we can integrate identity into these things securely and with scale. And that's where we are today. Yeah, super cool. And I think one of the things that's really interesting, this whole evangelism side is you get to touch a bunch of different technologies and identity, you get to talk about a bunch of different technologies. This node app wants to talk to that Python API back in. Yeah. So it's, you really kind of got to embrace that full time, right? And every platform and every language so we're not locked into a specific ecosystem. We can speak to AWS developers who speak to Google develop

05:00 As we speak to these, the lotion developers, as we mentioned before, for us, it's about making sure that you have the right tools in your arsenal to write the code using the tools that you love and the language that you love. All right, I can't let you get off this topic here. The origin story without asking you about Mr. Robot. Oh, God, I love it. My background right now on my windows terminal is Mr. Robot. Oh, my gosh, Aziz. misters JPS, who's gonna be talking in a second? And the other background because I have multiple terminals. The other one is Halt and Catch fire, which is my second favorite TV show. If you haven't watched it, it's a fantastic TV show. Oh, yeah. I would say Mr. Robot, for those of you who have not watched this, like it gets a little weird. And Season Two and season three. But season one. This is I would say it's probably the absolute best, like dramatic representation of programming. And software in a show is not one of these vague things like you really feel like I think there's a whole section where they're using Python to write some Python code. Yeah. That's legit code on the screen. That's not like weird green text falling down or something. Right. Like, actually, it's super accurate. And there are lots of people in the tech industry that love that show that spent time looking at the commands that they write, to analyze whether it's valid code or not, whereas other shows, I don't know. I mean, the best one was NCIS. Was it where two people jump on the keyboard? Yeah, it was at the VBA. One, the VB one? Yeah, the very first one where they were like, oh, some of these are liking us. And the two people jump on the keyboard trying to type at the same time. Well, the same people.

06:33 Oh, that hurts. That's not the pair program we were thinking of.

06:38 All right, john, how about you? How did you get into programming by the so I started, I was always sort of into computers and building stuff. And I was a kid. And so I thought, oh, I'll go to college for something I want to do, which is music education, because I wanted to be a band director. So we see which we see Oh, well, that worked out. I. So I went to college. And I took a bunch of programming classes, and most of my programming classes were actually in Python. When I was starting out before they moved into Java. I'm super jealous. They said I had to do it all in Lisp, Fortran, what?

07:10 Them effects.

07:12 Python and then Java. That makes sense. I mean, I think honestly, studying a static language is super important, even if you don't necessarily embrace it, but Java, C++, C#, like, you should know that stuff, even if you don't necessarily do it day to day. Yeah, yeah. And then while I was in college, I found a job on Help Desk and one of their developers left and they said, Hey, do you wanna come help and take over? And I said, I guess I've no idea what I'm doing. But I'll try. And so my first project for better for worse was a, an online banking app that was written in C#, and I was like, you guys sure you want me to build this? I was like, 20. That's so interesting. Like, I remember the first time I wrote a credit card processing, I was like, paranoid, I, I had a hard time, you know, being relaxed. I'm like, What if I get it wrong? What if I charge them like $10,000 $100. But we're supposed to take I thought it took sense. And it took dollars, like it was really nerve racking. And that's a hard first project, what it was me and one other guy, and he had a lot of he was a 1520 year, guys, so but I would ask him questions. And he was just like, yeah, now that sounds fine. I thought, you seem very relaxed about this whole thing. And it was a, it was a, it was an app for high net worth individuals to go and manage their insurance accounts. So I guess there weren't like, there were like transactions necessarily happening. But you could reinvest your life insurance policy and stuff. I mean, it was, I was terrified. Every day I went to work. And we, this guy, we hired a guy consultant to come in and help. And my boss said, well, you're 20, so you're not going to get your own office. And he's a consultant, and he's not going to get his own office. So you two are going to share an office. And so I sat at the desk with a tower of Mountain Dew cans in between me and him. And he would poke out once a day. And he go up and write a concept on the board. Like, you need to go learn about, you know, interfaces, and C#, and I said, Okay, I'd go figure it out and learn about him. It's come back a couple days later and say, okay, but it was, it was really interesting. It was sort of a trial by fire. And then I started working, you know, doing enterprise dev at different places. And then I got really into Azure about 10 years ago, and built an app with a friend. I told Christos, I don't know if you can still call it a startup, what it's nine years old, but I guess it's still in the startup because it makes about as much money as a startup. I was actually thinking about that. Just the other day, I saw headlines like when does a startup stop becoming a startup? It's odd that that label like it's applied to it? Yeah, I feel like people almost consider Facebook and these types of places a startup like this is not a startup.

09:33 So let me just ask you. My theory is basically when you stop accepting VC money, it's not a startup. And maybe it might not be a startup, when even when it's small. If it doesn't have like some of these attributes, like high growth, sort of user growth over profit or profitability, and feel like there's some sort of, yeah, cat like metric you can say like this world makes these attributes make it a startup, not just a small business.

10:00 Or at large business? I don't know. What do you think? Yeah. Well, it by that definition, let's see growth over profit VC monies. We've had none of those things.

10:11 Exactly. But I think we call it we used to call it a startup because it was only two of us. And it was technology focused is all about it was actually it was a proxy. Yeah, I think it qualifies. Sorry, for the diversion. That's okay. But I learned a whole lot, I learned a whole lot because I was building software outside of work. And it was, I think, for me, when we had people start paying to use it, it was sort of like the light bulb went off of like, hey, maybe I should like maybe this is it, maybe I do have some talent here. And I should do this more often. Yeah, it's kind of like an external validation, which was cool. And started doing cloud consulting for people too. So I worked for a consulting firm, and we would go to customers that wanted to use Azure, or were interested in it and say, Hey, this is how you use it. And these are ways to get started. And here's how you design apps that are going to scale to one node or 5000 nodes and, and a lot of patterns, and how do you deal with consistency and data, that sort of thing in a cloud environment. Of course, back then, it was the Wild West, we had some customers using AWS, we had some customers using us an Azure, we had some customers that were calling Rackspace cloud, which that's cool, because back then they were about the only other thing out there. And then I came to Microsoft, I did pretty much the same thing, but focus on Azure. And a few months ago, right around the same time, Christos did join the identity team for helping developers understand identity, I think because as a developer myself, I know that I didn't care about identity until I started using it and realized, oh, if I don't have to deal with this on my own, I'm sold. I don't want to do this, I'm sort of was what I wanted to do. Yeah. And then seeing how many projects got completely sidetracked and blocked and had so many issues with identity. Because, you know, we have a sort of a funny saying that we hear people say around our division of we've talked to identity developers was like, well, 1500 identity developers in the world work for us, because they care about identity, they want to build an identity system. Most of our customers don't want to build an identity system, they want to build an app and identity is the third checkbox in the list that they want to check off and get back to the other 200 tasks they have to do. Yeah, as well. It's one of those things that you have this idea, like I really want to build this thing, it will be amazing. And nobody ever goes. And I want to have a super cool login. Or I want to have a really fantastic secure header exchange with my API. Like, nobody wants that. But you can't release the thing without an account and identity and or some sort of authentication. Right. And it's, it's also you talked about being nervous around the banking stuff, and so did I rightly so. But this is another one that will make you a little uncomfortable. If you get it wrong. Oh, yeah. You know, you could end up in the news in the wrong way. You don't want that to happen. Yeah, we want you to be out of the news. So we have lots of companies out there that make the news every week for this exact reason. I think Troy hunt. I don't know if you followed my heart, but he's a big security. Yeah. Troy hunt has been on the show previously nice quite a while ago, but yeah, Troy is fantastic. He does. How have I been poned. And he's a really good. He's a bunch of good ideas around what it means to proper security as a developer. Yeah, yeah. But he's a Have I been poned. Right, what nearly 10 billion accounts have been compromised and made it to the to the news. So we don't want our developers to or their companies to make it to those news, right? We want them to make the news for good reasons, like growth or whatever. But from a security perspective, it's very hard to get authentication, right. It's very hard to get authorization, right. Especially if you're rolling it out yourself. And I've done this in the past. I am guilty of that. And I can tell you, bro, they're an awful system. Because I was learning as I was going, and it was an internal app. So no big deal there. However, I just know how hard it is to do yourself. And dude, right? Especially in the era of internet where there are so many challenges out there, you put your app out and on Azure, or AWS, it becomes a public target, whether you want it or not, you say that.

13:55 But it's hard to appreciate how quick or how soon it becomes a target. So for example, if I open up any of my web apps, the training website or the podcast or whatever, and I just tell the log of like, these are the requests coming straight into it. It's less than a minute before I see somebody requesting like, admin slash like WP admin slash like login dot php, or some other random like well known access point, just constantly. And the thing is not building web, WordPress, but it doesn't matter. They're just pounding on any open endpoint that they can find, to just start hitting it. So when you say that it's, that's probably within the first minute at least what that once it becomes a well known IP address. That is a host. Yeah, there's a funny story that goes with that once my website runs on that ghost, which is a lightweight kind of a platform for creating blogs. And yeah, I was working on that. And a friend of mine said, Why are you deploying manually the files, you should just put it on GitHub and then have a GitHub action to push it straight into other like, Oh, that's a great idea. And I post my solution to Azure Now, inside goes there's a central

15:00 section, which allows you to send emails if people subscribe or whatever. And I forgot the live settings in that file. So I pushed to the GitHub, I put in the public repo, I go to sleep, I get up the next morning, I get an email from sendgrid saying, you hit your I can remember it was to 25,000 emails limit, like, that's one plastic, I went viral overnight. That's brilliant. And then I continue reading the emails, like some of the reasons why this may happen is you get disclosed credentials, check your GitHub, like, oh, and that point, the light bulb went on. And thankfully, I was still on the free tier. So I didn't have to pay anything. But just the stupidity of me putting these things out there. And developers do it all the time. We see RSA keys on GitHub, we see SSH, oh, yeah, keys for secrets or API, whatever. We don't want developers to do that. And it's a very easy mistake to do. So there you go. It's super easy. And it is much like I spoke about like, within the first minute you publish your site, it's going to start getting hammered on. Have you guys heard of get no s? h, h, g? it? No. So this is a get I think it's a play on like, oh, my goodness get.

16:06 But also secrets get it's a thing. It's I'll put a link in the show notes for some, but it finds committed secrets and sensitive files across GitHub, just get lab in Bitbucket, or your local repositories in real time. Wow. And so there's like a continuous stream this thing, it hooks into the public API for these things. It hooks into like the public API for like changes to public endpoints on GitHub, basically. And it just yeah, it's the real time Feed API. And it just watches those and anytime it sees something come in, it just grabs like the secret keys and the off keys for I'm looking at an Azure AWS get. It's super disturbing. So yeah, I mean, it's not like, Oh, whoops, I have somebody found my repo. And this happened, like, no, it's like a live stream that was probably captured from that. And so it's, it's not good. Well, I think the way we look at it is like security sort of starts with the identity. If you can't secure the identity, then your app sort of your app can never be secure. Right? If you can't reliably know who people are, what they can do. So yeah, and it's worth throwing out like you could end up on Have I been poned, very likely not because necessarily identity directly, but SQL injection other badness. But nonetheless, identity is the first gateway. So let's talk about identity. You know, what I hear about people talking about security, they say, the three A's and identity even though it doesn't have an A in the word maybe as part of that.

17:33 We've got a fourth a, but I guess we'll start with the first three, right? All right, tell me about the fourth day because I only know the three. So I'm excited to hear I'm gonna learn something today.

17:42 So we have authentication, right? So we need to know who the user is. So when we authenticate somebody, we say, Hey, we know user ABC, john is the john that we're expecting from a trusted provider, or with certain properties, we can authenticate them correctly, and in a way that we can trust. Right? The second big one is authorization. So authorization is all about now that I know who john is, what can this person do in the app? What type of data can they right? Are they an admin? Can they create invoices? Can they view them? Are they just allowed to like, I don't know. Yep, something else? And what can they view? What can they do? What kind of actions can they take all that data, but then we get into auditing, so you know, what's been happening. And that's the third day. So logging the identity system, logging your app, logging all of those logs, and correlating them together. So that you can either be alerted when something sideways is going on or so you at least know what's happened historically, when you're investigating an incident or something like that. The fourth one is access control, which is actually enforcing control to what people have access to. And usually that falls to your app, but lots of different identity systems. Third, party identity systems have ways to enforce that access control themselves, too, right? You hear like exchange of claims, things like that potentially, right? Yep. Like the identity provider says you have this that you claim this right or something, even though it's not necessarily built in your app, your app, kind of trust it, right. And that's the whole point is a way for an app to say, I'm going to let somebody else do handle the authentication bit for me, and maybe even the authorization bit, I'm going to let them do it and send you back to me with this package of data of some package, it could be a set of claims, it could be a JW T and claims in the JW T. But it could be something else completely opaque and arbitrary. It doesn't really matter how it's done, or what the package looks like. What matters is that when you get it back as the developer, you can validate that it's true and that it's real and it came from where you expected it to come from.

19:45 This portion of talk by me is sponsored by linode. Simplifying infrastructure and cut your cloud bills in half with linode to Linux virtual machines, develop, deploy and scale your modern applications faster and easier. Whether you're developing a personal project or managing large workloads you deserve

20:00 Simple, affordable and accessible cloud computing solutions. As listeners of talk Python to me, you'll get a $100 free credit, you can find all the details at talkpython.fm/linode. linode has data centers around the world with the same simple and consistent pricing. regardless of location, just choose the data center that's nearest to your users, you'll also receive 20 473 65 human support with no tears or handoffs, regardless of your plan size. You can choose shared and dedicated compute instances, or you can use your hundred dollars in credit on s3, compatible object storage, managed Kubernetes clusters, and more. If it runs on Linux, it runs on linode. Visit talkpython.fm/ linode or click the link in your show notes. Then click that create free account button to get started.

20:49 I'm starting to feel like these identity providers, they're almost like one of the first microservices Yeah, for sure. Right. They're like a separate place you go but then they like your apps or to talk to them and so on. Kind of before microservices were cool before they were not cool again. But

21:06 pretty interesting. So the forays access control there on the end, and the first day I feel like that's identity right Who are you? Yeah, how do you prove to me you are who you say you are? Well, I complete system like a complete identity provider will give you all forays because Joslin occation is slightly incomplete. But yeah, you're right. I mean, when we talk about identity, maybe we refer to who you are to start with, right? So that's a good question, right? Like, what does identity mean, when you maybe you're talking about like, well, what is our app need? What mechanism should we choose to provide identity right like that? You got to be talking about the same thing that you have decided on the same trade offs. I think it's worthwhile. True. So let's start at the beginning. Like let's say mostly the beginning, I care about the first day, and I just want something simple. So I'm just going to create a username and password field. Like this is still the most common way. I think that logins happened on the internet. Oh, yeah. Yeah, there's a lot of people saying that their usernames and passwords are going away in different ways. I know, I think even Microsoft is working on something. You've got yubikeys. Like yubikey scared the daylights out of me. Like I love the idea that yubikey. But what if I lose it? It's like, it's like a password vault, but I can't get it back. I know, there's probably some mechanism where I can, I don't know, get it back. But it's, but there's other things other than passwords, but let's talk about username and password just for a minute. Because I feel like a lot of people are going to start there. Yeah, right. They're gonna say, well, we're going to need users. So let's have them have a password. When I put up a dialog or some kind of page that says login or create an account, do you forget your account here, set you enter your email address, and we'll send you on and like, that almost always has to be the very like, second feature, the very next feature you implement is how do you reset your password? Because it's incredible how frequently people forget their password.

22:53 Yeah, have you spoken to my wife, because like, it drives me crazy. We have a password manager for the house. We use a bit Warden these days. And there's lots of different tools out there. Okay. But for the last 10 years, I'm trying to instill in her that sees to not be using the same password everywhere. Yes. And once he doesn't do that, she doesn't record what password she uses. She always resets the passwords, once he needs to go somewhere. The problem is that not every site is optimized to respond real time. So you might say I forgot my password, and then you don't receive an email for two hours or two days. So you kind of use that site until you get that reset password that email. So I'm trying to say they're like, please don't do that. Just use our password manager. So lately thanga lately in the last six months, he started using bit Warden, yeah. And then I checked their bit Warden account, and I show that most of the passwords were very small variations of the same password. Like there's a way to automatically generate very long passwords. Yes, I know, not the long passwords that john is using, because I think he's like 90 characters long. But for me 24 characters randomized through a tool is great, but sorry, yeah, let's go back to reset your passwords. Well, I think what you're talking about is super interesting. A lot of people say that username and password are kind of broken, and they're not gonna work for the reason that you kind of just laid out with your wife. On the other hand, if you use something, so I use one password. We're one password family over here. But people talk about the challenge of logging in. And then I'm going to get to the developers of this quick, but I just want to riff on this because it drives me crazy, like, Oh, this username, password, I can't use it. What I want is some kind of bio authentication, I want a yubikey or something like that. And to me, my experience of logging into a website is I go to the website, I hit command, Backspace, that auto fills it either auto fills it. Or they'll say you have to log in. So I put my finger on the fingerprint reader on my Mac, and then it auto fills it. So to me, my login is there's stuff that happens in the middle, that's usually like a 30 or 40 character thing that exchange with the site, but to me, it's I put my finger on my Mac, and then I log into the site. Yeah. So that's an interesting thing. I think, yeah, the user experiences user experience and security are sort of in direct conflict with each other, right? So they often are. So when it's a miserable experience to add MFA, for example,

25:00 Like multifactor to do your phone or yubikey or whatever, when that's a miserable experience, nobody uses it. So like my parents literally have a physical book that they've written their passwords. And so in some ways, kind of Yeah, you someone's gonna break into their house to get it. It's so interesting because people say you should never write down your password like the last thing I'm worried about is someone physically see my written password. So yeah, exactly. Like I'm so paranoid of a virus or something getting into my computer or sniffing network traffic, like, the notebook actually seems pretty safe. Not reusing the password. Yeah, to be honest, but they still reused a password. And then like, yes, that's the problem. Netflix and not to call Netflix out specifically. But I encountered this a lot. I've got like, some crazy password that LastPass generated. Apparently, we all use different password managers, I have some crazy password that we can still get along. It'll be like a fight, like from anchorman, or whatever. But

25:57 I've got this, you know, 900 character password or something silly. And I went to a hotel, and it's like, hey, use your Netflix account in the hotel. I was like, oh, that'd be fun. And then I hit the login button, and it says, oh, type in your password. I'm like, No, like have to type it out. And probably with the remote control with the remote control, right? So I immediately pulled the plug on that and said, Well, I guess I'm just go to the bar or something instead, and but that experience is the same even when you're at home when you're on TV. And so people end up shortening their passwords to something they can remember something that's easy to type in on a remote control, which is why you see most of those services moving to a web based thing where you go to a specific website, type in a shortcode. And the one time code is what connects your account to your TV. Yeah, that's a nice system. Yeah, cuz that all of those other things like, oh, you're we don't know who you are, you should use your multifactor Are you we're gonna send you a text message to make sure it's you. All that can happen on your phone. And it doesn't have to be implemented for the device, right? And then your phone already knows who you are. And you're already logged in. So on the developer side of this username, Pastor, I think the username password is pretty straightforward. And I don't know, it's necessarily to be discounted, because for a lot of simple things, it kind of does make sense, as opposed to a Facebook login. But it's not, it shouldn't be discounted. But the challenge there is that it is not just the username and password that you need to store somewhere, and then bring back and validate that when the user inputs, the username and password, it's the correct one. It's all the other things that happen around that. So for example, password reset, how do I do my password reset? So as a developer, now you have to implement it now adding MFA? I'm not joking. It literally gets used like the first 10 minutes you launch an app? Yeah. Right, exactly.

27:36 You're just got here, it never existed before. Why are you resetting your password, but no, it happens.

27:43 That one, and then it's the MFA, if you want to do that. And if you want to either, like a notification, so you have to integrate sendgrid or whatever tools you want to use. So it shouldn't be discounted, especially if you're writing a simple app. But at the same time, like I tried, when I went back in 2007, I was implementing that solution I mentioned before, I had to implement the incremental back off for if you enter your password too many times, and then you're not the right one, then you have as a developer to manually roll that aim. Now, how do you do it efficiently? And how do you protect your app from? In fact, I was listening to Troy's podcast back then I was like, Oh, yeah, he's got some blog post that explains how to do it and why you should be doing it. Right. Let's go and do that. But if I hadn't had Troy saying that, then my website would be viable to or prone to a password spray attack or a brute force attack. Yeah. So yeah, for sure, absolutely. You can do it. But it just requires a lot of steps beyond just the simple username password implementation guide. So I think we're gonna move off of this one and to the next level. But before we do, I just, I would feel remiss if I didn't talk about pass lib in the Python space pass lib is so incredibly awesome. Because another thing that you got to talk about is, how do I store that password? It had better not be in a VAR char 16, the length of my password and just going straight in there, right? It had better be at least hashed. Yeah. And now with MD five, but with a complex hash, like B crypt, or shot five, or something like that, then you probably need to make sense salt, which is instead of just hashing the text, you also hash like a random other bit of text. So you can't do rainbow lookups on it rainbow tables. And then you need that to be computationally expensive for guessing just like you were talking about, right. So paslode is awesome, because it does all those things. But then it also folds the hash tag. So when you say hash this, it doesn't do it. Once it creates the salted hashes it, then it does it by default. 150,000 times takes the output visa back end takes output next time iterates at 150,000. That's the answer. So it's computationally expensive to guess. Yeah. If you ever have which is beautiful, I think. So if you're going to go down, consider if not using past lib, the ideas encapsulated in it as a really good idea. Yeah, I mean, the net of that and probably the

30:00 thing you'll hear over and over from us today is, don't write that library yourself.

30:05 Yes. Don't write your own past live, let people who understand the cryptography behind making it computationally expensive. Let them do it. Because there are a whole lot more eyeballs and a whole lot more sort of skill sets involved in getting those libraries out the door than anyone, we shouldn't expect a developer who's building an app to necessarily be super, super deep on what's the best hashing algorithm free to use for a password, or, God forbid, try to implement it on their own, because it's just there's too much risk for bugs. And in fact, so many of the breaches that we see, they end up pointing back to some homegrown system that was either completely built from the ground up to be sort of rolled on their own or was maybe use the library here or there, but ultimately had some sort of critical flaw in the path of hashing passwords. All right, it may start with one of these, I don't trust that third party library to do our encryption.

31:01 That's exactly how it starts. As always, same with the frameworks. I don't trust the dotnet. framework. I'm going to roll out my own framework on top of dotnet. Just to prove you guys. Yeah, yeah, exactly. Yeah, exactly. For sure. Then once just to finish on this one, I don't mind people building their own stuff like the their own username and passwords using existing libraries. But it does require some basic knowledge of certain things. Like today, you can walk into a room of developers and ask them to explain the difference between encryption and hashing. And half of them will get it wrong. Yeah. Because I've been in companies where they say we have secure passwords. We're encrypting them. And like, No, no, not these not secure. And let me explain why. So yes, do it if you want to play with that, but just make sure you know that that terminology and watching it to do, yeah, that's always an option. A huge red flag for me is when I go to a site, yes. And it says it has an upper bound on the length of the past. Yes, password has to be less than 16. gigs, like we did way, way way.

32:00 When you hash it, it's always the same size, it doesn't matter how big the input is. Exactly. Yep. So you must be mapping that text to something where it directly relates to the size of it. This is disturbing to me. Yeah, what's worse, it's one of the company you pay your mortgage to every month. Oh, my bank has like a 12 character limit. I'm like, What is going on? Mine is the same way. This is insane. To me, it needs to be between eight and 12 characters, it's like eight and 12 ways to reduce the attack space considerably for the person guessing passwords.

32:32 Just tell them myself? Sure.

32:34 All right. So I want to talk about some of the other stuff where you sort of delegate or transfer some of this identity, maybe to a federated identity, or some sort of social authentication, or just a central Identity Service that you have at your company that then powers your other apps. And there's a bunch of different pieces in here. And I have no idea where to fit them together. Honestly, we have Oh auth and there's Oh auth one, and then that became their ad data. So there's OAuth two. And then we have open ID Connect, what's the relationship? All these things? Like? Where did these fit into the world? Because Tell me about this. Tell us all about this. So Oh, auth. One was the first attempt at a way for two systems that don't have sort of any sort of inherent trust between them to talk to each other and have a little bit of trust. And it was all centered around a user. And so a user would say, hey, I want to give app ABC access to my data. That's an app 123. Very much like on your cell phone, when your cell phone pops up and says, Hey, this app wants access to your contacts. Do you want to allow this to happen? Right? It's a very similar sort of mechanism, that OAuth one but over the internet instead of like, on the phone. That's right. But yeah, and OAuth one was sort of quickly invalidated. Then we had 490, or some ridiculous number of drafts of OAuth two. And then we finally got to OAuth two. But the thing about OAuth two is that it's purely an authorization framework. It's all about giving ap 123 access to ap avcs data. It has nothing to do with the user actually. So you're not doing any authentication there. You're the system is authenticating the user because it needs to know to whom you're giving access to your data. But the application itself that you're using, say the mobile app on your phone doesn't actually know who you are, and oh auth or an OAuth two, it can access your data, and it can infer a lot of things about you. But the identity system is not actually telling you who they are. So open ID Connect is a sort of a superset of OAuth two. And so open ID Connect gives an application that extra token that says, hey, this is user ABC, and this is their first name, last name, email address, you know, whatever properties that you want to send over. And it's specifically intended for authentication to happen. Okay. Yeah, very cool. What are some of the use cases like concrete examples maybe that you see out in the world of these? So we'll start with open ID Connect, because that's in some ways, it's the more simple one. It's the more basic one yeah, open

35:00 Id Connect is used for signing user in to a web app to a mobile app, whatever. So let's say I've got a, let's say, let's say I'm going to my office mailbox and office 365. We might as well use a real example. At least a few people have those mailboxes. So we'll use one of those. And so when you go to when you try to get office 365, and sign in, it asks you for your username and password, and you'd type those in. And then those go off to what we have, which is Azure AD, some sort of centralized directory service, that centralized is a super common in large enterprises. They've got an active directory that like owns a definition of identity for like the whole company, and everything has someone else to talk to it. Yep. Or it same with your Gmail, right? Let's use Google. And let's use Gmail, because that's probably that's going to remove the the confusion of organizational stuff for them. So I'm just a guy with a Gmail account and I go to sign in Gmail itself is not actually doing any authentication, because Gmail is one of 5 billion apps that that Google has that they haven't deprecated yet. So yeah, maybe next year,

36:02 there's a great Twitter account called what is Google killed or whatever, I don't remember exactly what it was. It started after reader, I think reader was the that was the tipping point for a lot of people anyway. So I go to Gmail, and I type in my username and password, it's the same experience every time I see that same classic Gmail or Google Sign In window in the middle of the screen, and I type in my username and type in my password. And it's like accounts. google.com, I think is the actual website. And accounts like google.com, plus this long URL that comes after it the part that path of the URLs, it has all the bits of data that the Google authentication system understands to know you're trying to go to Gmail. So when I go and type in my username and password, the Google account system is the thing that checks my username and password, it also checks the request and says, oh, you're trying to go to Gmail. So I'm going to send you back to Gmail, I'm going to redirect you to mail@google.com, for example. And I'm going to have a specific chunk of information that I send along with you. And usually it's in the form of an ID token, Id underscore token. Okay. And inside that ID token is a bunch of data for the application. So in this case, Gmail to go look at and say, oh, okay, I know you this user is I'm gonna go look at my application database and pull back email and pull back tags and that sort of thing. So that's open ID Connect. And that's purely for getting signed into an application. So now we're signed in. So Gmail knows who I am. And they can serve, show me my email, right? There's probably not really many rules around what you're allowed to do, like Gmail users just do this. Right? Right. They read their email, they send email, and so but it's just what data do you have access to? Not? Can you administer Gmail for other users? That's not a thing, right? Better not be a thing? Well, and so sort of as a part of that, though, is that there may be an administrative interface in Google, you may have access to somebody else's mailbox, you may have access to something, some extra functionality, and like the business version of Google their apps, Google Apps, yeah. So once you're signed in, I didn't Gmail itself, the Gmail app doesn't know my username and password for Google. It doesn't. I never gave it to Gmail directly. I give it to the Google account system. And the Google account system authenticates me and checks my password and maybe prompts my phone or whatever. And then it sends back this blob of data to Gmail. And because Gmail trusts the Google account system, it can validate that Oh, the Google account system actually wrote this, actually wrote this token, because it's got their signature on it, and make sure that it's valid. And then let me into my email. That validation process is fairly standard for most things for most JW tees, for example, say I can't talk about Google with a Google phone sitting next to me because it thinks I'm talking to it.

38:44 Here's some things I found for you. Have you checked out on the web?

38:48 Sorry, I can't do that. Right now. That's probably the most common response. But the thing about it, though, is that Gmail system has to validate that the token came from the Google account system. And typically, we do that in like JW t world, where you get a JW t a JSON web token, typically, those are signs. So there's a cryptographic signature that sits at the end of that. And the identity system, the Google account system, for example, publishes enough data for Gmail to go and check that key and make sure that it was signed, actually by the Google account system to say, yeah, we know that this came from the Google account system, so we can trust it, right? That way, you know, it's not being faked, or man in the middle sort of thing. But then you already trust that service. And then you can verify everything you got from it was not tampered with. All right. Cool. All right. Let's go next to federated identity. So what we've talked about so far, is one app doesn't want to do the identity management itself. Because how painful would it be to log into your Google calendar with a separate account to your Google Docs with a separate account, right? You just want to have a Google account and then log into these things. But a lot of times there might be some app that is calling an API.

40:00 And then that API wants to call another API, carrying forward that same identity or something along those lines, right? I want you to be able to log into that system, which then allows you to log into effectively delegate that identity to an external system. Like, I would I don't know if this actually works, but I want to log into my corporate account, which then allows me to log into my business, Dropbox account, yep. By just virtue of being on the network, right? Or I want to be able to log into my corporate account, and then take talk Python courses by just passing that identity along through federated identity. Right? Yeah, correct. Well, the key is, you're never passing the identity along. In logically we are, but technically you never are. So let's go to Google for a second to Gmail. Okay. So your Gmail has the option to connect to your outlook and pull your Outlook email into Gmail. So when the Gmail front end when the app that you're using needs to connect to that service, that service is going to require some kind of authorization from the user for the user to say, Yeah, I want the Gmail app to be able to go and talk to, or to be able to read my email. In order to do that, when we're calling the effectively the outlook.com API for lack of a better term, we need the user to go and approve that request and say, Yeah, I want to do that, which is typically called consent. And so when a user consents, they get the window that says, Hey, would you like to allow app 123 to access your data on the service? In this case? Would you like Gmail to be able to access outlook? When you click Allow, or Yes, that's okay. That's when a new token is issued. So use the developer of the Gmail application, you go and talk to the identity system for the other party. So in our case, Azure AD and Alex calm and say, Hey, please give me a token for user 123. And so if the user has gone through and authenticated correctly, that first API, the Gmail API for if we want to call it that, that goes through a round sort of a back and forth with the other authentication system that says, hey, this is what the user provided, please give me a token for this next service. And so each step in that service is typically called a sort of a, that's a more of a traditional OAuth. But each one of those steps needs to have its own token to talk to those downstream services. Because if I tried to reuse a token for a different service, in most cases, most properly built Oh auth services and API's will reject that token and say, No, I didn't issue this token for you. I issued it for this upstream service that you're trying to call, right. Okay. And what kind of systems can you use to set up that? The federated identity, I know Azure has some federated identity thing like, what that and what else? There's Azure AD courses we offer, there are others like Okta, and zero, that are all sort of identity as a service. So those are service providers who are offering a full, holistic SAS type thing software as a service where I'm on the fence about zero, it looks interesting to me, but the pricing model looks like it could get out of control, pretty quick for a lot of scenarios. But it looks nice. But every time I've looked at it, I've always been curious to the pricing. But I can't say too much because we work for competitors. I don't want to I don't want to say anything about it. But yeah, you don't have to say anything, but I it's like you pay a little bit like that mail list. Companies like MailChimp, and drip and ConvertKit. All those things you like, this should be pretty affordable, then all of a sudden, you're like, why am I paying $400 a month? emails? Yeah, maybe I should switch? Oh, that one's 500. So once you kind of get into these realms, I don't know. I mean, I can't say exactly what it is. But if it sort of felt to me like that, so yeah, yeah. Anyway, sorry. It's bit of a diversion. But that's okay. A lot of it depends on what the key is for pricing. Like, the way that we bill is for certain features, the way that other providers bill might be for certain, like number of users or number of applications. And there are all sorts of different metrics that the different providers bill on. And it just kind of depends on what you're doing as to which one of those metrics makes the most sense. Yeah. And just to like, set the context for people, I do want to be fair to office here, but also let people know. So I just looked at their pricing. They're up to 1000 users, which is not a lot like if I you know, like talk Python trainers way more than 1000 users $23 a month, but just 5000 active users is $1,000 a month for identity. Oh, there's a lot like if it's Yeah, if it's over 7000. Like you got to get in touch. So anyway, that's a high burden to carry on top of like your other expenses and trying to run a business when you're starting out or whatnot. So anyway, yeah, that's what I thought when I was thinking of that, I guess in fairness, I should say that our consumer identity product, which is called Azure AD, b2c, your first 50,000 monthly active users are free. Yeah. So you can start using that immediately. And once you have 50,000 monthly active users, maybe you've got a good problem anyway, and spending, you know, yeah, exactly. spending a couple of bucks on an identity system will be a big deal. Yeah, for sure. And one of the things about these systems is that the convenience that you get of not having to manage the deployment and the maintenance

45:00 And the scalability of the system. So whichever identity provider you go to depending on your choices, hopefully you'll come with us. But you know, that's not a prerequisite. I would rather have a developer saying, No, we're going with x provider, because we want to do right rather than us having to go and put out fires because they did their own thing. But whatever you do, there's always this kind of a trade off where I don't have to roll it out myself. And I know that these companies are dedicated to doing that. And you get to pay a little bit more to get that convenience out. So security is always this kind of a trade off. Where do I pay for it? There's no 100% security. So as close to 100%, you get that's great. Yeah. And it's with everything I think we're the really interesting value comes in is the integration between other identity providers, right? Like, you can kind of do username, password yourself all you want, and it's okay. But like, once you like, well, we're gonna talk to this system. And then we want to integrate with their identity, like all of a sudden, it explodes in complexity. And we were talking about you kind of got to do a little work to do your own username password stuff, you should never try to do this, like the cryptographic exchanges and stuff in the back and forth. It just, it's insane. Some of this, so like, you don't want to mess with this, right? Yeah, not by hand. I have a customer I worked with a while back. And they had a really old legacy app that was cold fusion 10 and couldn't be moved past cold fusion. Impressive. Yeah, I was impressed. It was still running. But they still had a server that would run that. But the thing is cold fusion 10 went out of support before open ID Connect became a standard. So there are no libraries for open ID Connect. So we we helped them write one. And it's not for the faint of heart. I mean, there's there's a ton of signing and cryptographic signatures that happen both signing the tickets themselves, and then reading them to make sure they're okay. And it's certainly not something I'd want to do on a regular basis. It's a high stress, high stress, job built writing identity code. So yeah, it's super frustrating to debug that stuff, too. It's like, we don't validate the certificates account. Like, why what? Like, I don't want to bring back pain. So I'll go to a separate therapy session for this.

47:06 We should offer separate therapy sessions as a service. Yes, you should for the developers.

47:12 All right. So let's make this concrete for everyone out there and do in Python programming. There's a host of libraries that are available for you, you could just pip install them, and then go integrate them into your apps to not necessarily for the username password story. Like that's built into Django. I talked about pass love and like integrating, that's pretty easy. But you know, things like OAuth, OAuth two and open ID connect and whatnot. So one of my favorite places, when I have no idea what I'm doing in a corner of Python is to go to awesome dash python.com. And those are not all of the libraries in an area. But those are libraries that have gotten submitted a certain number of times. And once they cross a threshold, they're like popular enough to be in, there's my understanding how that place works. So anyway, it's like the kind of the popular recommended libraries, and they have an authentication section. So they've got an O auth, and a JW. T section in here. So let's just talk about some of the ones that you might use. I mean, let's start with the Microsoft one, because you guys have an interest in b2c and Azure AD library for Python, right? Yeah, that's correct. I mean, for us, if you are going to use our identity system, then there are two choices. And because we're built on top of open standards, there, we give you choices in how you interact with our system. Now, if you are fairly new to our identity system, and you haven't done any authentication before, that will give you amsoil for Python, or emsl, for whatever ecosystem you want, right. So it's not just Python, which follows the same standards that you should be following and comes out of the box. It comes with samples and everything else. However, since we are abiding to open standards, there's a number of other auth libraries out there. And as long as they're open ID compliant, and OAuth compliant, then you can use your own thing. So you can bring your own libraries or you can use our libraries. We just want to make it easy to get off the ground and implement the solutions. Yeah. So emcell is recommended for us if you're coming to Microsoft as a fresh Greenfield project. But there's a list of other ones like ORTLIEB Django loss. I think that there's a whole list of other solutions there. Yeah, yeah. So there's a couple for Django. I feel like Django has the biggest advantage here. There's a lot of ones that are just like plug in middleware type of things. Whereas if you're in flask, or pyramid or something else, you kind of have a lot of times you're like I will, how do I take this random library, integrate it. So we've got Django dash all auth, which has the moniker just works for authentication in Django, which is nice, nice as all the authentication, right. There's Django auth toolkit, and it says, it'll help you provide out of the box endpoints data logic to add OAuth two capabilities to your Django projects, I think both. Maybe both ends actually, as a provider as well, which is pretty cool. You've got one that looks really flexible called OAuth lib. And this one

50:00 Nice cuz it's a generic library not just for, say Django. But the problem with the generic ones is you kind of got to understand like, there's this exchange, there's like these five callbacks, you got a hook or whatever, which is a pain. Yeah, you don't want that. Yep, you want just like I do this, and then I get the user. So what they did is, there's a bunch of people who have built wrappers for common frameworks. There's a Django a toolkit, which wraps that there's the flask, oh, auth, and flask dance, which wrap this one, there's pyramid dash o auth. lib, which wraps it for pyramid and bottle. And it says, if you have another library like Sanic, or whatever, some other random web framework, and you want to add that you could write a thin wrapper around OAuth lib, and then add that to your framework. So that's pretty cool. Yeah, I think our library, we tried to balance sort of the pythonic idioms so that it makes sense if you're looking at it, if you're familiar with Python, that when you come to the library, it makes sense how you use it, how you import it, how you integrate with it. But our focus has been really strong on know how to use the library, and not necessarily having to be a super deep protocol nerd to understand how to use it. So most of the the API surface where our library is fairly, it's fairly light, it's sign in user a get token quietly and get token by prompting the user, there really aren't that many protocol details that are leaked out of there. That's good. Because Yeah, we want it to be as close to a just work kind of a scenario as we can. And when you've got open ID seven and a watch nine, yeah, you can just keep the same.

51:34 Well, a great example. So for a long time, there's been something called the implicit flow and OAuth. And the implicit flow was the least secure flow of all of the ways you can use OAuth. And there's a new, a new thing authorization code with pkcs 11 here called Pixie lot, where you don't need to worry about what the flow itself actually does it obviates the need for to use the implicit flow. So in apps where you have to use implicit today, you can use this Pixie based flow tomorrow. And we updated our libraries to use that. And we were working on a Javascript app the other day, and we upgraded the package. Nothing else changed. And we started using Pixie and we didn't have to change a line of code, which was awesome. We just upgraded the package. So yeah, that's super cool. Yeah, nice. So our maintainers are maintainers do what they can to keep the API surface as generic and consistent as possible, in the sense that it's very focused on what do you need to do rather than how does it need to be done? Right. Okay, that sounds great. So one other place, I want to give one a library ish, I guess library framework I want to give a shout out to in this space is FastAPI. So for me FastAPI is the hot new API framework in Python these days, right, it's got fantastic support for async and await. It's got really cool support by taking pedantic data exchange models with validation automatically binding like a JSON post over to it. But it also comes with OAuth two scopes directly built in. So it lets you work with like more fine grained permissions, and do many of the big integrations with providers like Facebook and GitHub, Microsoft, they call it explicitly. So yeah, so that's kind of built into the API there, which is pretty cool. That's cool. Yeah. And I think, because we're standards backed, if a library is implementing, oh, IDC, open ID Connect, or OAuth two to spec, they should work with our system and any other system really, without having to make any changes. It all just comes down to configuration. And it's also worth noting, too, that a an API developer, someone who's building an API, their concerns are going to be a little bit different than someone who's building say, a web app that consumes that API. Because, yeah, an API, I don't necessarily need to log into an API, I need to validate a token that's coming in from some other client or web client or mobile client or whatever. And so the things that I'm concerned about more are Can I validate that this is a real token? And then what does the token allow this user to do? Which is just a different set of concerns than say, I'm building a front end web app, and I need to let a user sign in and then determine what they need to do and call API's. Yep. Because one of those are just receiving something you need to check. And the other thing you need to handle the actual acquisition of one of those two, right, which can get tricky, like that provider over there said their email address was this. So I'm gonna assume that I can identify them by that, but is that really their email because they could have lied to that place. There's a lot of interesting stuff there. So I think this gives us a pretty good range of the world in this identity space and some of the libraries we can use but I, I definitely want to have a short conversation, especially with you crystals because we went off on this before we hit record about depending on basically social media, for your identity, and other places, right. So that's I want to go like you go to places you can create an account with a username or password or you can use Facebook or you can use to

55:00 Or you can use Google or you can use your Microsoft or whatever. How does that make you feel? Do you like it? Your fan? I am, I am partial to it, as we were discussing before, I think it's a great convenience. If you are creating a consumer app, you want your consumers to be able to log in. So let's say your Walmart or whichever account, you want people to come into your shop and buy with great convenience. And I know a lot of people just don't use the right tools. So they don't want to go and create a username and passwords for every single website. However, yeah, right. They have these thoughts like, oh, if I'm going to create an account here, how can I trust this random thing on the internet to not like, get hacked as my password? Exactly? To me? I don't feel that way. Because it's a 40 character, randomly generated thing and it true if it gets lost or whatever, right. But anyway, yeah, carry on. Yeah, but you're right. I mean, I tend to avoid using my social media accounts for logging in first, because I don't remember which one I use where. And that means that if I go to a site, I haven't used them in a year, like, did I use Google? Or do they use Facebook and every time, every time you actually go back and use a different social media account, it gets in your account for you? Yeah. So you might log in with a new account, and suddenly, like, Where's my basket? Where my orders from last year? And what have you? So it's a little bit confusing, right? So a year ago, you went in there? He said, I feel like Twitter. Yeah, right. Create an account, and it knows your Twitter. And then you go back here like, gosh, there, I could log with Twitter, Facebook, GitHub with all is probably I trust Facebook. And that is a totally different account. It's as if you use a different username and password. And you're like, well, what is this, right? There's no, it drives me crazy. There's no real record of that unless you hunt through like your authorized apps and your different social media platforms to find it correct. So I can see the convenience there. And I know that some people like to sign everywhere with their Facebook account, and they only have that one. By the same time it gets a bit of a login. So if I decide to delete my facebook account, for whatever reason, and if I decided to stop using Google From now on, then that means everywhere sign with my Google account, is now not accessible anymore. So I have to go and create a brand new identity for me. So two people, I like to use them, I would just say approach them with caution. But they're more secure, right. So you don't have to create a username and password all the time. They do bring that access token to the app, they do that secure exchange that we talked about earlier on. So Facebook now is a trusted provider for my identity into the new system, which reduces the amount of passwords but if you use the right tools, like a password manager out there, then I don't think that should be an issue. So I agree that the danger is like, you're not going to have your password dumped on Have I been poned. And like, yeah, payspan and other random places, if it gets hacked, if use say face, let's just pick Facebook, login, use Facebook. But if you authorize 50 different websites with Facebook, and your Facebook account gets hacked, yes, all of a sudden, like you've got a list of these are all the apps that you also can use if you break into this one, right. So there's like this, there's a bigger wall. But if you scale it, there's a larger pile of goodies for the hackers to get ahold of on the far side of it, I tend to fall on the side of I might use a social login. But I usually create a username and password, either first if the site supports it, or after I've done a social login always because that way, like I deleted my facebook account the other day, and then I had to create it again, which was really made me sad, but like, my own account is totally gone. And so anything that I had authorized, there will be gone. And Facebook's also a little bit of different of an identity provider because there are a lot of apps that are a little bit malicious because you get a lot of data and Facebook and so for a while is sort of the wild west of Oh, you can sign up with your Facebook account. And then I'm also going to pull your friends list and your photos and all these extra things. Yes, exactly. So, you know, it's

58:40 our privacy policies. We work with this guy in the UK when there's like some analytics. Yeah, I don't know. I mean, I forgot the name of the cut, but the whole one that around the DNC, another DNC hack, but like, Oh, yeah, Cambridge the one that happened like around there. Yeah. Cambridge Analytica? Yes. Cambridge analytics. Yes. Yeah, we just we don't share much we just share a little data with them. It's gonna be fine. Just a little. So yeah, I mean, I tend to fall on the side of because the big risk with passwords is if you use the same one over and over again, or a variant, and somebody gets it from site a now they've just unlocked 40 other sites for you. But so a password manager with super random accounts kind of removes that. So if I get a notification that my password is on Yes, on Troy hunt site, well, at least I know that password the the blast radius of that password leaking was just to that one site because I didn't use it anywhere else. And that's sort of the key so yeah, and you just go change the one place and it's fine like what I usually it's those huge random ones are probably good enough, even though space so I don't know I'm with you. There's a site that I use periodically, and it literally does not allow me to create a username and password. I can only login with Facebook. Yeah, that hurts. Wow. Sounds like it's time to not use that site anymore. And it keeps logging me out. And I had been taking the policy that I'm not going to be logged into Facebook on my main browser. If I want

01:00:00 Do Facebook ads, an incognito window to Facebook? And then I closed that down, right? Yeah, good idea. But now I've got to stay logged in if I go, I mean, I gotta keep logging in and out of Facebook just to go do that thing. But it has these like knock on effects of well now like every facebook pixel, and the internet is now turned on for me, to the extent that my ad blockers are not stopping that, right. It's like a arms race. But it's, it frustrates me if that's the only option out there. Yeah, for sure. Yeah. All right. Well, just leave it there. I suppose. I think we're getting definitely along in time here. But it's been really fun to talk about identity in the broader sense with you guys. Absolutely. It's been a blast being here and talk about NT and how to keep you off the news. Yeah. All right. For you out here. If you're gonna write some code, I'll just do there's two, I'll just ask the one. Although, who knows, it might be the same answer. We'll see. You're gonna write some code, some Python code, what editor do you use? I would probably go with VS Code. Okay, because I am more comfortable without I haven't really used by termites. And I haven't really done a lot of Python production at work to say that. So that will be the convenient one. However, we are working with JetBrains these days to actually improve the user experience inside pi torch and vice versa. Your Python Yeah, awesome. Really? I didn't know that. That's cool. Yeah. So we want to bring it into turbo. Yeah. So use the tools that that work best for you. Yeah, absolutely. JOHN have a Jupyter notebooks count? Yeah, absolutely. Count. Sure. In the browser. Yeah. No, I mean, yeah, most of what I've used Python for in the past, probably past 12 months has been, like work in spark doing like data processing and stream processing, which Yeah, I kind of love it for that, because it's so much easier than Scala. And

01:01:39 I tried to do Scala once, and I was really quite miserable. And then I was like, gosh, do this in Python. And then a lot of it too, I do use VS Code a lot. And for more sort of like application stuff for doing like Azure Automation stuff. Like if I want to automate some resources and things like that in Azure, or use like AWS, lambda, for application stuff, I tend to follow vs. codes. Excellent. All right. Well, that's definitely a popular answer these days. All right, final call to action. And people are interested identity, they want to up their game and their app. Or maybe they're creating a new app, they want to try something different, like federated identity. So the What do you say to them, do it and come hang out with us? on Twitch, come and write some code with us and tell us what you want to see. Tell us what kind of scenarios you're in that you want to see. Yeah, we haven't talked about that. Just really quickly. You guys have a twitch programming live stream, you wanted to tell folks about that real quick. We'll put the link in the show notes. Sure. It's every Tuesday and Thursday at 7am Pacific 10am. Eastern. And usually Tuesdays, we build something right now we're working on a multi episode project of building what we're calling the threads man, which is the Azure resource Thrasher. It will be fun. And we take questions from the chat and from the community all the time. And then Thursdays we do community hour where we show we show off like a cool project from somebody in the communities been working on or we have a guest Come on from Microsoft or outside and share with the world what they're working on, or something really cool. Or a big announcement. And yeah, it's a lot of fun. Yeah. Cool. I hear you have some Python topics maybe coming up, potentially. We do. What are you gonna come on the show? Come on with us? Oh, yeah. Yeah.

01:03:09 October 20. Nice. It's already done. Agreed. And we're cooking. So we'll make sure that we promote that and let people know that you're coming to the show to build some awesome authentication stuff with us. Yeah, that'd be sweet. Yeah, sounds good. We'll do some flask plus, open ID connect or something like that. Yes. Awesome. All right, guys. Thanks for being on the show. It's been a lot of fun. Thanks for having us. Thank you for having us. Yeah, you bet.

01:03:32 This has been another episode of talk Python. To me, our guests. In this episode, we're Christos mascus. And john Patrick Dennison. And it's been brought to you by us over Talk Python Training in linode. Simplify your infrastructure and cut your cob bills in half with linode. Linux virtual machines develop, deploy and scale your modern applications faster and easier. Visit talk Python FM slash linode. And click the Create free account button to get started. Want to level up your Python. If you're just getting started, try my Python jumpstart by building 10 apps course or if you're looking for something more advanced, check out our new async course the digs into all the different types of async programming you can do in Python. And of course, if you're interested in more than one of these, be sure to check out our everything bundle. It's like a subscription that never expires. Be sure to subscribe to the show, open your favorite pod catcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes. The Google Play feed is /play in the direct RSS feed at /rss on talk python.fm. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Get out there and write some Python code