So you're excited about that next app you're about to build.
You can visualize the APIs 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 out of GitHub with zero downtime.
What you're probably not dreaming about is writing yet another password reset form
and 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 Mascas and John Patrick Dendison,
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 2nd, 2020.
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 @mkennedy, and keep up with the show and listen to past
episodes at talkpython.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 .NET 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 .NET developer.
This 10-hour course takes all the features of C# and .NET that you think you couldn't
live without.
Unity 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/.NET.
That's talkpython.fm/D-O-T-N-E-T.
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.
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 if they're building
apps, right?
So that's our goal.
That's right.
Yeah.
So let's start with the beginning, with setting stage, just personally for you two.
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 one
of the languages you write?
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 hacker.
At some point in my life, the crossroads of what do I want to do?
I think it was the tender 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 hacker.
So I was like, to be a hacker, you need to know how to write code.
So I was like, okay, I'll go and get a degree in coding.
So I did a software engineering degree.
And then I thought, you know what?
If you want to be a good hacker, you need to know about networking.
So I went and did a networking degree, understanding 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 .NET 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 stack for very long.
So since 2004, I've been writing code in .NET.
But over the years, I worked as a consultant.
So I got a chance to double with Python, Node, Java.
And that Polyglot experience brought some interesting bits like, oh, I like this bit from Node.
I like this bit from Python.
.NET doesn't do everything.
Then .NET Core came around.
So I fell in love with .NET Core again and pulled me back into the .NET ecosystem.
And then I joined Microsoft in 2016, working as a consultant, helping customers.
And since March, I moved into the identity team where 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, it's 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 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.
We speak to Google developers.
We speak to DigitalOcean 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 languages that you love.
All right.
I can't let you get off this topic here of 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.
As is Mr. JP's, who's going to 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, if those of you who have not watched this, it gets a little weird in season two and season three.
But season one, this is, I would say, it's probably the absolute best dramatic representation of programming and software in a show.
It's not one of these fake things.
Like, you really feel like, I think there's a whole section where they're using PyCharm to write some Python code down.
Yeah.
And you're like, dude, that's legit code on the screen.
That's not like weird green text falling down or something, right?
Actually, it's super accurate.
And there are lots of people in the tech industry that love that show that spend time looking at the commands that they write to analyze whether it's a 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.
Was that the VBA one?
The VB one?
Yeah.
The very first one where they were like, oh, somebody is attacking us.
And the two people jump on the keyboard trying to type at the same time on the same keyboard.
Oh, that hurts.
That's not the pair program we were thinking of.
All right, John, how about you?
How did you get into programming, VBA?
So I started, I was always sort of into computers and building stuff when I was a kid.
And so I thought, oh, I'll go to college for something I want to do, which is music education.
So I wanted to be a band director.
So we see, which we see how well that worked out.
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 and 4chan.
What?
Oh, God.
Yeah, no thanks.
Yeah.
All right.
So yeah.
All right.
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#, you should know that stuff, even if you don't necessarily do it day to day.
Yeah.
And then while I was in college, I found a job on a help desk and one of their developers left and they said, hey, do you want to come help and take over?
And I said, I guess.
I have no idea what I'm doing, but I'll try.
And so my first project, for better or for worse, was an online banking app that was written in C#.
And I was like, are you guys sure you want me to build this?
I was like 20.
That's so interesting.
I remember the first time I wrote a credit card processing, I was paranoid.
I had a hard time being relaxed.
I'm like, what if I get it wrong?
What if I charge them $10,000 instead of $100?
Because I thought it took cents and it took dollars.
It was really nerve-wracking.
And that's a hard first project.
When it was me and one other guy, and he had a lot of – he was a 15-, 20-year guy.
But I would ask him questions and he was just like, yeah, no, it sounds fine.
I thought, you seem very relaxed about this whole thing.
And it was an app for high net worth individuals to go and manage their insurance accounts.
So I guess there weren't like transactions necessarily happening, but you could reinvest your life insurance policy and stuff.
I mean, I was terrified every day I went to work.
And this guy, we hired a guy, a 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 a desk with a tower of Mountain Dew cans in between me and him.
And he would poke out once a day and he'd go up and write a concept on the board like, you need to go learn about interfaces and C-sharp.
And I said, okay.
And I'd go figure it out and learn about them and come back a couple days later and say, okay.
But 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 when it's nine years old, but I guess it's still a 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.
I feel like people almost consider Facebook and these types of places a startup.
Like this is not a startup.
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.
Overprofit or profitability.
I feel like there's some sort of metric you can say, like this world makes these attributes make it a startup, not just a small business or a large business.
I don't know.
What do you think?
Yeah.
Well, by that definition, let's see, growth over profit, VC money.
So we've had none of those things.
Exactly.
But I think we called it, we used to call it a startup because it was only two of us and it was technology focused.
It was all about, it was actually, it was a proxy.
Yeah.
I think it qualifies.
Sorry for the diversion.
Keep going.
No, no, 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 5,000 nodes.
And a lot of patterns and how do you deal with consistency and data and 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 Azure.
We had some customers that were calling Rackspace the cloud, which that's cool because back then they were about the only other thing out there.
And then I came to Microsoft and did pretty much the same thing, but focused on Azure.
And a few months ago, right around the same time Christos did, joined 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, this is what I want 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, we're sort of a funny saying that we hear people say around our division of, we need to talk to identity developers.
I was like, well, 1,500 identity developers in the world work for us because they care about identity and 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.
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 follow Troy Hunt, 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.
Have I been pwned?
And he's a really good, he has a bunch of good ideas around what it means to proper security as a developer.
Yeah.
But he's a, have I been pwned, right?
What nearly 10 billion accounts have been compromised and made it to the, to the news.
So we don't want our developers 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 the authentication, right?
It's very hard to get authorization, right?
Especially if you're rolling it down yourself.
And I've done this in the past.
I am guilty of that.
And I can tell you I've brought 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 it yourself and do it right.
Especially in the era of the internet where there are so many challenges out there.
You put your app out on Azure or AWS, it becomes a public target whether you want it or not.
You say that.
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 tail 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 built in 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 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 a 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 that pushes it straight into Azure.
I'm like, oh, that's a great idea.
And I pushed my solution to Azure.
Now inside ghost, there's a send grid 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 GitHub.
I put in the public repo.
I go to sleep.
I get up the next morning.
I get an email from send grid saying you hit your, I can't remember.
I think it was two, 25,000 emails limit.
I was like, that's fantastic.
I went viral overnight.
That's brilliant.
And then I continue reading the emails.
Some of the reasons why this may happen is you disclose credentials, check your GitHub.
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 SSA 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 shgit?
No.
S-H-H-G-I-T?
No.
So this is a shgit.
I think it's a play on like, oh my goodness, git.
But also secrets git.
It's a thing.
I'll put it in the show notes or something.
But it finds committed secrets and sensitive files across GitHub, GIST, GitLab, and 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 auth keys for...
I'm looking at it.
...Azure, AWS, GitHub.
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 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 and what they can do, so...
Yeah.
And it's worth throwing out.
Like, you could end up on have I been pwned?
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, when I hear about people talk about security, they say the three A's.
And identity, even though it doesn't have an A in the word, maybe is part of that.
We've got a fourth A, but I guess we'll start with the first three, right?
All right.
Tell me about the fourth A, because I only know where the three is.
So I'm excited to hear.
I'm going to learn something today.
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, something else?
And what can they view?
What can they do?
What kind of actions can they take on that data?
But then we get into auditing.
So you know what's been happening.
And that's the third A.
So logging, be it 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 trusts 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, some package.
It could be a set of claims.
It could be a JWT and claims in the JWT, 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.
This portion of Talk Python To Me is sponsored by Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's 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 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 24-7, 365 human support with no tiers or handoffs regardless of your plan
size.
You can choose shared and dedicated compute instances, or you can use your $100 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.
I'm starting to feel like these identity providers, they're almost like one of the first microservices.
Yeah, for sure.
They're like a separate place you go, but then your app sort of talks to them and so on, kind
of before microservices were cool, before they were not cool again.
But pretty interesting.
So the four A's, access control there on the end, and the first A, 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, a complete system, like a complete identity provider will give you all four A's because
just authentication 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 are talking about like, well, what does our app
need?
What mechanism should we choose to provide identity, right?
Like that, you got to be talking about the same thing so that you have to decide on the
same trade-offs.
I think that's worthwhile.
True.
So let's start at the beginning.
Like, let's say mostly the beginning, I care about the first A and I just want something
simple.
So I'm just going to create a username password field.
Like, this is still the most common way, I think, that logins happen on the internet.
Oh, yeah.
Yeah.
There's a lot of people saying that the usernames and passwords are going away in different ways.
I know.
I think even Microsoft is working on something.
You've got YubiKeys.
Like, YubiKeys scare the daylights out of me.
Like, I love the idea of the YubiKey.
But what if I lose it?
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 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.
They're going to say, well, we're going to need users.
So let's have them have a password.
We're going to put up a dialogue or some kind of page that says, log in or create an account.
Did you forget your account here?
Enter your email address and we'll send you one.
And that almost always has to be the very second feature.
The very next feature you implement is, how do you reset your password?
Because it's incredible how frequently people forget their passwords.
Have you spoken to my wife?
Because she drives me crazy.
We have a password manager for the house.
We use Bitwarden these days.
And there are lots of different tools out there.
Okay.
But for the last 10 years, I'm trying to instill in her that she should not be using the same password everywhere.
Yes.
And when she doesn't do that, she doesn't record what password she uses.
So she always resets the passwords when she 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 can't use that site until you get the recent password email.
So I'm trying to say to her, like, please don't do that.
Just use our password manager.
So lately, thank God, lately, in the last six months, she started using Bitwarden.
Yeah.
And then I checked her Bitwarden account.
And I saw 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.
Sorry.
Yeah.
Let's go back to resetting 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 going to 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 a one password family over here.
But people talk about the challenge of logging in.
And I'm going to get to the developer side of this quick.
But I just want to riff on this because it drives me crazy.
Like, oh, this username and 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 it auto fills it or it'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 experience and security are sort of in direct conflict with each other, right?
They often are.
So when it's a miserable experience to add MFA, for example, like multi-factor 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
in.
So in some ways, it's kind of, yeah, somebody's got to 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 seeing my written password.
And so, yeah, exactly.
Like I am so paranoid of a virus or something getting into my computer or sniffing network
traffic.
Like the notebook actually seems pretty safe as long as you're not reusing the password.
Yeah.
To be honest.
But they still reuse the 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.
Sorry, we can still get along.
It'd be like a fight like from Anchorman or whatever.
But 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, I'm not going to type it in.
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 going to the
bar or something instead.
And but that experience is the same even when you're at home on your own 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 short code.
And the one time code is what connects your account to your TV.
Yeah, that's a nice system.
Yeah.
Because then all of those other things like, oh, you're we don't know who you are.
You should use your multi-factor or you were going to 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.
You're already logged in.
So on the developer side of this username and password, I think the username and password
story is pretty straightforward.
And I don't know it's necessarily to be discounted because for a lot of simple things, it kind
of it 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.
Yeah.
Adding MFA.
I'm not joking.
It literally gets used like the first 10 minutes you launch an app.
Yeah.
Right.
Exactly.
You're just gone here.
It's never existed before.
Why are you resetting your password?
But no, it happens.
Yeah.
That one.
And then it's the MFA if you want to do that.
And if you want to add a notification, so you have to integrate SendGrid or whatever tools
you want to use.
Yeah.
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 incremental backoff 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 heard 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 a simple username password
implementation.
Yeah.
So I think we're going to 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 passlib in the Python space.
Passlib 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 VARCHAR 16, the length of my password and just going straight
in there, right?
It had better be at least hashed.
Yeah.
And not with MD5, but with a complex hash like bcrypt or a SHA512 or something like that.
Then you probably need to mix in 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 passlib is awesome because it does all those things, but then it also folds the hash back.
So when you say hash this, it doesn't do it once.
It creates the salt, it hashes it.
And then it does it by default 150,000 times, takes the output, feeds it back in, takes the
output next time, iterates it 150,000 times.
That's the answer.
So it's computationally expensive to guess if you ever have, which is beautiful, I think.
So if you're going to go down it, consider if not using passlib, the ideas encapsulated
in it as a really good idea.
Yeah.
I mean, the net of that, and probably the theme you'll hear over and over from us today is
don't write that library yourself.
Yes.
Don't write your own passlib.
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 for me 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 used a library here or there, but ultimately had some sort of critical flaw
in the path of hashing passwords.
Right.
It may start with one of these, well, I don't trust that third party library to do
our encryption.
That's exactly how it starts.
That's always how it starts.
It's the same with the frameworks, right?
I don't trust the .NET framework.
I'm going to roll out my own framework on top of .NET just to prove you guys.
Yeah.
Yeah, exactly.
For sure.
There are one silence just to finish on this one.
I don't mind people building their own stuff, like 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, that is 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 the terminology
and what you need 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 password.
Yes.
The password has to be less than 16K.
It's like, wait, wait, wait, wait, wait.
Because 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 when it's the company you pay your mortgage to every month.
Oh.
Yep.
Oh, my bank has like a 12 character limit.
I'm like, what is going on?
Mine's the same way.
This is insane to me.
It needs to be between eight and 12 characters.
It's like eight and 12.
Way to reduce the attack space considerably for the person guessing passwords.
Jeez.
Exactly.
Why don't you just tell them my social security number?
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 OAuth.
And there's OAuth 1.
And then that became sort of outdated.
So there's OAuth 2.
And then we have OpenID Connect.
What's the relationship?
All these things.
Like, where do these fit into the world?
You guys tell me about this.
Tell us all about this.
So OAuth 1 was the first attempt at a way for two systems that don't have 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 in 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.
And then OAuth 1.
But over the internet instead of like on the phone.
That's right.
But yeah.
And OAuth 1 was sort of quickly invalidated.
And then we had 490 or some ridiculous number of drafts of OAuth 2.
And then we finally got to OAuth 2.
But the thing about OAuth 2 is that it's purely an authorization framework.
It's all about giving app 123 access to app ABC's data.
It has nothing to do with the user, actually.
So you're not doing any authentication there.
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 in OAuth or OAuth 2.
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 OpenID Connect is sort of a superset of OAuth 2.
And so OpenID 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 OpenID Connect because that's, in some ways, it's the more simple one.
It's the more basic one.
Yeah.
OpenID Connect is used for signing a 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 in 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 go to Office 365 and sign in, it asks you for your username and password and you type those in.
And then those go off to what we have, which is Azure AD, some sort of centralized directory service.
That centralized.
This is super common in large enterprises.
They've got an active directory that like owns the definition of identity for like the whole company and everything somehow has to talk to it.
Yep.
Or same with your Gmail, right?
Let's use Google and let's use Gmail because that's probably, that's going to remove the confusion of organizational stuff for the moment.
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.
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 when 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.google.com plus this long URL that comes after it.
The part of that path of the URL is what 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 who this user is.
So I'm going to go look at my application database and pull back email and pull back tags and that sort of thing.
And so that's OpenID 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 start showing 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.
All right.
They read their email.
They send email.
But just what data do you have access to?
Not can you administer Gmail for other users and stuff like that?
Like 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.
Yeah.
And like the business version of Google, their apps, Google apps.
Yeah.
So once you're signed in, 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 JWTs, for example.
See, I can't talk about Google with a Google phone sitting next to me because it thinks I'm talking to it.
Here's some things I found for you.
Let me check that on the web.
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 the JWT world where you get a JWT, 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.
All 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.
That's right.
Cool.
All right.
Let's go next to federated identity.
So what you'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, say, an API, 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.
I'm like, 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 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.
And logically we are, but technically you never are.
So let's go back 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 in this 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 you as a developer of the Gmail application, you go and talk to the identity system for the other party.
So in our case, Azure AD and Outlook.com 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 and 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 OAuth services and APIs 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.
OK.
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, of course, we offer.
There are others like Okta and Auth0 that are all sort of identity as a service.
So those are service providers who are offering a full holistic SaaS type thing, software as a service where.
Yeah, I'm on the fence about Auth0.
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.
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 say anything about it.
Yeah, you don't have to say anything.
But it's like you pay a little bit like the mail list companies like MailChimp and Drip and ConvertKit, all those things.
You're like, this should be pretty affordable.
And then all of a sudden you're like, why am I paying $400 a month just to have 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 it sort of felt to me like that.
Yeah.
Anyway, sorry, it's a bit of a diversion, but.
No, it'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.
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 didn't want to be fair to Auth0, but also let people know.
So I just looked at their pricing.
They're up to a thousand users, which is not a lot.
Like if I, you know, like Talk Python Training is way more than a thousand users, $23 a month.
But just 5,000 active users is $1,000 a month for identity.
Oh, that is a lot.
Like if it's, yeah, if it's over 7,000, 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 ADB2C, 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 won't be a big deal.
Yeah, for sure.
And one of the things about these systems is that the convenience that you get of not you having to manage the deployment, the maintenance 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 say, you know, 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?
And there's no 100% security.
So as close to 100% you get, that's great.
Yeah.
And it's with everything.
I think where 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're like, well, we're going to 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 had a customer I worked with a while back and they had a really old legacy app that was ColdFusion 10 and couldn't be moved past ColdFusion 10.
Impressive.
Yeah.
I was impressed it was still running, but they still had a server that would run that.
But the thing is, ColdFusion 10 went out of support before OpenID Connect became a standard.
So there are no libraries for OpenID Connect.
So we helped them write one.
And it's not for the faint of heart.
I mean, 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.
Yeah.
It's super frustrating to debug that stuff, too.
It's like, we don't validate the certificates.
Like, oh my gosh, why?
What is going on?
Anyway, like, I don't want to bring back pain.
So I'll go to a separate therapy session for this.
We should offer separate therapy sessions as a service.
Yes, you should.
For identity developers.
All right.
So let's make this concrete for everyone out there and doing 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.
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, OAuth2, and OpenID 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-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.
There's my understanding how that place works.
So anyway, it's, like, kind of the popular recommended libraries.
And they have an authentication section.
So they've got an OAuth and a JWT 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 interesting 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,
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,
then we do give you MSAL for Python or MSAL 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 OpenID 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.
So MSAL is the recommended for us if you're coming to Microsoft as a fresh greenfield project.
But there's a list of other ones like Authlib, Django, Auth.
There's a whole list, right, of other solutions there.
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 a lot of times you're like,
all right, well, how do I take this random library and integrate it?
So we've got Django-Oauth, which has the moniker JustWorks for authentication in Django,
which is nice.
Nice.
It has all the authentication, right?
There's Django OAuth toolkit.
And it says it'll help you provide out-of-the-box endpoints, data logic,
to add OAuth to 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's nice because it's a generic OAuth library, not just for, say, Django.
But the problem with the generic ones is you kind of got to understand,
like there's the six chains.
There's like these five callbacks.
You've got a hook or whatever, which is a pain.
Yeah.
You don't want that.
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.
So there's a Django OAuth toolkit, which wraps that.
There's the Flask OAuth and Flask Dance, which wrap this one.
There's Pyramid-OAuth 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 API surface where our library is fairly, it's fairly light.
It's sign in user, 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 OpenID 7 and OAuth 9, you can just keep the same API.
Exactly.
Well, a great example.
So for a long time, there's been something called the implicit flow in OAuth.
And the implicit flow was the least secure flow of all of the ways you can use OAuth.
And there's a new thing, authorization code with PKCE, you hear called Pixie a lot, where
you don't need to worry about what the flow itself actually does.
It obviates the need 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.
Then 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 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.
Yeah, that sounds great.
So one other place I want to give, one other 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 Pydantic data exchange models with validation and automatically
binding like a JSON post over to it.
But it also comes with OAuth 2 scopes directly built in.
So it lets you work with 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 OIDC, OpenID Connect,
or OAuth 2 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 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 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, a web client or a
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 APIs.
Yeah.
Because one of those, you're just receiving something you need to check.
And the other thing, you need to handle the actual acquisition of one of those tokens.
Right.
Which can get tricky.
Like that provider over there said their email address was this.
So I'm going to 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 definitely want to have a short conversation, especially with you, Christos, because we went
off on this before we hit record about depending on basically social media for your identity
in 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 Twitter, or you can use Google, or you can use Microsoft
or whatever.
How does that make you feel?
You like it?
You're a fan?
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.
All 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 or lose my password?
Exactly.
To me, I don't feel that way because it's a 40 character randomly generated thing.
True.
If it gets lost, 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 in a year, like, did I use Google or did
I use Facebook?
And every time you actually go back and use a different social media account, it creates
a new account for you.
So you might log in with a new account and suddenly like, where's my basket?
Where are 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 and you said, ah, I feel like Twitter is the one I want to
use.
Yeah.
Right.
So you said Twitter.
And you created an account and it knows your Twitter.
And then you go back here and you're like, gosh, I could log with Twitter, Facebook,
GitHub with all this.
Probably I chose Facebook and that is a totally different account.
It's as if you used 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.
But at the same time, it creates a bit of a lock in.
So if I decide to delete my Facebook account for whatever reason, if I decide to stop using
Google from now on, then that means everywhere I sign with my Google account is now not accessible
anymore.
So I have to go and create a brand new identity for me.
So to people that 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.
The danger is like, you're not going to have your password dumped on have I been pwned and
like haste bin and other random places.
If it gets hacked, if you 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.
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, but me and my old account is totally gone.
And so anything that I had authorized there would 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 on Facebook.
And so for a while, it was sort of the wild west of, oh, you can sign in 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 our privacy policies.
We work with this.
Oh, God, in the UK, but there's like some analytics.
Yeah, I don't know.
I mean, I forgot the name of the cup, but the whole one that around the DNC and not the 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 and it's going to 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's site.
Well, at least I know that password, you know, 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 in 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 or password.
I can only log in with Facebook.
Oh, 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 to do Facebook, that's an incognito window to Facebook.
And then I close that down.
Right.
Yeah.
Good idea.
But now I've got to stay logged in if I go.
I mean, I got to 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 an 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 long in time here, but been really fun to talk about identity
and the broader sense with you guys.
Absolutely.
And it's been a blast being here and talk about identity and how to keep you off the
news.
Yeah.
All right.
Before we get here, if you're going to write some code, I'll just, since there's two, I'll
just ask the one, although who knows, it might be the same answer.
We'll see.
If you're going to write some code, some Python code, what editor do you use?
I would probably go with VS Code.
Okay.
Because I am more comfortable with that.
I haven't really used bytes or mats and I haven't really done a lot of Python production
work to say that.
So that will be the convenient one.
However, we are working with JetBrains these days to actually improve the Azure experience
inside PyTorch and PyCharm.
Yeah.
PyCharm.
Yeah.
Awesome.
Really?
I didn't know that.
That's cool.
Yeah.
So we want to bring it in to everyone.
Yeah.
So use the tools that work best for you.
Yeah, absolutely.
John, how about you?
Do Jupyter notebooks count?
Yeah.
They absolutely count.
Sure.
In the browser.
Yeah.
No, I mean, 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 I kind of love
it for that because it's so much easier than Scala.
And I tried to do Scala once and I was really quite miserable.
And then I was like, I'll just 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 fall to VS Code.
Excellent.
All right.
Well, that's definitely a popular answer these days.
All right.
Final call to action.
People are interested in 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 or something.
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 want to tell folks about that real quick?
We'll put the link in the show notes.
Sure.
It's every Tuesday and Thursday at 7 a.m. Pacific, 10 a.m. Eastern.
And usually Tuesdays, we build something.
Right now, we're working on a multi-episode project of building what we're calling the Thrasman, which is the Azure Resource Thrasher, which 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 off a cool project that somebody in the community has 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.
When are you going to come on the show?
Come build something with us.
Oh, yeah.
October 20th.
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, it sounds good.
We'll do some Flask plus OpenID Connect or something like that.
Yes.
Awesome.
All right, guys.
Thank you for being on the show.
It's been a lot of fun.
Thanks for having us.
Thank you for having us.
Yeah, Yvette.
Talk to you later.
This has been another episode of Talk Python To Me.
Our guests in this episode were Christos Mathkes and John Patrick Dendison.
And it's been brought to you by us over at Talk Python Training in Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Visit talkpython.fm/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 that 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 podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.