Is OAuth all it’s cracked up to be? In this episode, the Jabberers sit down with Dan Moore, an expert in the OAuth world. They discuss the GIANT perks of OAuth (even if you’re a beginner), how to fix OAuth’s biggest issues, and what you NEED to watch out for in OAuth if you’re a prospective client.

“The end goal of OAuth is let someone else handle authentication, and based on tokens you get, you have the insurance that the authentication was valid.”
- Dan Moore

In This Episode

1) The HUGE perks of using OAuth in 2022 (and how to get started)
 2) What you SHOULD be looking for in OAuth as a client
 3) How to resolve OAuth’s biggest drawbacks and feel confident in your security
On YouTube
OAuth Explained - JSJ 523

Sponsors

Picks

Special Guest: Dan Moore.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel we have Dan Shapir. 

DAN_SHAPPIR: Hi, coming to you from a very cold 65 degrees Tel Aviv. 

CHARLES MAX_WOOD: We have AJ O'Neil. 

AJ_ONEAL: Yo, yo, yo, coming at you live from the Cave of Wonders. 

CHARLES MAX_WOOD: We need a sound effect that's like magic or something. I don't know. Anyway, Steve Edwards. 

STEVE_EDWARDS: How you doing from Portland? 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. This week we have a special guest and that is Dan Moore. Dan, do you wanna introduce yourself? Tell us who you are and why you're famous and awesome. 

DAN_MOORE:Ha ha ha. Yeah, thanks for having me. I'm Dan Moore. I'm head of developer relations at a company called FusionAuth. And I've been a developer for over 20 years. Started out cutting my teeth on Java and have graduated to a bunch of other different languages. And I'm really excited to talk to you today about OAuth and authorization and authentication in general. 

 

Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with devchat.tv and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. So whether you wanna be an influencer in tech,just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever. I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th, if you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com.

 

CHARLES MAX_WOOD: Awesome. And I'm assuming that's what Fusion Auth does, is it provide some kind of authentication system that you can use as a software as a service plug into your app? 

DAN_MOORE: Yeah, it's basically similar to Auth0 or Okta in that it's standalone user management, authentication, authorization. It's a little different because you can use this as a SaaS offering or you can self-host. And then we have some other things that this is not Fusion Auth. 

CHARLES MAX_WOOD: No fair, but it's nice to get a little bit of context, know what you do. 

DAN_MOORE: Absolutely.

CHARLES MAX_WOOD: So yeah, so we brought you on to talk about OAuth. And I'll tell you that OAuth is something that I use on my apps just because I hate setting up authentication and then worrying about whether or not I left any giant holes. So I pay somebody else to maintain the holes for me in security. In other words, I hope that they find them. But anyway, as we get going, I know that we have kind of a mix of people. Some people have used OAuth. Some people have written either end of an OAuth client or provider. And then some people have no idea what it is. So do you want to just, for people who are newer, give us kind of a high level definition of what OAuth is and what it does? 

DAN_MOORE: Sure. So that, that sounds great. So basically OAuth and I'm kind of using it as a shorthand. There's a, there's some other protocols and RFCs and what I mixed in there, but the end goal of OAuth, they're called grants. Basically what it means is that you can let somebody else handle your authentication and then you get back what's called a token, which is kind of a temporary set of credentials and other parts of your application can consume that token in with the assurance that you the user was properly authenticated and authorized at a central point. So similar to the way that you outsource database operations to something like PostgreSQL or MySQL, you can outsource authentication decisions and authorization decisions to a central I call it an OAuth server. It's also called an authorization server or an identity provider. But anyway, the idea is you centralize your user, basically decision-making at one point. As again, I'm glossing over some things here, but that's what someone who's a consumer, like a client of an OAuth server would really want, right? They just wanna outsource that, not worry about just like you said, Charles, and rest assured that there are other people who've spent time either...the vendor spends time or the protocol designers spend time thinking about security and edge cases and performance. 

CHARLES MAX_WOOD: Right. And then for my end, the other thing that I like is that if somebody, if I feel like somebody's monkeying around with, Hey, here's a token, right? I can send the token back and say, you know who this is, right? And the other end will go, yes, I know who it is or no, I don't know who it is. And then, you know, I can give them access or deny them as I want to.

DAN_MOORE: Yes. I mean, so that's the interesting thing. There's kind of two ways to think about that. Right. The first is that's awesome because you have again outsourced the off decision. The second is, oh, wow. Now you have a dependency on yet another thing. And there are some solutions that are basically engineering trade-offs that you can think about, uh, whether you want to make a technically it's called an introspection call is what you're talking about. You're like, Hey, present this token. Is this token valid? There are other things you can do that are with that stay within your, your server, which is technically called the resource server, I believe, or the service provider, depending on which off thing we're talking about. 

CHARLES MAX_WOOD: Makes sense. So if I'm the job, 

AJ_ONEAL: it's a lot of terms. It's a lot of terms thrown around and they're different between the different specs. You know, I like the OIDC language the best because it's the way I look at it is someone else had said this, but basically, OAuth is a framework for creating security frameworks. And OIDC is actually a specific framework that if you implement it, will work with anyone else who has implemented rather than having all these little caveats of, well, in this one you do this, and in this one you do this, OIDC is, it is the way. 

DAN_MOORE: And it's worth saying OIDC for people who maybe aren't familiar with OAuth is layer built on top of it. It stands for OpenID Connect. So it's taking the OpenID protocol which existed before OAuth.

AJ_ONEAL: No, it's not. It's completely abandoning the OpenID protocol. 

DAN_MOORE: No, no, but it's taking the same kind of ideas of, hey, we can authenticate a user and bring it on top of all. Yes, I agree. They're not connected except for like in the name and in the intent. But no, the actual protocol is different. Totally agree. 

AJ_ONEAL: Right, right. But yeah, the protocol is it is the best that... Well, it's the only one that's actually well defined. That if you implement it, you can be guaranteed that someone else that implements it, it'll work together. 

DAN_MOORE: In your experience, has that been just...Cause implement obviously means a bunch of different things. You mean someone who passes the tests and is certified or you mean anybody who stamps OIDC on there and you know, they're probably going to be a good fit. 

AJ_ONEAL: I mean that, I don't mean certified. I just mean that if you, if you follow the spec for the basic things that are necessary, then the two things will work together and OIDC library will work with any OIDC provider without custom tweaking, you know, whereas back with the, in the OAuth days. You had a separate library for OAuth Facebook and, or Facebook OAuth and a separate library for Google OAuth. And then you had a completely different spec entirely for Twitter OAuth. That wasn't even similar at all to the Google or Facebook ones, whereas at least Google and Facebook were pretty similar. And then you had a different OAuth for, you know, every different provider you wanted to interact with. You had to have, there were some core library functions that you could use that were the similar functions, but you couldn't just...Plug in, okay, here's three details. Now it'll work. 

DAN_MOORE: Sure. And my understanding is that Facebook still hasn't implemented an OIDC provider. Like if you want to use Facebook login, you're still in that Wild West Oauth world, is that your experience or not? Am I understanding? 

AJ_ONEAL: I don't remember anymore. It's been a while since I, since I implemented the Facebook one, but I think Google and Facebook and GitHub, I think are all OIDC compatible. Now, I think that their idiosyncrasies with OAuth have been versioned away. I think they probably still have the subtle nuance differences with their original OAuth 2s, but I believe that they're all up to date with basically the same spec that Auth0 and Okta and that FusionAuth, any of those libraries are going to work with them. If you were to just take the component parts and say, swap the URL from...Okta.com to what is it? Identity.Google.com or something like that. 

DAN_MOORE: Accounts, I think, or something. 

AJ_ONEAL: Yeah. Yes, that's it. Accounts.Google.com. 

DAN_MOORE: And in a positive element, I know that Twitter recently, cause they were on OAuth 1 for a long, long time, they recently rolled out OAuth 2 support. So I think they had to have OAuth 2 to get to OIDC. I don't know whether they've gotten to OIDC yet, but if you care about logging with Twitter, that's a positive step. 

CHARLES MAX_WOOD: So, well, it's interesting hearing you guys talk about this because.It reminds me a little bit of kind of the disjointed standards we had just for web APIs. And as the browsers have standardized, right, then it's, oh, I can reliably do this thing because everybody implements it the same way. 

DAN_MOORE: Yeah, I mean, that's the thing is like, there's the promise and then there's the reality, right? And the unfortunate truth is, and this is something I've heard and not just lived, but like that heard that even I have seen this even even if you everything's kind of OIDC compatible, like they're still differences around some subtle things. You know, identifiers can be weird because sometimes people can expect an identifier to be a URL, but other times it's just a random string and that those kinds of cross-convaliability things, unfortunately mean that really the only way to truly test interop is to, is to interop. 

AJ_ONEAL: So that is, yeah. 

CHARLES MAX_WOOD: That's any API though. 

DAN_MOORE: Exactly. Yeah. We live in the real world of engineering, right? Like there's always subtle, subtle mismatches.Sorry, AJ. 

AJ_ONEAL: I was just going to say, some of those things, they only matter if you want to automate it to the max. If you just want to integrate with the one service, it doesn't matter whether they're using a URL or a random string. I prefer it when they use a URL because that's what you should do because then it's, what's the buzzword that we used to call this when inside of a document, it links to another document, not hyperlinking, but there's some term like that.

DAN_MOORE: Oh, hate OS or something like related to that. I hate OS is I think, 

AJ_ONEAL: I think that's the newest standard for it. But that general thing. Yeah. I think, I think that it's good when the tokens specify the provider or what was the right terminology is it issuer, 

DAN_MOORE: issuer. 

AJ_ONEAL: That's right. Now it's called issuer providers, the OAuth2 terminology that yeah, when they provide the issuer stuff in the talks, anyway, this is all deep technical detail. Maybe we should back up a little bit. Yeah. Take us down the rabbit hole as I always do. 

CHARLES MAX_WOOD: I was going to actually ask as sort of a next thing is, yeah. So if I'm just kinda coming into this and thinking, okay, that sounds great as far as like, the problems it solves for me and the things that I don't have to think about anymore. Like what do I need to know about it, right? Because I always hear people say, well, just use X, right? And it solves all the problems for you. But the reality is, is that I have to write some glue code somewhere, right? Now, hopefully in most cases, it's as easy as. Hey, I'm going to pull down this NPM package. I'm going to put some config together. And then I'm just going to kind of consume. I know this user is this, that, or the other from there, right? Whether that's in my app or your app, but that's not always the case. And then the other thing is, is yeah, sometimes you get into this weird land where it's like, you know what, it does solve this problem, but I need this thing that it's supposed to do, but I just don't know how to make it do it. So I guess. Yeah, what level of fundamental understanding am I going to have to have just to be able to make it work and to be able to kind of fiddle with things if I need something that's slightly different from the default? 

DAN_MOORE: So I mean, so it's worth kind of thinking about like who you are, right? Like, because this answer is different. So there are, you can think of three kind of main parties in this, there's the person or the server that holds the identity. And that's called on the authorization server, which again, is As AJ mentioned, there are multiple different names for this concept. I'm gonna go with the ones I'm most familiar with, which is OAuth 2. So the authorization server is what holds the user's password and possibly their roles or other information about the authorization. Then we have what we call the client, which is the thing that's trying to get, actually, skip client right now. We have the resource server, which is the thing that actually holds the data, right? So you can think of a to-do app or a calendar app. That's the thing that actually holds the data that the user, which is the person, wants access to. And then there's the client, which is the thing that the user is driving, right? So a browser or a mobile app, those tend to be the clients. So we're not gonna talk about the authorization server very much because the honest answer is there. There are plenty of open source options out there. There are plenty of commercial options out there. You should go use one. There's actually libraries you can snap into various frameworks that turn your application into an authorization server. So please don't write one. So let's ignore that piece. I guess the short answer about tweaking that is you're gonna wanna read your, whatever your solutions documentation is. Then we have the resource server, which is the thing that's protecting the valuable data. And so there, you're going to want to authenticate or verify that token, right? And that's a couple of things, right? Depending on how you're, is that too jargony right now? The token is just kind of this like little arbitrary, opaque piece of...data that you get from the authorization server. 

AJ_ONEAL: It's the password. Essentially it's the temporary password. 

DAN_MOORE: Temporary password. That's where we put it. Temporary. 

AJ_ONEAL: So I want to put this in perspective. Authorization server, log in with Facebook, log in with Google resource server, Spotify, mgr token, temporarily agreed upon password between the resource and the authorization servers, client, the Spotify app, the mgr website. Yeah, sure. Right. Is that painting the picture? Well,

DAN_MOORE: But it doesn't necessarily need to be like, like in the, in your world or the example you just gave Spotify owned both ends, but doesn't have to own both ends. Right. It could be your own personal spot. Like if you're hacking on a Spotify client, you might log in with Facebook and then get credentials to present to Spotify's API. 

AJ_ONEAL: Yeah. So for, if you, if you're doing the music search, look up and say an app and you're, and you're taking things people are doing and you're matching. You're, you're matching to see, is this a song title you could go hit the Spotify API. Well, generally that's how the API keys. Can you think of a real world example off the top of your head where it actually functions in the more decentralized manner? Cause it seems that usually two ends of the triangle are the same just because of that's usually things like Spotify wants you to use their app, et cetera. 

DAN_MOORE: An example is Buffer talking to Twitter, right? So there's a Buffer client that lets me post stuff to Twitter and LinkedIn and everything else. And then...So I have to authenticate against Twitter. I guess in this case, 

AJ_ONEAL: Twitter's resource and authorization. 

DAN_MOORE: Yeah. So instead of Twitter being the client in the, and, uh, the resource Twitter's dot 

AJ_ONEAL: if there was an OAuth for email, that would be a good example, because that would be something where all three would probably, you know, your client would be separate, your resource, your email would be separate. I guess maybe Gmail, Gmail business Gmail might be that way. Cause you have all sorts of the, the, the little apps that will integrate with email to do contacts and stuff like that. 

DAN_MOORE: You're talking about streak or something like that where it like augments Gmail. Is that, yeah. Gotcha. Okay. 

AJ_ONEAL: Yeah. 

DAN_MOORE: So where was it? So the client, as AJ said, is, is something that is, is driving, is trying to get access to those protected resources. So when you're a client, you need to, you really should be looking for, and again, an open source library that will take care of a lot of the kind of nuts and bolts. You can gain a lot of insight into the OAuth grants by running through them with a curl script this is all old enough technology that you actually can use form using form parameters to post. And so I think that it would behoove you if you want to kind of look behind the covers to actually run through the various steps in with curl or some other similar tool, but certainly for production, you're going to want to use something that is well supported in, in cover some of the edge cases. 

AJ_ONEAL: Don't shell out to curl in production. 

DAN_MOORE: Rarely, rarely.I'm in DevRel. They don't let me touch production right now. And then for the resource server, I think it's really important to kind of validate that token. We talked a little bit about that, valid that temporary password. And unfortunately, it's not enough to just present it to the, um, authorization server and say, Hey, is this token valid? There are other things you need to do as a resource server. You need to make sure that token was created for you. You need to make sure that you recognize where it came from because anyone can, I mean, I could go create a token right now and like present it around and see who accepts what, you know, make it say whatever I want. And again, these are kind of some edge cases, but that's one of the benefits of using a system like OAuth is that it makes it force you to think about these edge cases and other people have thought about them. There's a IETF mailing list that I'm on that is full of people who spend a lot of time just thinking about weird edge cases and how the OAuth protocol and the things that are built on top of like OIDC can address those edge cases. 

STEVE_EDWARDS: Hey, I have a question real quick. I'm sort of, I don't have AJ's level of knowledge on a lot of things, including this, but if I'm the client, okay. So I'm using OAuth to allow somebody to authenticate. How am I associating this token that has been passed to me with an actual user account in my client that I want to say, I'm Steve, okay, this token belongs to Steve, how is that token be associating with Steve's account on Spotify client? For instance or whatever the end resource is. 

DAN_MOORE: Sure, so it depends, but the short answer is oftentimes a token will have embedded information. Tokens can be, you could do multiple different formats for tokens for OIDC. I'm pretty sure the specification says it has to be a JSON web token, which is basically a signed bit of JSON content. And then inside there, the keys, again, more jargon, the keys of the JSON object are called claims. And there's a claim that says, this is who this token is about. There are other claims that say, this is what roles this person has, or this principal has, this is who issued the token. You can also get all these back, typically from by presenting a token to the authorization server, and then it will hand back JSON that says this stuff as well. But that's how the resource server can know who the token is about. The client, I'm not sure they need to, right? They just present the token. They're handed back that token and they present that token to other things. And then the other things are responsible for knowing. Does that answer your question, Steve? Or am I side stepping it? 

STEVE_EDWARDS: Yeah, there's a whole lot more complexity behind what you're talking about. Especially I've worked with JWTs before. I remember when I was learning Angular, I went through a course and, you know, how you use the different parts together to identify the user and stuff. So we could probably talk for a while just about that itself. Yeah. It just gives me a rough idea. 

CHARLES MAX_WOOD: I mean, just to give an example. So I'm using. I'm using Auth0 with top end devs, right? So if you go, you can sign up, you can sign up for a free account, right? It'll ask you to pay as soon as you sign in, but you don't have to, right? To get access to some of the stuff in there. And yeah, so I'm using Auth0. Auth0 has a subscriber ID, right? So the token may change, but the subscriber ID for that person will stay the same. And then on the other end, on my end, when I authorize and...We might want to talk a little bit about this in a minute, because I don't know exactly how it works. I just know that I magically get the information I asked for. But you can authorize it to give you certain information, right? So I'm always requesting email so that I can, you know, hey, there's a new course, hey, there's a new thing, right? But yeah, so I have a user's model in my Rails app. It's a Rails app. You know, for all you JavaScript folks out there going, you still do it on Rails? Yes, yes, I am. But... 

AJ_ONEAL: Now there's Remix, and that's just Rails and JavaScript, so... 

CHARLES MAX_WOOD: I think those might be fighting words, depending on who you talk to, but...Anyway, but yeah, so then once I have that, then the user can tie to a subscription in my system and things like that that integrates with stripe or whatever. And so that's how I've managed this. And so I'm just keeping track of, you know, I have the subscriber ID, the token is stored in the session. And so I can validate at any point that I need to. Hey, is this a valid login for my OAuth system on Auth0? And then I can also turn around and I can do the same thing with Stripe, you know, through their API, you know, to verify that they have a valid subscription and then from there I can show them the stuff that they've subscribed to receive. 

AJ_ONEAL: So as somebody who does not like too many layers of abstraction and likes to keep things simple, this sounds so complicated. Why would anyone ever want to use this? Why wouldn't I just put a, you know, a stupid, simple, bcrypt salted password? I mean, browsers have password managers now, so nobody has to remember a password. The browser will auto-generate a new, are there any browsers that don't just auto-generate passwords nowadays when you sign up for something new? So with all that, why in the world would I ever go through all this complexity if I could just have email address, password, done? 

CHARLES MAX_WOOD: Rails has that stuff built in too, right? Right.

DAN_MOORE: And so does Django and yeah, I mean, most frameworks do. Right. Yeah. It's a great question. So, you know, there are a couple of reasons. The one is that oftentimes you want to share something with shared users across different applications. Right. So with top end devs, you might have a forum, you might have a support system. You might have the main custom app and 

CHARLES MAX_WOOD: yeah, I'm setting all that up. Yes.

DAN_MOORE: Yeah, you might say I'm going to just hang everything off my Rails app and my Rails is use ready. Well, congratulations. You just invented an OAuth server essentially, right? An OAuth server. And now you need to make sure that that Rails app is available and secured and all the other things that you were going to want with an OAuth server. Now, if you extract that OAuth server out, again, I want to be careful about terminology here, this is tied to OAuth, but it's not part of OAuth.Right? Like you can have an auth server that's separate that doesn't use OAuth at all, uses SAML or WSFED or some other authentication protocol, LDAP. Right. I mean, but so, so I think there's two questions here. The first is, is there value in separating out your authentication information? And I think one of the, the piece of value is you can add single sign on pretty easily. You can have one view of your user. You can have one onboarding, offboarding process. So there's value in that, but that is not tied to OAuth necessarily. Then if you layer on OAuth, you get the benefits of this temporary credential and these experts that are pushing the authentication, understanding of authentication forward, right? An example of that is there's actually a grant that was, I think it was codified in 2018 or 2019 called the device flow grant, which is, sorry, it's the device grant, which is a way for someone to authenticate on their phone an app on their TV, right? So that if you've ever signed in a TV and it brings up a QR code that you scan with your phone, you log in, that is a use case that is pretty less education than it used to be, but pretty edge case, but by finding a properly compliant OAuth or OIDC server, you get that for free, right? Someone else is putting the hard work of figuring out that protocol and how that would work. And that's one example of, of multiple. So I appreciate your softball question, AJ. And I think that it's worth actually splitting out, isolating your auth, which I think is valuable in the same way that isolating your databases. And then do you need OAuth? And the other kind of final benefit I'd say OAuth is, or OAuth, slash O-A-H-C, is that compatibility, right? There are very many companies out there that sell your SaaS product that say, hey, do you want single sign-on with SAML or OAuth, O-A-H-C? It'll work. There are very few companies that will let you integrate your own custom protocol with their, with their SaaS app. 

AJ_ONEAL: And I will, in answering my own question, I'm just going to say, auth is subtle. And you might think you don't need the complexity, but it ends up that you do. I don't know. I don't know exactly how to articulate it, but anytime someone starts down a path of, oh, I'm just going to salt and hash some passwords, that path never ends where you think it does. And you end up needing most, not most, you end up needing a smorgasbord of these features as your app grows. 

DAN_MOORE: And I would also say there are operational concerns as well. You know, we all- 

AJ_ONEAL: Regulatory concerns. 

DAN_MOORE: Yeah, regulatory concerns for sure. I mean, how many, there's, I don't know, 600 billion passwords in the have-I-been-pwn database now. And-Are you going to take as good a care of your security posture? Are you going to change the factor? Are you going to update the algorithm? Are you going to deal with all these other pieces or can you outsource them? 

AJ_ONEAL: And then when browser standards change. So, uh, last year, all the browsers started, started moving over to not allowing third-party cookies. So that cool thing that, that Google just started doing where it gives you a one click sign on where it basically says, hey, this is who you're logged in as. Do you want to just go ahead and automatically share this? That is now essentially broken, uh, because you cannot do a seamless log and experience or that type of flow without third party cookies. So now if you're using Safari, if you're using brave and you don't make the exception for Google, eventually Google's going to have to adopt those standards for their own browser. But right now, because their whole business is ads, they're really, really slow to adopt that, but it is going to land in Chrome eventually. And it is multiple times over the last decade, browser standards have changed and has broken authentication flows. And so even if you design it all right yourself, when the browser standard changes and you did nothing wrong, your auth breaks again.

DAN_MOORE:  And then you just can't log in and they're PO'd at you, right? Like they're not mad at somebody else. The other thing I would say is that there are more changes coming, even around like redirects. There's a working group with the W3C. No, it's all right. It's a community group, not a working group. Anyway, they're talking to the browser vendors and trying to figure this out because some of the very valid changes that browser vendors want to bring to increase people's security, like disabling third party cookies also have the follow on effect of breaking auth because auth has been built on this kind of the same primitives. And so. This is all things that you want to be aware of if you're going to kind of roll your own off. 

AJ_ONEAL: Yeah. Yeah. I think the standard you're referring to is portals. Does that ring a bell? 

DAN_MOORE: I'm not familiar with that. 

AJ_ONEAL: No, it's going to be the replacement for redirects. Basically it's a hybrid between an iframe and a redirect so that you can get experience in the same window without sacrificing security. So the URL can still change, but you can still have the state. So basically rather than the users in the middle of something, they go to log in and then you either have to pop up on a new window and have them possibly get confused, or you have to redirect and have them lose state. You're going to be able to do what you could do before they took away the third party cookies, where you open up the iframe overlay and then have it go back. But it's a little bit more secure. The URL will change as well. So it'll feel like a redirect and that you'll see the new URL. And then there's some things to prevent click jacking or whatever. 

DAN_MOORE: And do you communicate back and forth to that portable the same way you do with an iframe, like just over JavaScript, like passing messages or? 

AJ_ONEAL: I haven't actually looked at the spec, but I'm imagining that it's that type of thing, either, oh, what's that, either post message or just having a reference to the parent. 

DAN_MOORE: Sure. 

CHARLES MAX_WOOD: So one thing that I'm curious about, and this is something that I've seen on several different OAuth systems. For example, if somebody signs in with GitHub, right, it says, hey, I'm requesting access to manage these repos and see those repos, and I want your email address, and I want this, right? So those are all customizable according to your provider, I'm assuming, but how does that work as far as the OAuth protocol goes? 

DAN_MOORE: Sure, so those are called scopes. And so the idea is that the client knows what they want, right, and so you gave the example of wanting people's email address from Facebook or some other provider, but you don't necessarily want birthdays. And so the idea is that the client, the application running on the client presents those scopes to the authorization server and the authorization server then presents the user who's living at the authorization server when they're authenticating with those set of permissions. And the user, I think the ideal is the user carefully considers what data they are handing over to the client. I don't know about any of you, but I don't read any EULAs that I just kind of click through stuff. But the idea is that people could choose to say, oh, actually, I do not want this app that is a to-do app to be able to send email via Gmail. And so I'm going to say, no, I'm going to bail out of this permissioning process. But that's what scopes are for. And if the user gives the consent, gives the permissions, then the authorization server can encode that in the token. And then the resource server, which again is the thing that holds access to the precious data or functionality can examine that or find that out and say, Oh, okay. They do have the scope of being able to read an email. And so I can send them any, I can send them whatever data they want. 

AJ_ONEAL: This is the next standard that we need. We need a standard for scopes that is well-defined because things like profile picture, email address contacts there's a few things that basically no matter which web app you want. I wish that we had a Well defined list of these are well-known Scope names that's that you know Whether I'm logging in with gmail or I'm logging in with yahoo or whatever it is just contacts is called schema org slash Contacts and photo library is called schema org slash photos or something like that. That's one thing that that Hasn't been well standardized. It's one of those nuanced details. Well, I guess this is This is a point I was going to bring up earlier. I don't think that any of these services are good for authorization at this point. I think they all stink at it. I don't think that anybody has figured out how to do authorization. Well, I think that authentication at this point has been nailed, but authorization I think is still completely the wild West. And I think it's just cause needs are so different. It's hard to do an author authorization strategy. 

DAN_MOORE: Yeah. So maybe we're digging into a little bit. I mean, in my experience, yeah, authentication there may be five, 10 20 different ways to authenticate somebody, but it's pretty standardized across different orgs, whereas authorization is super business domain specific. And so what I see is, I see kind of two or three things. One is if you're small and you kind of have only a few applications, you can get by with RBAC, which is Sansa role-based access control, which basically means that the authorization server assigns someone a role or set of roles, and then your application reads those. You also can use attribute based authentication, sorry, ABAC, which is Attribute Based Access Control. And that is something where you don't just present the roles that are handed out at authentication, but you also can present like what the resource is being, which resource is being accessed, what time of day it is, things like that. And they're actually, you could code that on your own, but there are actually some standalone authorization servers that are starting to emerge. I've worked with and they basically, it's kind of like, what was that called in rails? There was something that was the same kind of thing where it was like a, basically kind of a set of permissioning structures that you basically present the user. You present what they're trying to access and maybe some other metadata and it gives back a yes or no answer. But again, that's not standard. 

CHARLES MAX_WOOD: I think you can't can or yeah. 

DAN_MOORE: Can't can or something like that. Yeah, exactly. So yeah, but that gets to AJ's point, right? There's no way to standardize that, right? Like my admin is gonna be totally different than your admin depending on the application context and what our application can do. And you may be able to standardize the names, right? I don't know if there'd be a ton of, I'm not sure how much value there would be in that. So I think where the standards would help, to your point, AJ, is maybe more like guidance, right? Which maybe it's more of a best practices kind of thing people talking about what's worked and what hasn't worked. But then the question becomes like scale too, right? Like I can read interesting things about Slack's user permissioning system all day long, is it going to be applicable to my to-do app? Probably not. 

CHARLES MAX_WOOD: Yeah. One thing that I see here is like, if I'm talking about maybe like digital access to a product or something like that, I think a lot of those permission structures are going to look the same across multiple apps. And so it'd be nice to see something that worked with those, but what I find is that the permission setups for these systems, they either try and boil it down to a set of attributes. And so then I've got to work through the callback system. I looked at doing this with Auth0, right, where it was, you know, go look at Stripe and, you know, if the subscription's still good, then tell me when I authenticate, right? So then I have a scope for what subscriptions do they have or what products have they purchased. But it was easier for me just to manage that on my own and make the Stripe API. API calls myself, right, and have a web hook that Stripe could hit. But I think that kind of structure, you know, works for a lot of things. And then, you know, if it's role-based, you know, maybe on an admin or something like that, then, you know, you're, you're looking at something else and then sometimes you kind of split the difference and you have a role on a entity in your system, right. But yeah, the problem is, is yeah, all of the authentic or authorization systems that I've seen in. And I've used Okta and Auth0. They're just way too generic and there's not really a good way to update them based on the things that I care about other than going into their UI and actually manually doing it, which is not the way I wanna manage it. So that's what I've run into. But I think you could standardize on kind of some common patterns. But yeah, then you've gotta be flexible enough for the exceptions, right? Because yeah, everybody's setup's a little bit different.

 

So I'm here with JD from Raygun. JD, when I talk to you, I mean, I really feel the developer vibe and I know that's your background, but is all of Raygun that way? I mean, you know, it just kind of feels like when I talk to other companies, they're a little more corporate, a little more, you know, focused on maybe, you know, raising money or doing other things, you know, but it seems like when I talk to you, you're just, you know, down to earth developer dude. I like to think of myself as a down to earth developer dude. Yeah. Yeah. Right. Raygun is a little bit different. So, You know, we're not heavily VC backed. Um, you know, my business partner and I, when we started, we were both nerds. You know, um, I might be the CEO today and I don't write code on the product. Um, but you know, the joke internally is, you know, what's the definition of technical debt Chuck? It's CEO code stuff to go. But, uh, no, we, we, we, we. Stories. We're a cashflow positive business, you know, we're not heavily VC funded, you know, but we are at a size now where we are expanding and more and more folks are discovering what we're about. But yeah, we often look through things through that lens of a developer, you know, I wanted a 30,000 foot view, but I also want to go right down to an individual data point. Similarly, you know, I don't believe in averages. I want medians, I want P99s, I make better decisions that way and so we try and drive that sort of thinking into our products and try and be as developer minded as we possibly can be. Yeah. I love that because, you know, for me, it's, it's run by people who get me, um, and you're not under pressure from like a VC to raise your prices or, you know, go hyper grow and then, Oh crap, now we're behind the eight ball with our money and now we've got to figure it out. You know, you're just going to keep growing steadily moving. And I just love that. Yeah. I mean the term these days is often referred to as product lead growth, right? Like get people use the product and say, Hey, that's great. I want to give you money. Um, I don't think it's that complicated. Sounds good. Well folks, if you want to go check it out, you can go find them at raygun.com. Uh, you can actually sign up for free trial right there on the website. 

 

AJ_ONEAL: Oh, one of the, one of the weird things with, uh, Okta that's a gotcha is they have two different types of access tokens and the way that you can use it varies based on the audience field. So basically for the audience field that's addressed to you, that token, it follows the spec, but the audience field that's addressed to them, that token does not follow the spec because supposedly it's a bespoke token not for not addressed to the audience of you. Oh, sorry, audience. Audience is another one of those six terms that the OID spec defines differently from the OAuth spec, but are otherwise exactly the same. Audience is the application that's going to receive the token, which is some subtle difference from what we were previously calling resource. Anyway, just a little anecdote there. 

DAN_MOORE: And so, I mean, that gets back again, like, like the OAS spec, like if you follow it, like perfectly, the client should never look at the token, right? Like, I know this is slightly different than what you're talking about, right? You're talking about the resource server examining the token, but there's this tension there between, like,

AJ_ONEAL:Well, that's not true. Well, I mean, maybe with OAuth, but OIDC, one of the points of the ID token is that it has information that you can you can relatively well rely on, assuming that you trust the issuer. Then you can rely on if the person has a nickname or an email address as part of the claims in the ID token. You actually as the client, you should be able to use that rather than making another API call round trip to get the basic user information to just have those. Because ID tokens are typically larger than access tokens because they are meant to be. 

DAN_MOORE: Totally agree. And so, and maybe it's worth kind of like digging into like the difference between ID tokens and access tokens, right? Like access tokens are part of OAS and they are what you present to the resource server, right? Like again, this to do API to say, I want to manage my to do's. ID tokens are part of OIDC and the client's actually supposed to read them, right? So that's where it can say, this is, hey, my name's Dan. And I can send out an ID token and that way I don't have to call off or do anything else to get like the information that I've requested about this particular user. So there are multiple tokens and you can get back all, you can get back both of them from an OIDC flow, right? You can get back the access token and the ID token. And then the client probably won't present the ID token to anybody else because the ID token is really designed for them, the client to like process it. Whereas they really should be processing the access token. That's not for them. Yeah. 

AJ_ONEAL: And I think in some ways the ID token takes replacement of a refresh token with OIDC as well, because your ID token is typically the thing that defines your long live session that maybe it lasts 90 days or something like that. And you can use it to get new access tokens. Whereas the access token is the thing that's gonna last maybe 15 minutes and you just need to get a new one every time. And that's, you know provides the access controls against unauthorized access. 

DAN_MOORE: So I'm not familiar with the ID token refresh flow. So that could be part of the OIDC spec. I just haven't kind of delve into, I'm more familiar with the refresh token or the refresh grant, but maybe we are a little bit in the weeds here. I don't know. This is this interesting, but Charles, are you going to bring us up again? Or we good here? 

CHARLES MAX_WOOD: I'm not really sure where, where, where it would take us next. 

AJ_ONEAL: So, well, what I want to know is Why in the world would anybody want to use, what is it, FusionAuth? When we've already got these other, we've got Auth0, we've got Okta, goodness knows, don't they give us enough headaches? Why do we want FusionAuth in the mix? 

CHARLES MAX_WOOD: Sure. Well, when I work on an app where we use a library, again, this is another Rails app, but we use DoorKeeper, right? And they just provide their own. So, I mean, why roll with any of it? 

DAN_MOORE: Sure, yeah, so it's a good question of why you would pick FusionAuth over any other solutions or any other solution over any other solution, right? I think that I can speak to some of Fusion Auth benefits and then we can talk about things that you're gonna wanna think about. So let's do that. Let me give you the quick 30 second pitch for Fusion Auth and then we can talk about, if I'm just dropped into a project and I'm trying to figure out what auth server to use, what are some attributes that I would consider? So the quick 30 second spiel for Fusion Auth is that we're built by devs for devs and so we have more of a dev ethos than some of those other providers out there in terms of...Being really friendly with CI, CD, we're entirely API driven. I already mentioned the hosting model, so you can host or you can pay us to host for you. We also have different tiers of product and we have a free tier that is, if you hosted yourself 100% free for as many users as you want. Obviously, if we're hosting it for you, then we're gonna charge you hosting fees. But kind of running through all that is just the idea that Authentication, as AJ mentioned, is kind of, can be really subtle and really deep. And we see a lot of people approaching it from the security minded perspective, right? The security officers and whatnot, or the people coming from the IAM perspective, where they, they really worked on like identity access management. But we didn't see somebody coming from the developer perspective, except for Auth0. And props to them. They've done a great job of that. The final difference I'd leave you with is, is just pricing and we've You know, Auzero has a great free tier, but as soon as you grow out of that, we've heard some people have some complaints about that. So move on from the Fusion House pitch and talk about like things that you want to think about, right? Like I have a big long list of things to consider, but I think the open source versus commercial divide is pretty big. The, do I want something that snaps into a framework or something that's standalone is a big thing to consider. Obviously there's a bunch of different kinds of features you can look for, but the big kind of three are authentication, authorization, user management, which tend to be bundled together, but can be separated out. And then I could keep going, but there's a lot to think about. So, yeah. 

CHARLES MAX_WOOD: And a lot of those are, you know, I think they're different topics that are a little bit wider that we probably ought to cover on the show. Like do I, when do I pick a commercial solution? When do I self-host right? Or, you know, when do I self-host the standalone app versus using some framework that plugs into my framework? or things like that. But, and I think for like 80% of the cases, it's do what makes sense to you. And then the other 20% is where the nuance comes in, where you're actually going. You know, there's a pretty major trade off between this one and that one. At least that's been my experience with almost everything that I've used. Libraries, frameworks, programming languages, all of those things, they work in like 80% of the cases and you're never gonna run into the limits. And then the other 20%, that's where it's gonna be like, You know, this really, really is not fun, right? So I'm gonna do it this way or that way. But it's nice to know that there's an option out there. I really like the open source option, to be honest. And just being able to go in and say, okay, well, I'm gonna set up a DevOps server to manage updates and crap like that, stay on top of what's new in Fusion Auth, and kind of go host it on my own. And then if I get tired of that, then I probably can just roll it into a commercial option and not worry about any of that stuff either. 

DAN_MOORE: I do want to be careful that like, fusion is not open source. So there are open source options out there. Fusion has a free as in beer, but the code is not available. 

CHARLES MAX_WOOD: Okay. So it's not open source, but it's you can go host it on your own for free. 

DAN_MOORE: Absolutely. It's a, you know, there's the whole free isn't speech, free is in beer thing. That used to be a big deal 15, 20 years ago. These are not this free as in beer. 

CHARLES MAX_WOOD: So, okay. Good to know. Thanks for clarifying that. 

AJ_ONEAL: What is it written in? 

CHARLES MAX_WOOD: Do you care? I mean, I can tell you, I can tell you.

AJ_ONEAL: But I, I do. Cause I basically, me personally, I only run stuff if it's either node, go or rust because those are the, well, go and rust are generally secure and efficient. And, uh, trust that if people are writing enterprise services and those that they, I just trust them more. 

DAN_MOORE: Sure. Fair enough. That's fair. Yeah. So to answer my question or the kind of flip it, I made a lot of people are running us in Docker containers, so they don't really care what our runtime is, but our runtime is Java, Java 17. So I guess AJ, we've just lost you as a possible user, seems like. 

AJ_ONEAL: Well, I personally, I want something that is not open source, but auditable source, we might say. I want, I want something that I can, I can poke at, not necessarily that I have to have the right to copy that to me is the sweet spot. I'm hoping some, I think something's going to shift in the open source community. I think open source is hopefully going to go away. Uh, and that what, what open source will remain as, I mean, it's the obviously not going to go away because there's a million packages out there, but I'm hoping that what it tends towards is open source becomes more about libraries and then something akin to auditable source will be products. Because right now the big lie is that we were taught and we were told that we're going to share our hearts with each other and open our minds and freedom will abound is basically, you know, hippies, but for code and then and then what actually happened was big business came in, took all the millions of dollars of stuff that we built, uh, that gave them access to something that they would not have been able to build otherwise, cause they just don't have the resources for it, put us in prisons, took all of our stuff away, put it out in the cloud where we can't get to it, see it, touch it, smell it, taste it. And then told us pay us, you're going to love it. And that, you know, it's just kind of a big kick at the Cahonies and things have to turn around. We have to get back to a point where people can own some stuff again and have some privacy again and I think there's enough groundswell that we're at the cusp of it. The one thing is nobody knows how to get to the point where, I mean, so for example, no one gets paid to work on, most of the foundational tools of the internet, people aren't being paid to work on curl, right? It's not that dude's full-time job, I could be wrong. Curl might be an exception, but there's a, you know, there's a hundred utilities like curl where they're decades old. And really somebody should just get paid a hundred thousand dollars a year minimum to just sit and say, hey, look I don't care if you make one commit to this a year, just maintain this thing. Make sure it doesn't break the internet, right? And as soon as that money piece gets figured out, which I am, don't tell my friends, but due to some conversations and some mind opening, maybe it will be something in the digital currency space that opens this up. But as soon as that money piece gets solved, I think. I think we're going to see the avalanche come down and we're going to have something way better than open source. That's sustainable. That's higher quality where people are getting paid. That's what I'm looking for. 

DAN_MOORE: I'm actually a little bit interested in the auditability piece. Like what does auditability mean? Auditability mean to you? 

AJ_ONEAL: Just to be able to view the code. 

CHARLES MAX_WOOD: I was going to say you have two minutes AJ, cause then I'm going to cut you off. 

AJ_ONEAL: Just view it. Just, just be able to look at it and inspect it. And, uh, you know, potentially learn from it. I know there's some issues with looking at code and then doing an implementation that could be similar, that, you know, there's some, some, some gray area there. So I don't know that I would, but I just want to be able to inspect and say, okay, how's this being done? How can I feel good about this or how can, how can I understand it a little bit better so that my mind feels at ease that yes, this is, this is right. I mean, cause if I, I mean, if I look at somebody's code and one of the most popular OTP libraries back in the day on NPM was terrible and insecure. And that was auditable and nobody just, nobody looked at it. And people that did look at it, didn't realize just because something's popular or done by a big corporation does not mean that it is good. 

CHARLES MAX_WOOD: Yeah. I, I'd love to do an episode on this and just dive into it with you, AJ, cause I think, I think some of the ideas you're bringing up are interesting and I'd be interested to see how they're workable. I think some of the points you made, I'd at least challenge you on and maybe it's just a fundamental misunderstanding of what you're saying or maybe we actually disagree on it, who knows. But yeah, I think this is another conversation that I think ought to be had at length because it affects everything that we're doing as developers and it's a big part of how we build our community. And so that all said just kind of derail us back to the conversation about OAuth and FusionAuth. It is at the same time interesting to see, you know, where you've kind of split the difference as far as, hey, you know, you can go use this for free, you can go put it out there for free, you can go do this stuff, we're built by developers, we care about this ecosystem, you know, and at the same time going, but we are a commercial company and we are trying to make a profit so we can pay people to work on this and stuff like that. I think at the end of the day, I think we all want it to be fair, I guess, for lack of a better word, right? People who are adding value are getting value and the things are sustainable because we do burn people out on open source every day. But yeah, it's interesting just to see where all of this heads and I'd really be curious to see where things go for Fusion off in the future as well. You know, given your value set versus maybe the value set of some of the other companies or libraries that are doing some similar things.

DAN_MOORE: Yeah, and I will say that like over the last couple of years, there's just been an explosion in people and different people with different approaches to auth. And it actually almost reminds me of some of the explosions I've seen in terms of frameworks over my 20 years where people realize the problem is important. People realize that there's money to be made or there's solutions to be found. And so people come at it from all different ways. And I've seen multiple Silicon Valley startups that basically seem to wrap a little bit of auth functionality and they've raised tens of millions of dollars. And frankly, I'm excited for it. I think that auth is one of those problems that, and again, it's the portmanteau of auth and authentication authorization and some user management that's been in there. But I think it's really something that people shouldn't care about. At the end of the day, it's non-differentiated functionality. You want to snap something in and make sure that it works in a secure and will be operated for you in the future. And then you don't want to think about it ever again, typically in my experience as a developer. 

AJ_ONEAL: So I think the one, one key thing is going to emerge soon ish, which is putting off and payment together somehow, because that's, that's those two pieces are the two hard pieces that are so closely related in terms of That, that I think is going to be the breakthrough when somebody bridges the gap between what Stripe is and what Okta is so that you've got the core thing you need to be successful and you only focus on the business logic. 

CHARLES MAX_WOOD: Well, I'll write that this week and we'll, I'll cut you in. Can you get on that? Thanks. I mean, 

DAN_MOORE: I thought that Stripe had released an authentication piece, but maybe, maybe they haven't. I thought they'd released a some way to sign in, but.

AJ_ONEAL: They did have a sign in with Stripe at one point. It broke when the third party cookie stuff started happening. So I don't think it's in their V3 API. It could be wrong about it. It could be totally wrong about this, but I know, I know that they did have a sign in with Stripe. I just don't think it was really popular because no one thinks of Stripe as an authentication service. They'd need to brand it a little bit better. Cause I'm not, I'm not going to put a sign in with Stripe next to my sign in with Facebook button. Right. 

DAN_MOORE: Well, and the other thing is we see a lot of customers that aren't necessarily charging customers, right? Or they're not charging customers via Stripe. They're, and that's one of the reasons that they like the community model or some of the other pricing is that they have hundreds of thousands or millions of users, but they're students, right? And they have a smaller set of users that are actually, you know, college counselors or something like that. And so they need both sides of that, both types of users, but they're never going to charge a user for that. Or companies will come in and want to like, roll up their user databases. And again, there are probably some other payment form rather than Stripe or credit cards to do that, but they still want that single view of the user. So I think that someone who does transactions or payments plus authentication is gonna be super compelling to some subset of the market, right? Like people trying to get a SaaS company off the ground will absolutely love that because it kills two of their really crucial birds with one stone. Other bigger companies might care, might not care as much for it. 

CHARLES MAX_WOOD: Cool. Well, we need to get to PICS cause I, I have a meeting. It's for my client, so I can't miss it. 15 minutes. So, but yeah, before we do that, Dan, if people want to connect with you, maybe they have questions about OAuth or FusionAuth or, you know, maybe you just are really interesting on Twitter. Where do they find you? Usually people put out like LinkedIn and Twitter. Some people it's like email me or, you know, whatever. So yeah, how do you want people to get in touch with you?

DAN_MOORE: Sure. Probably the easiest way is to follow me on Twitter or contact me on Twitter. It's M O O R E D S so Moo Reds or more DS. You can also email me Dan at Fusionauth.io and you can learn more about Fusionauth at Fusionauth.io. 

CHARLES MAX_WOOD: Awesome. 

 

Hi, this is Charles Max Wood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases just taking their career to the next level. You know, whether you're beginner going to intermediate and immediate going to advanced whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go and figure out what the next steps are. And then from there we can figure out how to get you to the place you want to go. So once again, that's topendevs.com slash coaching. 

 

CHARLES MAX_WOOD: All right. Let's go ahead and do picks. Dan's been having some difficulties making Riverside play nice with his ISP or something, so we're going to excuse him. I feel bad because he tried to hop on a couple of times and it just would not. Anyway, let's have Steve start us out with picks this week. 

STEVE_EDWARDS: Oh, we're going to go for the high point right away. Okay. So the high point of every of these podcasts is my jokes of the week. So I don't really have any articles, but I'll go for jokes. So my dad, when I was growing up, he always repeated the phrase, two heads are better than one. He was a great dad, but he was a terrible surgeon. 

AJ_ONEAL: I loved it. 

CHARLES MAX_WOOD: You actually got a laugh this time, Steve. 

STEVE_EDWARDS: Thank you. 

AJ_ONEAL: I've been subbing to you on Twitter, my friend. Yes, I saw that. You had a good one this morning. 

STEVE_EDWARDS: Yes. I'll get to that one here in just a second. So the other day I actually went to a bookstore and I saw a book that was titled How to Solve 50% of Your Problems. So I bought two. And then back when I was single, which has been a long time, I once joined an online dating agency for arsonists. They sent me new matches every week.

AJ_ONEAL: You forgot to add and they were hot. Smoking hot, smoking hot. 

STEVE_EDWARDS: Anyways, 

AJ_ONEAL: smoking hot matches every week. That's that. 

CHARLES MAX_WOOD: They were on fire. Okay. I'm going to stop while I'm at it. 

STEVE_EDWARDS: And Fuego. Yes. Yeah. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_ONEAL: Oh man. I've got some good ones for you to check. The first one that I'm going to pick is something that you and I need to talk about is Otter AI Otter AI. I just started using it for my own live streams. I, oh, I'm so excited about this. 

CHARLES MAX_WOOD: I tried it a while ago and I would have only had to fix half the words so it doesn't 

AJ_ONEAL: it doesn't it doesn't matter because it's not about fixing the words It's about there being words at all and keywords and it'll get used to our voices Anyway, I'm not gonna go into that but but I also got a stream deck and I have to pick these two things in concert So I got a stream deck which stream 

CHARLES MAX_WOOD: like jealous. I want one get one 

AJ_ONEAL: Why would you not get one? Because I was thinking I had this stupid $20 keyboard that I had hooked up with I think it was carabiner and I was trying to get some And I had it set up as a separate keyboard so that when I typed keys on it, they would go to commands rather than being treated as characters. But it just wasn't reliable. And then I thought one day, wait, I've been doing this streaming stuff so long. Why have I not bought a stream deck? And I got one and I love it. It's so simple and easy to use. I got it can run a bash script. I actually, I would have used it today, except I haven't figured out. They don't have it, I think on. Mac yet working so that you can get an audio to play in as a microphone device. Otherwise, I would have used my soundboard a couple of times, but I've got a soundboard on it for the streams. But the key thing is, so when I press record, I've got it hooked up with a multi action so that it switches to the right scenes and OBS starts the counter does a couple of other things. And then when I hit stop, just last night, I got it hooked up so that it runs a script that will extract the audio out of the recorded version of the stream, upload it to Otter AI, and then my digital assistant gets it the next day. And then what we're going to do is create a content site so that every stream that I do, we just use this tool to take the YouTube URL, and then link all the time codes that are in the Otter transcription and just put it up there. And then when I want to go look, oh, what was the stream where we talked about this, or I did that, or whatever, I just get... access to it. So I am I am just super in love and Otter, Otter AI, as far as I can tell, it's the best service out there for the value. Because if you look at Google or Microsoft or Amazon, their prices are just through the roof. It's, it's something like pennies, pennies per minute, where when you're looking about long format discussions, like what we do, it's insane. And then the other competitors to Otter that are a little bit more in the same price range, they just they just don't compare Otter has got to be the best thing out there in terms of getting good value for your money. They don't have an official API, but a little bit of hackery. There's an NPM module for it that works. So I've been using that. Anyway, I'm just super excited about those things. 

STEVE_EDWARDS: Chuck, you gotta know where this is going. I really think you ought to try it. And then also- That was just some low-hanging fruit. I couldn't resist it. 

CHARLES MAX_WOOD: I'm gonna boot you in disgrace. That was terrible.

AJ_ONEAL: I also want to pick our people that are watching live. Thank you. We had a comment that I didn't read out loud, unfortunately, because by the time I saw it, the moment had passed, but it was about basically the scope and claim names, but then the other, the last thing I'm going to pick is, it's just, it's embarrassing for me to have this, this conversation openly, but my mind is opening up, oh gosh, how do I, I think that there may be certain applications that are limited in scope. I'm sticking with the, you know, proof of work is a bunch of crap and blockchains aren't gonna solve the world's problems. But I think that there are a few limited number of problems that there is some blockchain based technology that can solve in a better way than other existing technology. So that's mark this day, I said it publicly, I got a knot in my stomach over it, but gotta speak truth to power even when that powers me. So I said it and I think I think Dash I think Dash is something that is on I think they're on to something and part of this is because I've actually had in-depth discussions with one of the one of the Dash people as a buddy of mine but Dash is not they they don't market themselves as a cryptocurrency they market themselves as digital cash spends but make everyday purchases with digital cash is the kind of their slogan and I think some of the stuff that's going on there. Talk about it later. 

CHARLES MAX_WOOD: Interesting. All right. I'm going to throw out some picks and then we'll let Dan throw out some picks. First of all, I've been looking around at a few things because there are some things that I want to pull together, but I kind of want to validate the ideas first and I have decided lately that I am not a huge giant fan of like Kickstarter. So I was looking around at like other crowdfunding websites and go fund me. No matter how you feel about like political stuff, the fact that they were gonna take money from a legitimate crowdfunding thing and give it to a charity instead of giving it to what it was meant for. I mean, they can change their terms afterward and say, we're not taking funds for things like this anymore. But that really bothered me because, and then they got social pressure and came back and said, no, we're just gonna give the money back. But it really bothered me because it's like, if people are going to give money to something and then you decide you don't like it. So I've been looking at, and I've seen Kickstarter kick a few folks off that I didn't feel like it was warranted either. And so I kind of like the decentralized idea, I guess, is where I'm heading with this and one of them that I found out there is called Tallycoin. And so you donate Satoshi's or fractional Bitcoin to people as kind of a fundraising thing, and so I'm kind of playing with that at least they've come out and publicly said that they're not going to censor an ongoing thing or not send the money to the people it was donated for is GiveSendGo. And that's the other one that I've been looking at just to kind of raise money there. And basically the things that I'm looking at, one of them is just a podcast management service. So you have podcast hosting services that host the website and the media content but nobody does all the other stuff. And I've had to cobble stuff together with Zapier over the years, right? So the Dan went through this, right? Where he scheduled it and then he got an email and said, hey, here's where you can collaborate with us to get information to us so we can prep. And then it updates the calendar invites that are created by schedule once and all that stuff. And I keep thinking, it's a real pain to maintain five different systems to make this work, right? And it generally works okay but I keep thinking it'd be nice to have a system that just did all that naturally. And then on the other end, I haven't found a way to automate the, okay, Dan, your episode's out. Here's how you can share it. Here are some resources to help you share it, things like that. And the other thing is, before the show, Dan Shapir told Dan Moore that we're a month-ish out, and it'd be nice to be able, for him, after we record it, you know, as soon as it's scheduled to go, right? Not necessarily edited and ready to go, but as soon as we know what the schedule is, you know, just let him know. And so he can go tweet about it or whatever upcoming, right? Hey, on the 23rd, go subscribe, JavaScript Jabber, right? And so I'd like to raise money for that. And then I've got some other projects that I just wanna see if people are even interested in before I spend a bunch of time putting it together. And so, yeah, so I'm looking at those. Those look really cool. And yeah, I'm just really interested in if somebody donates the money, it's just going to go where it's supposed to go. And then if you, if you have an issue with, you know, some aspect of the social cause, then you can let people know in the future, Hey, if it's something like this, we're not doing it anymore. And at least then I can say, well, I don't like that you're censoring that kind of a thing and then I can use or not use your platform. But anyway, it really bothers me when they edit it in the behind, after the fact. Anyway. I'm going to quit preaching about it, but those look really interesting. I'm also going to pick another movie called Encanto. It's the new Disney movie where I took all my kids to see it. The thing that really appealed to me out of this movie, I mean, most of the time I, you go see a Disney movie and it was like, yeah, I was entertained for an hour. But the thing that was interesting about this one in particular that just keeps striking me over and over again is that you've got all these people with all these different gifts, and then you've got one or two people in the family that don't have gifts, right? They either married in or whatever, right? And so, but the thing is, is those people immediately kind of get stereotyped into she's the perfect one, she's the strong one, she's the this, right? And we do this all the time. We do it in our communities. We do this in the wider world. And what winds up happening is the main character goes and she's actually talking to these, talking to her family members and it's the strong one, you know, there's a whole song about how she feels like she's always under pressure and she's going to crumble under pressure. And. You know, the other one feeling like she always has to be perfect until something happens and, you know, she realizes that she can kind of be who she wants to be. You know, and then the one that can hear everything, she's the quiet one. Right. And so anyway, it's, it's interesting, but that's how the family heals is by talking about their stuff, right. And realizing that we've kind of been putting everybody in a box and what we need to do is understand each other. And. It seems like some people are more interested in doing this than others. And I'm not going to demonize anybody for it. But honestly, if, if you have a deeply held position and you think that the other people have it made, or you're, you're making assumptions about whether they're good people or bad people, or this kind of people are that kind of people, go talk to them, right. And go see, you know, are you feeling like you're cracking under pressure? You got to do everything. Do you feel like you've always got to be the perfect one? Or do you feel like you're carrying this burden or that burden for the community, the family, the world, the country, whatever, right? Anyway, I just, I found this deep message in there that really clicked for me. And so I'm gonna pick the movie, because it's a fun movie. And my 16 year old is being driven nuts by his sisters playing the songs over and over and over and over and over and over and over and over again. And we don't talk about Bruno, no, no, no. But seriously, go watch the movie and then just think about it, you know? Who am I? whose relationship with me is strained because of the way that I see them or the way that they see me. And then see if you can understand each other. Anyway, beyond that, I just want to let people know we are doing workshops. I know this is gonna come out after the workshops. I actually know the topics on, but I'm planning on doing a workshop every week for an hour about some aspect of building your career and the replays will be part of a Top End Devs membership. So go to topendevs.com slash workshops. You can see all the ones that are coming up and all the ones that we've done. Um, and then, you know, go browse through some of the other series and courses that we're putting out. It's still a relatively new thing. So it's not a deep catalog yet, but, but we're getting there. And then I'm working on doing the same thing for podcasters and that's going to be a podcast playbook.co. So if you're looking at starting a podcast, you can do that. Um, to be perfectly honest, a lot of this is also down to coaching. So, you know, I'm coaching people on their careers. I'm also coaching people on starting their podcasts. Sometimes it's both, right? They want have a developer career and anyway, so if you're interested in that, go to topndevs.com slash coaching, but yeah, I'm really interested in just helping you get further ahead. So anything I can do there. Happy to do. All right, Dan, what are your picks? 

DAN MYeah, great. Thanks. So loved in Kanto by the way. And then as far as auto AI, I just had a big feedback. My wife does a lot of transcription and she loves the script. So I don't know if you've looked at that, but loved it. My picks are, I actually been working on some eBooks lately and I really enjoy the Lean Pub process. So I want to kind of give a shout out to Lean Pub. And then I have actually 

CHARLES MAX_WOOD: good folks over there too. 

DAN_MOORE: Yeah. Are they? 

CHARLES MAX_WOOD: Yeah. 

DAN_MOORE: I haven't interacted with them other than to give them some money, but the security engineering book, which is by Ross Anderson, which is, I ordered it. It's like an $80 textbook, but it is one of the best kind of, well, I'm, four or five chapters in, but it's been one of the best textbooks I've ever seen about security because it doesn't kind of jump right to math or cryptography or anything like that. It really talks about kind of the overarching principles of security. And you can actually, if you Google the author, Ross Anderson, he has chapters, old chapters of his second edition on his website. I think the whole thing might be on the website, but, and then he has some chapters of the third edition. It's just been so interesting to me to, cause again, I'm a developer. I've, you know, security has been a non-functional requirement for all my career, but it's really great to take a step back and look at it from the perspective of a kind of a textbook, a textbook view. So that'd be my pick is the security engineering book. It's big and green and it's a third edition by Ross Anderson. 

CHARLES MAX_WOOD: Awesome. Well, thank you, Dan. This has been fun and it's always interesting to kind of dive into some of these infrastructure things that we plug into our applications. I'm just going to wrap this up here. Until next time, folks, Max out. 

DAN_MOORE: Thank you. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.