Bobby Johnson introduces us to modern identity and the use of external providers to outsource your authentication layer.

Hello, and welcome to another episode of adventures in dot net. I'm Sean Clabo, your host. And with me today is your cohost, Wai Lou. Hey, Wai. How you doing?

Yay. Good. Good. A little bit different time than than we normally record, but I think it's working out for the the 2 of us. Yeah.

Caleb couldn't make it this week. I guess he had a a dinner that he had to, go to. I'm hot to you guys. Sometimes you you gotta you gotta pay attention to your friends and family. So Yeah.

Alright. So today on the show, we've got a good guest. His name is Bobby Johnson, and we're gonna be talking about modern identity. Hi, Bobby. How are you doing?

I'm doing really good. Thanks for having me on. Oh, thank you. It's great to have you on the show. So the topic for today, Modern Identity.

Let's first start off with what's your background, what kind of things that you do, and Yeah. Sure. How you got into this industry? Yeah. So I started out doing web development in the, mid nineties, predominantly on the Microsoft stack.

So I started out with ASP classic, moved into, Web Forms, then into MVC. And throughout that whole period, I had a a strong interest in open source. I I like to go to conferences and and publish anything that I write. I was a a big con not a contributor to InHibernate, but a big proponent of InHibernate back in the day. I was involved in alt.net for quite a while.

We helped organize a couple conferences several years back, and I've, spent some time in, enterprise software development as well as, start up software development. So a company that you might know that I've worked for was, cheeseburger.com. That was one of the startups that I worked for. I tend to like working in the startup space because I like having my fingers in all the pies. So but they're not as stable as enterprise development.

Right? So references, I guess. Yeah. What what what is cheeseburger.com? It sounds like an interesting, cheeseburger.com was a meme site when meme sites were cool.

There was a a suite of, like, 70 different branded sites all with tailored content to specific audiences. The big one being I Can Ask Cheeseburger, which was mainly cat memes. Okay. And is it still around? Is it, we go they had ended up getting sold off to the same company in Israel that owns, Ebom's World Oh, okay.

If you're familiar with that website. Yeah. So, yeah, I ended up leaving out of there, going back into enterprise for a little while. And I don't know if you guys know him or not, but do you know Glenn Block? Former Microsoft guy worked on the MEF team.

Anyway, I ran into Glenn Block one day at a conference in, Portland called dotnetfringe, and he was working at Auth0. And he was recruiting for his team, and we got to talking about the needs that he had for his team. And he ended up recruiting me out of the enterprise I was working at the time, and I've been working at Auth0 for about two and a half years now. Nice. And and what is Auth0?

Auth0 is a identity server for rent. So we will do all of your identity needs in the cloud so that you don't have to. Okay. Like an authentication of the service type? Uh-huh.

Okay. So the topic, like I said, we're talking about, modern identity versus classic identity. So I guess how identity has changed over the years? Oh, identity has definitely changed over the years. And, you know, most people when they think of identity, they think of username and password, but it goes well beyond username and password to things like active directory to SAML, OAuth, and OpenID Connect.

And all of these kinda, you know, jargon that I'm kinda throwing at you are intended to solve specific use cases in the identity realm. So, yes, username and password is still in use, but OAuth layers on top of that in such a way to facilitate a type of interaction that wasn't possible before. Right. Nice. So this episode, I think, really, it came timely for me because right now, I'm doing all my authentication against LDAP.

Mhmm. Just cookie based authentication. And, you know, one of the tough things I think a lot of developers find with authentication and and authorization. A lot one of those things is they don't do it very often because, like, the application the the project that I work on, you know, we started it 6 years ago. And since then, we've just kept on using the same authentication.

Mhmm. But now we've got to switch over and start using OpenID Connect. And so I've got to revisit some of these things. And I think this is this episode is gonna be nice for me, But, maybe we should start, you know, defining some of those terms. You know, what is OAuth and what is Sure.

OpenID Connect, things like that. So OAuth for for the layman is a really loaded term because if you go search for it on the Internet, you're gonna find a whole lot of bad information. And I I wanna clearly define what OAuth is for you. OAuth is a delegated authorization protocol, and what that means is let me give you an example. Say, I I am working at the company LinkedIn, and LinkedIn wants to help you grow your network of connections within LinkedIn, that sort of thing.

And they know that, a lot of people use Gmail, and they keep, you know, lists of contacts in Gmail of people that they know, that they've worked with, that sort of thing. And what LinkedIn would like to do is they would like to consume my Gmail contacts to send out invites to people that I know to grow my network on LinkedIn. One way that they could approach that problem is to just ask me for my LinkedIn or my Gmail credentials. Just say, hey. Give me your Gmail username and password, and I'm gonna reach out to Gmail, and I'm gonna pull your contacts in.

And maybe I'll even use Gmail to send the invites out to where it looks like it's coming from you, that sort of thing. And this use case is is very useful. Right? Like, I would want to do that. LinkedIn would want to do that.

Gmail would wanna provide that service. Right? But the implementation there is is really tricky because for one thing, I have to rely on LinkedIn to protect my Gmail credentials. Right? They're not as important to LinkedIn as they would be to Gmail.

The security of my credentials is critical to Gmail because their business depends on it. And what LinkedIn is implementing is a a small little feature of their application. It might not be as critical to them, but the the security risk is even more bigger than that. Because I've given my credentials to LinkedIn, LinkedIn can act as me and do anything that I can do. So while LinkedIn wanted my credentials to read my contacts and send emails, they can also read my emails.

They can delete emails. They could even delete my account if they wanted to. Right? LinkedIn probably would never do that, but I'm just saying the possibility is there because I've given the king the keys to my kingdom. And OAuth was designed specifically to solve that problem.

So what OAuth intends to do is to delegate authorization to a 3rd party on behalf of a user without exposing that user's credentials to the 3rd party. And does that sound like it has anything to do with authentication? Yeah. I think you say that. So it's like you got a group of friends, and this third you know, one friend is somebody that you both trust.

Right? Mhmm. And then, one says, okay. My name is George. Well, my name isn't really George.

Mhmm. So my friend that the other guy trusts is gonna say, no. That's not George. That's Sean. Mhmm.

And is that kind of the the path that's going there that there's they both have to trust this, like, 3rd party? Or Well, in this case, the 3rd party is LinkedIn. Right? So I'm the user. I'm a Gmail user, and I want to grant access to my resources on Gmail to the 3rd party LinkedIn.

And the resources I wanna grant them access to are my contact list and the ability to send emails on my behalf. So, like, Gmail is the identity of the provider in this case. So it's more Yes. Mhmm. Yeah.

So he's a per he's a he's a common friend I've on track. We're we're starting to get into that miscommunication on the Internet right now. Right? The we're looking at Gmail as an identity provider, but they're not really providing my identity in this use case. They're just providing access to LinkedIn based on what I have consented to give them.

Okay. Right? So, typically, the the flow that you see is you go to LinkedIn and there's some button that says, you know, hey. Send send, invite emails to my contacts. And you click that, and you get redirected to Gmail.

Yeah. And your browser is pointed at the appropriate place to consume your Gmail credentials at this point. If you're not logged in to Gmail, Gmail asks you to log in. You provide your credentials. You're giving them to Gmail, not LinkedIn.

And then Gmail will pop up a dialogue that says, hey, user. LinkedIn has requested access to your contact list and to send email on your behalf. Are you okay with that? And you can click okay. And then you get redirected back to LinkedIn with some OAuth magic that that grants that permission between the two parties.

So so given that LinkedIn kind of has to implicitly trust Gmail, is there any kind of, like, background work that has to be done? Like, is there some sort of trust that has to be established between LinkedIn and Gmail? Absolutely. Yeah. So to to accomplish this through OAuth anyway, LinkedIn as a entity would need to come to Gmail and register as a known client, and Gmail would issue them a a client ID and a client secret.

And they would provide those credentials in the background when they're communicating with Gmail directly. Okay. Yeah. So one big catch here and one of the differentiators between OAuth and OpenID is that the access token that gets issued by Gmail, OAuth doesn't really give you a specification for the format of that token. All it really says is that if a client presents the token, the resource will accept it.

So the only way a client can use an OAuth token is to send it back to the source of that token. OIDC does have a specified format for its tokens. It's a JSON web token. We call it JWT for short. And so the token in OIDC has meaning to both sides of the of the communication.

So it's appropriate for OpenID Connect, ID tokens to read them and pull information out of them. So the the the the differentiation I wanna make between the 2 is is this. I'll state it really clearly. OAuth is a delegated authorization protocol, and OpenID Connect is an authentication protocol. I'm using a third party to tell me who a user is.

So the communication that comes back has meaning to the application. Okay. So so we send that OAuth is for that that first example where you wanted to just drag contact list out of Gmail. You don't really need Gmail doesn't need to know who who is asking for it as long as you have that access token, and you should drag the information. Whereas OpenID is more for for LinkedIn verifying that you logged in from a from that particular Gmail account.

Let's stay with the same scenario of, Gmail and LinkedIn. Right? And say we're we're just gonna talk about OpenID Connect for a moment. And the engineers at LinkedIn decided they no longer want to maintain a username and password store in their database. Right?

They had some kind of security leak. They panicked. They don't wanna handle that stuff anymore. What they can do is they can instead, through OpenID Connect, say that all users are now going to authenticate through Google, and Google will maintain their username and password. We're kinda delegating the authentication out to Google, and they're providing us the identity of the user.

So there are no username and passwords in this LinkedIn example at that point in LinkedIn. We're just relying on Gmail to authenticate that user and tell us who they are. Right? So it's about authentication. It's not necessarily about, authorization.

You see the difference I'm trying to split them? Yeah. Yeah. Definitely. Yeah.

You you it's actually Gmail is is the authenticator in this case. And LinkedIn doesn't care, who the person is as long as, that he that they've got that open ID JWT token to say that, Gmail has actually logged him in. And it doesn't matter, I guess, whether they're logged in via MFA or fingerprint or password. They just trust, Gmail has done its job to authenticate them. Yes.

So long as Gmail says that user is valid, we can trust the information in the the token itself. And there are several ways to validate that trust as well. Right? K. So OpenID Connect allows to use a third party for what people typically used as username and password.

So OpenID Connect allows you to rely on an identity provider to provide you with identities in the same way that you rely on active directory to provide you with identities of your user. The difference is you're doing it over the public Internet, which you could do with, like, Azure AD and some tweaking. Azure AD also offers OpenID Connect for being able to do this. Right? Yeah.

I think, going back to what Sean was saying about how, like, developers, don't have much experience in this or that, you know, it's it's not saying they're working all the time. I'm I'm I'm so I'm actually so glad that that these these authentication of the service things that exist because Mhmm. As a developer, like, I I'm totally lost on authentication and I'm not confident in my own skills to to be able to do it properly and do it Mhmm. The latest software patterns and all that stuff. So so I haven't used Auth0 yet, but I've used I think I've used Firebase authentication.

I've used Azure AD and all that stuff. And it just it really just it allows me to really outsource that that part of it that I'm just just not smart enough to to understand. You know? Well, I I I would challenge you on that. I I do think you are smart enough to understand it.

There's just a lot of knowledge you have to gather to do it correctly. Right? Yeah. And when I'm giving a talk, like, at a a conference, I'll say, something along the lines of, you know, the the developers who are having to interact with identity don't have a desire to be an expert in identity. They just wanna get to the features they wanna build.

Right? Identity is kind of an infrastructure concern for them. Yeah. Yeah. Yeah.

Then you can focus on your own, you know, business value adding activities. So Mhmm. So as developers, are we typically gonna work with OpenID Connect versus OAuth? Well, it depends on the use case that you have. Are you simply wanting to authenticate users in your application?

Then OpenID Connect is all you need. But if, say, you have, APIs that you'd like to secure as well, well, then you're gonna have a mixture of OpenID Connect and OAuth. Mhmm. So APIs use OAuth? Well, you get an access token, which gives you access to an API.

So you can send that token along with an API request, and the API will validate that token. Yeah. So I think, in in the Gmail example, the the API is things like the contact list or send an email and all that stuff. And I guess all that stuff is defined by by Gmail on a specific app by app basis. And there's no there's and there's no generic there's no, like, language for OAuth.

It's just the the OAuth provider will just define this API to to to say for for this app, you need this particular access to to access this particular functionality. Typically, in OAuth, you define the the things that a client can do on behalf of a user in terms of scopes. And scopes are are related to permissions and privileges, but they're they're slightly different. And I'll I'll give you an example. Let's try to define those three words.

So permissions are what someone can do with a resource. So, for example, with maybe, Google Docs, you can read a document, you can create a document, or edit a document. Those are things you can do with the resource. Yep. A privilege is permissions for a resource that's assigned to a user or an application, because applications can communicate with each other.

Right? So applications can have privileges as well. An example of that would be Bobby can read documents and create documents. So me, personally, I can do these things within the system. Note that I can read and create, but I can't delete.

Right? Even though it were the system, the resource is capable of deleting a document. I personally don't have the privileges to do that. Yeah. Scopes are permissions an application ask a user to delegate.

So LinkedIn would like to read my Gmail contacts on Bobby's behalf. Yeah. So effective permissions in that scenario are, user privileges union with the consented scopes. So the things that user can do along with the scopes I allowed that application to have on my behalf. Does that make sense?

Yeah. There's definitely a lot of jargon in this space, and I find myself having to define those quite a bit. So in in terms of effective permissions, just to give you an example of that, Bobby is okay with LinkedIn reading contacts on his behalf, and Bobby has privileges to read the contact requested. Yeah. That makes sense.

So so when when a user logs in, like like, you're saying that, like, let's say, LinkedIn is using Gmail or Google for, authentication. Mhmm. So they actually from from a website level, they they click on the login button. They'll get redirected to to to Gmail, won't they, to actually do the login. Is that right?

That's correct. Okay. And how does Gmail prevent, like, someone from just creating a fake Gmail page and then entering their credentials in? Sure. So OpenID Connect is actually built on top of OAuth.

So it adds some primitives and, a couple endpoints to your authorization server for achieving single sign on. So OIDC communicates with Google the same way OAuth 2 does. You have to register. You get client credentials, and those credentials are sent with the communication to Gmail. Okay.

Now I need to disambiguate that a little bit. When I talk about client credentials, we we have a a distinction between a confidential client and a public client. So a confidential client is any application that can prove its identity to the authorization server, meaning it can send the client ID and client secret in a secure method. So if you're thinking back in the days of, like, PHP or, Web Forms, now you have a web server that can reach out to Google's API and communicate with it outside of a user machine. Right?

So that that would be a confidential client. A public client, on the other hand, would be something like, your cell phone, an application running on your cell phone, or maybe even a single page application. Those are not secure enough to be able to store a client secret. So there are some different grant types within OAuth for each of those client types. To answer your question, we need to just kinda define, well, what how are we attempting to authenticate?

Are we doing it from a a confidential client or a public client? Because it changes based on which one you have. So with the confidential client mainly be your back end? Yes. Mhmm.

So you the user would log in from the front end. I'd give you a token. You'd you'd authenticate them. And then let's say you needed more information from the identity provider, then you'd use did you then the back end would act as a confidential client to communicate with, Auth0 or In the terms of a a confidential client, you're probably going to be using what's called the authorization code grant. Yeah.

So let's just kinda quickly run through what that means. User clicks the login button, and they get directed to link Gmail. They log in. Gmail gets their consent, and then they return the user back to LinkedIn through their browser with what's called an access code or authorization code in the URL that they're using for the redirect. So in the query string, there'll be something like authorization code equals some string.

Right? And that string is okay to go through the browser like that because but the string alone cannot be used to exchange for an access token. So I I get redirected back to LinkedIn. LinkedIn's back end then takes the code along with its client credentials and queries Gmail directly with the 3 to get an access token back. So the access token never goes out to the, browser itself in that case Yep.

Which would be different with a single page application. Right? So you have a, a server that's capable of maintaining state so that the access token can sit there, and it also can secure its own client credentials. Okay. Yeah.

So I think most developers are gonna be in our scenario, they're gonna be developers for, like, LinkedIn. Mhmm. So they're trying to set up their application so that somebody can log in using Google credentials. Their yeah. Their Google account, basically.

Right. Right. So for those developers, you know, what does it take to get started and get their application set up so that they can then use either Auth0 or Google or something like that to handle those credentials? So because the combination of OAuth and OIDC are very well specified, you're typically gonna be using an SDK to handle most of these interactions for you. So for a developer, who maybe wants to, interact with Gmail or Google to do authentication, they're gonna pull down a SDK.

They're gonna go to, Google, and they're going to register their application with them and receive client credentials. And then they're going to pass those client credentials around each time they're interacting with with Google directly. So with the SDK, you know, there's probably some good documentation out there for for using that. Mhmm. Is there also a lot of providers?

Do they have, starter kits or things like that so you can actually see examples of code that's written and Yeah. Well, I I don't wanna sound like I'm hawking Auth0, but, yeah, we we have it's okay. Okay. Basically, when you when you sign up for an Auth0 account, you'll go in and you'll you'll create an application there, and we give you quick starts, which basically show you the SDKs for your particular programming environment. So if you're in Java or dotnet or Node or something like that, we have quick starts for each one of those platforms for implementing authentication and and walk you through it.

Nice. Well, I'm stuck I'm still stuck in classic ASP. Is there something for me? No. Absolutely.

We we support PHP, which pretty much is very similar to classic ASP. I'm not sure we have an SDK for it though, but I'm sure we would accept community contributions of it. Alright. So we we we talked about tokens. You know, what kind of information comes along with those tokens and how can they be used?

Sure. So there are 3 tokens when we're talking about the combination of OAuth and OIDC. OAuth itself defines 2 types of tokens, an access token, and that's the thing that you send along, with a request to an API for, you know, fetching and and interacting with data. That token, like I mentioned before, is opaque. It really only has meaning to the API that you're calling for.

It doesn't have meaning to the client itself. It also defines something called a refresh token. If you've ever gone through an OAuth flow where, you know, you get a consent screen and the that consent screen says something about offline access, then what you're requesting in that point is a refresh token. And what that allows you to do is exchange the refresh token for a renewed access token because, usually, access tokens are very short lived. You know, you might have your access token last 3 minutes or a day, but a refresh token is very long lived and allows you to be able to get new access tokens.

OAuth came along and added an ID token to the mix. And an ID token, like I said, is formatted using a JSON Web Token, and it's going to carry information about the user. It's going to carry information about, like, your name, your email address. And the the token is a JSON Web Token formatted, which means that it's assigned token that comes along so you can validate it in your client. Isn't that what the OpenID Connect thing is instead of Yes.

Mhmm. So ID tokens were added by OpenID Connect. Mhmm. Oh, okay. So going back to access tokens and refresh tokens, I've always been a little bit confused.

So, like, you're saying that the refresh token is this thing that you're supposed it it has to be it needs to be more protected than the the access token because the access token is just a like a it's just for one call, but the refresh token is saying that you have to keep is to to generate their access tokens? Yes. So when when we talk about these things, we kinda talk about the blast radius of a token actually escaping into the wild. An access token leaking out, you know, is not a good thing, but it expires in a certain period of time. So if you're worried about your access tokens, you know, leaking out and you want to kinda lock them down, you can set the expiration smaller and smaller.

They don't necessarily have to be one time use, but, say, you set them to 30 seconds. And so if that token gets out, it's only going to be able to be used nefariously for 30 seconds. Mhmm. Right? A refresh token, the blast radius is kinda big because you can use it to generate new access tokens.

So you want to store them more securely than you would an access token. And would a refresh token have an expiry date as well, or would would that just last forever? You can have an expiry date on a refresh token, but typically, they're very long lived, like maybe 6 months, a year. Oh, yeah. So just just wondering then.

Just taking example of a like a spa app, like like an an an Angular or Vue spa app. I log in to, off the URL, I get that token. Is that a refresh token or an access token in in that case? So if you're working in a a single page application, you're going to be using 1 of 2 OAuth grant types. You're going to be using the implicit grant type or you're going to be using the auth code with proof key for code exchange.

Neither of those grant types allow you to get a refresh token. Okay. So it is just an access token. You never wanna send a refresh token to a public client. Oh, okay.

That's only for confidential clients. Exactly. Yeah. Sure. And then once I've got the access token, never be sure where I'm supposed to store it on the on the browser.

Like Mhmm. I've heard local storage is actually not a great place to store the access token. Is that true? Or if so, where should I be storing it? That is true, actually.

Local storage is available or vulnerable in a number of ways. So storing your access tokens in there is is kind of not a good idea, especially if you want to have a high level of security. So if maybe you're running an ad network in your site or something like that in JavaScript that you don't own gets run on your page, they have access to the same local storage as as your JavaScript. Right? So our recommendation at Auth0 is to store access tokens in memory.

So what what I mean by that is just a variable in your JavaScript that holds the access token for the duration of the session. When you refresh the page, wouldn't it wouldn't you just would would you just have to reauthenticate again? Or Well, there are ways of working around that. Yeah. So because you have authenticated with the identity provider and you have a session open with the identity provider itself, you can rerequest the access token directly behind the scenes without the user having to reauthenticate.

So if you refresh the, browser, you can reach back out to the identity provider and get a new token Yeah. As long as the user's browser has a session with the identity provider. So I guess there's a little bit of performance delay from from a in in that scenario, but being being a smart spa app, you wouldn't normally refresh the page anyway. Right? So Sure.

Yeah. I I wouldn't say the the performance is huge, like a huge hit. You know, you just see some flashing on the screen, for a second or 2. Mhmm. But, yeah, that's that's what we recommend doing is not storing it in local storage, but just maintaining it in memory.

Mhmm. Okay. And what about cookie storage? Would would you recommend doing it there? If you can, yes.

Absolutely. If you're interacting with all first party applications, meaning the single page application is communicating with a back end that you own and they're on the same domain, then absolutely send the access token down as a cookie. I mean, cookies have been around for, what, 20, 30 years now. We we understand how they work. We understand how to secure them.

So where you might trip up in that is if you need to use an access token to consume a resource on a separate domain. So that cookie is not gonna go along with that request, right, because it's for a specific domain. Yeah. For sure. Yeah.

Mhmm. So these, tokens, are they subject to, like, man in the middle attacks? Well, they could be. Sure. But if you're not validating the tokens.

I'd an ID token specifically comes with a signature that is exposed the signing key is exposed by the identity provider itself, and you can actually validate the signature with the payload to verify that it hasn't been tampered with in transit. Though I'm specifically talking about single page applications in that instance. With a confidential client, you don't you you probably still wanna do some validation of the token, but you're probably communicating back end to back end over TLS, so there's less of an opportunity for a man in the middle attack. I think most even even most web pages would probably be using HTTPS now anywhere. Right?

So that man in the middle thing is probably unless unless you're not using HTTPS, it's probably not a not a real threat. So Mhmm. What I was thinking is that, say, Google or me as the user wants to not allow LinkedIn to do these things anymore. Mhmm. Can those those permissions and tokens be revoked?

Absolutely. Typically, you would go to the identity provider that you've given consent, from, and you revoke the, consent. And that's one of the other nice things that refresh tokens actually introduce into this mix is that we have to hand the refresh token to the identity provider to get a new access token that gives the identity provider to check that revocation list and say, oh, no. I'm not supposed to issue them anymore. Okay.

So when when you log in to it, like, your own your own back end via an access token, your back end will actually speak to the attendee provider to make sure that that token the access token that that was given to you, is still valid. Would that be true? Typically, you you can do that. You can do some form of introspection where you're sending the token to the identity provider for them to tell you that it's, valid, but that introduces a lot of network chattiness. So, typically, we try to leave our use our tokens in a stateless manner.

So the identity provider gives us their public signing keys, and each token is signed. I'm talking now on the OAuth case or, auth 0 case. Yeah. Each one is signed. So if I get their public keys and I get a token, I can then validate that token without actually having to communicate with them.

I can cache the keys for some period of time. Yeah. But if you do that, then you can't revoke it until that cache is is, like, expired. Right? That's correct.

Of the access token. But remember, access tokens are intended to be very short lived. Yeah. Sure. So you have a small window of of blast radius.

Mhmm. Another question I I had was so we've talked about, like, LinkedIn trusting Gmail and stuff. But for for me, like and maybe it's just bad user behavior. But every time I go to a site and it says you can log in with Facebook or I can log in to Gmail, I don't like doing that. I don't know.

I don't know. I just feel like it's kind of I I don't wanna be giving Facebook or Gmail any more information. So I'm wondering, like, as an identity provider, aside from knowing what websites you're logging into, which I assume they can they can do, is there anything else that you're giving to if you when you log in to Facebook or you log in to Gmail, is there any information that you're giving to Facebook? Well, it's all wrapped up in the scopes that the your application your consuming application, the client is requesting authentication point. Right?

Sure. That's the Facebook consent screen is going to pop up and tell you this is all of the information that the client has requested. Yeah. When you you give consent, we're gonna send them all of that information. Okay.

So the only thing you're giving you're letting Facebook know is that you've tried to log in to that page or you tried to give the contacts your contact list in this particular website, but nothing else. Like, there's no other communication between the websites or any data being passed? Yes. I mean, the intention of OAuth is the user grants consent to the data they want to be available to the client. Right?

So the the choice is in your hands. Now there are definitely some nefarious ways of prompting people to, give me more scopes, but you're you still have to grant that consent to do it. And, you know, logging into Facebook and logging into Twitter or, logging in using Facebook or logging in using Twitter is not the only use case. Right? At Auth0, we have the G Suite accounts.

Right? And that's our primary identity across the entire company. I log in to Slack using my G Suite account. I log in to Expensify to log all my expenses using my Google account. Sure.

Right? So it's not just about social scraping of your data. It's just about having one central location of identities that allow me access to all the applications to be able to do my job. Yeah. And I think at the end of the day, that's actually a like, despite my reluctance to log in to other websites using Facebook, I think that's actually the safe way because it means that only one website has has the built like, has my password, I guess, which is Facebook.

And, you know, I'm I'm, you know, I'm not sure whether I trust Facebook as a company, but I do trust them to to protect my identity at least because, you know, if if they if that leaks, then they stand to lose, you know, 1,000,000, probably 1,000,000,000 of dollars kind of thing. Well, there's another way to look at it as well. Right? If you're using your Facebook account to log in to Twitter and to log in to Twitch and to log in to Reddit and all these other places, you have one place to go change your password that secures all those places. Right?

Yes. So, you know, you go on to have I've been pwned, and you put in your email and password. It's like, oh, no. I've leaked. You can just go to Facebook, change your password, and you're good to go.

The other benefit is that for a small development team, Facebook has a much larger dedicated team to identity and securing identities. Right? So you can kinda leverage their skill set and their effort for a very small cost within your application. Yeah. And you can I guess, there's all these features like like MFA and and all these things that if you didn't use an identity provider, you would have to implement yourself?

And that would be probably much, much more expensive than just using an authentic Futurata. So Sure. One of the interesting things we're we're talking about OAuth and, OpenID Connect specifically. But where these problem spaces get really interesting in working with is when you have different protocols that you need to authenticate folks through. There's WS Fed, which you guys might be familiar with for federating identity around a, Windows network.

Yep. There's SAML, OpenIDC, and username and passwords. If you needed to support each one of those protocols to be able to access all of the applications within your organization, that can get very complex very quickly. And so identity as a service provider like, Auth0 or Ping or Okta kinda solve those problems really nicely for you. You let us deal with that complexity, and your application only needs to really be concerned with OpenID Connect and OAuth.

Right? So your surface of interaction is much much smaller at that point. And that's where a lot of our big customers come from. They have problems like that. You know?

They started out with one product that they used maybe username and password, and then they acquired another company that only supports SAML. And then they bought an application off the shelf that only uses OAuth. Right? And now they've gotta manage all that complexity. Well, let us deal with that sort of thing.

Yeah. Sure. So another an analogy that I think a lot of people might be familiar with is, like, on your phone when you install an app, it says, you know, this app wants permissions to your microphone. This app wants permission to your contacts. Mhmm.

Each different little thing, and those are the things that come along with that, what you're giving in the token between Google and LinkedIn. Correct. Yeah. Those would be the equivalent of a scope. Right?

Mhmm. I'm getting it. Yeah. It's not dirty as mud anymore. Nice.

You're doing good, Bobby. My work here is done. So what kind of things does, you know, Auth 0 help out with, along these lines? Is it just, you know, identity provider or is it does more than that to help out the developers? We will help you with authentication of your users and with protection of your APIs.

So we act as both a OAuth provider and an OpenID Connect provider. And then we can also reach into your 3rd party identity providers depending on what the protocol is that you wanna use. So say you have internally, you have active directory that stores all of your employees. Well, we can reach in there to do authentication and maybe pull out some profile information. But then you also have a large customer base that is maybe that customer authenticates via username and password in an application that, you know, stores that logic in, SQL Server.

Well, we can bridge that gap for you as well, and then your applications and APIs only need to know about Auth0 and OpenID Connect for authentication and OAuth for authorizing access of APIs. So we kinda simplify your identity blast radius for lack of a better word. You know, you there's only one protocol you need to deal with, and we'll just connect in seamlessly to all the other protocols that you need to work with. Mhmm. So So then for new users, they'd all be re directed over to Auth0 to create an account?

That's correct. Yeah. You can customize the UI. We have a full suite of user management tools, like create an account, I forgot my password, reset passwords, MFA. All those things are built into our platform, and all of it is customizable, and we also offer custom domains.

So from your end users point of view, it still looks like they're going to your domain for that authentication. You would just have some subdomain like, accounts.example.com. So is there a it's a how how what's the pricing structure? How what's how do you guys monetize? Is it like it's like a freemium thing where Sure.

We definitely have a freemium model. You can get in and start playing with it absolutely free. The next step up from that is the Developer Pro account, which I believe right now cost $29 a month when we bill typically on active users per month. So someone has come and logged in at least one once in a month. That's one active user.

Yep. And then we have some the enterprise features that I spoke about, like reaching into active directory or integrating with SAML. Those tend to be enterprise pricing, and you need to actually talk to a salesperson about that. I don't get involved in that stuff. Yeah.

Alright. Any other questions why? I I I'm doing pretty good. I'm I feel a lot better now. I've got a lot.

Yeah. About 45 minutes ago. Awesome. Well, hey, you guys are are welcome to reach out anytime. I'm on Twitter.

I'm on my own website, and I do Twitch live streaming. So feel free to opt in and ask questions. Yeah. Let our listeners listeners know how to, to get you there at Twitter or Twitch or things like that. Yeah.

Sure. So my, Twitter handle is not myself, same for GitHub. My website is I am not myself, and I'm a member of Jeff Fritz's, LiveCoders team. So you can find my Twitch channel at not myself dot livecoders.dev. That's not confusing at all.

Yeah. Yeah. I've been known not to sign up to a website because I can't get my username. Yeah. There's not too many Bobby Johnson's around?

Oh, no. I mean, not myself. Yeah. Yeah. You're not yourself.

You're not Bobby, but you're not Bobby. Yeah. Yeah. It's it's it's kind of an inside joke for myself. I I grew up in a very small town in Northwest Arkansas, and I did a lot of chicken farming in my formative years.

And so I moved out to the West Coast and got into tech, and I'm making, you know, tons of money. And, obviously, the life I'm living is not mine. I'm I'm not that guy that grew up in Arkansas anymore. So that's that's kinda where it came from. Good thing.

All right. So I think we should probably move on to picks. I'll be be glad to go first. And, I think you'll like this one. Why?

I've actually been watching a number of Australian TV shows recently. They're probably not new shows, but they're kind of older shows. And one of them I found on Netflix is called Aussie Gold Hunters. Oh. And I watched the gold shows up in Alaska for years years.

And then we found some on Netflix. We found this one, the Aussie gold letters. It's pretty nice. It's actually kind of interesting because in Australia, they don't have the water that they have it up in Alaska. So they've gotta do a lot more dry gold searching and things like that.

And they actually walk around with metal detectors or on the surface. And and through the metal detectors, they're just finding these gold nuggets here and there. So it doesn't look that quite that easy, but, it looks like fun. I'm not I'm not going to quit my job and go do that. But I think gold is worth quite a lot.

If you can find nuggets, probably worth, like, 1,000 of dollars. Right? It could be. Yeah. Yeah.

And there's also been another show that's been on TV here that's talking about opal hunters, finding opals in Australia. And one of the group is in, Coober Pedy. Oh, yeah. Yeah. That's all I say.

Yep. Coober Pedy in Australia. There's another group that's in, you know, New South Wales. So lots of interesting there. So check out if you got Netflix, look at Aussie Gold Hunters.

Yeah. Cool. Alright. What's your pick, Y? Okay.

So my pick this week is actually a it's a YouTube video that kinda just showed up on my just on my recommended list one day. It's called time lapse of the future. And I normally wouldn't just show, like, a just recommend just a normal YouTube video, but it actually kind of just blew me away. So the so the video is about what will happen to the to the universe, like, in the future. And the idea is, like, at start is is like a time lapse.

So one second is is equivalent to, like, 1 year. But then after, like, 5 seconds, it'll double. So then, you know, one second is equal to 2 years, and it'll just keep going and going. And it it actually goes for, like, half an hour. So it's a the time the rate of time just exponentially increases.

And it's just super interesting because it's not really about what will happen in, like, a 1000000 years or even, like, a 1000000000 years. It will happen is it's about what happened in the it's about what will happen with the universe in about like like a 1,000,000,000,000,000 years. You know, like numbers that you can't even kind of imagine, you know. And you know things like it would discuss like things like black holes just kind of eventually evaporating into nothing, you know, every proton in the universe decaying and things like that. So so yeah, I just thought it was just a really really interesting video.

That sounds kind of awesome. I got to check that out. Yeah. Yeah. I saw it once.

Yeah. It it was pretty interesting. So, yeah, definitely check it out. Alright, Bobby. What do you got for pics?

Okay. Okay. So I got 2. I got 2 because, you know, this is probably the only time I'm gonna be on your show, so I gotta do as much as I possibly can. Right?

So and I I have to call out my friends on the live coders team. If you're not familiar with live coding on Twitch, I highly recommend that you get into it. If you've gone to a conference where you sit in a chair and you have someone talk at you sort of thing, live coding on Twitch is is kind of the opposite of that. Live coding is we'll we'll communicate with each other through chat, and I'll build some software and talk through exactly what I'm doing and why I'm doing it. Or I might decide today, I'm gonna learn React, and I'm gonna go read the docs.

So, you know, bring the docs up on stream, and I'm gonna start writing some code. And I'm gonna, like, go through the basics, and my audience can tell me what I'm doing wrong and that sort of thing. And it's really fun. It's really interactive, and there are over a 100 of us in the group at this point who do live streams like what I just described all times of the day on just about any topic you could possibly wanna learn about. So if you check out livecoders.dev, that'll take you to our team page on Twitch, and you can start digging in.

The next one is actually some advice if you use Visual Studio Code and you typically interact with APIs a lot, like using curl or something like Postman. There's a extension called REST client that I absolutely love, and I show people how awesome it is every time, I have an opportunity. So definitely check out REST client as an extension. It is far superior to Postman. Oh, really?

Because I actually really like Postman. So you're saying it's actually better than that? Okay. Oh, yes. Like, originally, Postman was really, really nice, but they kept layering features and features on.

It's gotten quite cluttered. I really like the way REST Client works, like, directly within my code editor, and it's just very easy to use. The interesting thing about it is you can create a file called an HTTP file. That's just a text file with some parameters in it, and you can actually check it in the source code. So, like, as a live example of how to communicate with your API sort of thing, which is really cool.

So that that live coders thing, is that like so is it like a leader that kinda just does the coding, or is it like just hundreds of people collaborating on on a piece of code? Oh, well, they're individual channels. Right? So we're collectively a team, but I would be streaming on my own channel and people come in and watch me stream. And the interaction would be either through chat or sometimes we do pair programming sessions where, like, 2 live coders are on the same team interact or stream interacting with each other.

Yeah. That would actually be interesting, actually. Yeah. How do you how do you get over that being self conscious about, you know Yeah. Actually, let letting somebody see all your dirty laundry coding of all your mistakes and things like that?

Failure is the best teacher. You know, I've been coding for 20 years, and I still use Google to to look something up because I can't remember everything. Right? Yeah. Nobody else sees you doing that.

Yeah. Being a developer is the process of learning. Right? You're always learning new things and showing junior developers and new people to developers. A 20 year veteran still needs to do the same kinda, banging his head against the desk sort of thing is a is a positive.

Right? So I I'm not embarrassed by having mistakes. Sometimes I I do something wrong, and I admit to it. You know? It's a learning process.

It helps with impostor syndrome then? It does for me. Yeah. I think I I I wouldn't mind, yeah, checking it out. But I think if I if I did do a live stream, it'd be mostly me googling stuff.

Like, I'm just just like over, like, half an hour reading up on stuff. So, like Yeah. You know, you don't necessarily have to stream yourself. Right? You can just watch others do it.

Like, Jeff Fritz is a very accomplished live streamer, and his channel is very entertaining. So Mhmm. Cool. Nice. Mhmm.

Awesome. Well, thanks, Bobby, for taking the time out of your day and being with us. It was it was great. I I definitely think, at least in my mind, I'm in better place now than I was. Well, we'll see how after you've slept and how you feel tomorrow.

But thanks for having me on. I greatly appreciate it. Yeah. Yeah. And if any of the listeners, if they wanna reach out to me or or the show, they can find me on Twitter.

I'm at.netsuperhero. So that's a easy one to remember too. That sounds like an awesome streaming name. Alright, guys. Thanks very much, and we'll catch everybody on the next episode of adventures in dot net.

See you. Later.