OAuth 2.0, Oz, Node.js, Hapi.js

Welcome back everyone. This is the changelog and I'm your host, Adam Stikoviak. This is episode 178 and on today's show, Jared and I are joined by Aaron Hammer for an awesome show on Happy, Node, OAuth, and a deep discussion around security, specifically talking about Oz, Aaron's replacement for OAuth 2.0. We had four awesome sponsors for the show, Coach Ship, Top Tile, Casper, and Imagix.

Our first sponsor of the show is Coach Ship. They're a hosted continuous delivery service, focusing on speed security and customizability. You can easily set up continuous integration with your application today in just a few steps and automatically deploy your code in your test pass. Coach Ship has great support for lots of languages, test frameworks, notification services, and they even integrate with GitHub and Bitbucket and you can deploy it cloud services or even your own servers.

Get started today with their free plan. When you upgrade to a premium plan, use our code, the changelog podcast. And with that code, you'll stay 20% off any plan that you choose for three months. Again, that code is the changelog podcast.

Head to coachhip.com slash the changelog to get started and now onto the show. All right, we were back. We got myself here, Jared here. We have Aaron Hammer back on the show.

Now, Aaron, it's been, wow, I don't even know how long it's been at least a year and a half since you've been on the show. The last time you're on here, we were talking about Node and Walmart and Black Friday, what a triumph that was. So welcome back to the show. Hey, glad to be back.

And Aaron, I guess I don't whether you're in show for you, but whenever you come on to show like this, how do you introduce yourself? Oh, it's, it got much easier now. Yeah, I'm the founder of a very early state startup called Sideway, trying to make sharing conversations more interesting and fun, really early stage. And before that, I spent three and a half years at the Walmart leading the mobile web services team building among other things, quite a big portfolio of open source projects for Node for building service side applications.

So that's kind of where I am. Before that, I spent a bunch of time doing web standards and working on security related protocols like OAuth. And you mentioned Sideway, your very early stage startup. Has any of you mentioned about that whatsoever anything you can share that's kind of a secret, maybe no one knows about?

Well, I talk about a lot. I just don't write about it a lot. Basically, it's trying to kind of fill the gap between the high noise, low barrier social media slides like Twitter and Instagram and Pinterest, where people can express themselves, but it's very hard to find audience. And it's very hard to consume it because it's very, very noisy and very low quality, low value.

But it's telling us, James, here and there. And on the other side, you have the full blogging platforms, if it's WordPress and Medium and all those, where it's pretty tedious and expensive to produce content. I mean, everybody I know has a blog post idea everyday and they rarely write it. And so it's all about work.

You have to write and you have to do spell checking on it and grammar and then you have to make sure it's linked and has high value and all that. So what I'm trying to do is kind of like people convert conversations into content. We have these kind of like podcasting, but written. And so you'll have conversation and when you're done with the conversation and the transcript becomes the actual content that you're producing and people can follow the conversation live if it's happening, but then when it's over, they can read the transcript.

And so there's a lot of work involved in building a new kind of basically chat experience that is not optimized for your real-time communication needs, but it's optimized for producing a great conversation. Because if you look at your chat transcripts that you're having, whether it's Hangouts or Slack or whatever, whatever it is, they're pretty terrible. So they get the job down for communicating something in the moment, but if you're trying to read a conversation on those tools after the fact, it's just completely useless. And so the challenge here is to come up with a world user experience that can basically convert these kind of conversations into really great reading transcripts.

So it's interesting whether it's an interview or more if it's down the whole style with just a casual conversation. So is this something that just for yourself or is this something that just for me with other people? I, some of the guys I myself recently closed a small seat round and hired my first employee. So we're a team of two now.

Nice. Yeah, so that's what I'm doing spending most of my time on these days. I'm also doing a significant amount of open source work, keeping happy going and also doing a good chunk of consulting work with a great company called NearForm. So yeah, it's pretty much that busy.

Interesting. So seat rounds, a little bit of side work, a little bit of open source work, obviously, because you can't put that down, especially whenever you did such a good job transitioning happy, whenever you left Walmart. What can you share about your departure from Walmart and just sort of the, I guess, whatever you want to share about your personal breakup, I think you've blown about it quite well, but specifically around the community around happy and how well that transitions or any insight you can share with the open source community about that. It was pretty clear internally about two years ago that the organization was getting to a point where they got what they wanted out of the project and that the resource spent wasn't really sustainable at those levels moving forward for this particular project.

So basically, the feature set that happy was providing Walmart seems to match their requirement quite well in these side block fixes and small enhancements. It was clearly moving into direction where we couldn't justify having four people full time working on that piece. And so we worked really hard in order to increase outside involvement. And it was done in two, like the long tail and the super high quality involvement.

So we build a relationship with companies that had interesting happy and made sure that they're also contributing resources to the project. And at the same time, we made sure to put a governance mile in place that will really reduce Walmart's presence in terms of control and some association with the project so that people outside feel more comfortable contributing and getting the credit that they deserve without feeling like, now either they're affiliated with a company that they don't necessarily want to be affiliated with or just giving free work to Walmart to then go and boast about. So this was a long process and it was not just a community process, it was an engineering process because in order to get more contributions and diversify your community, you need to have more active developers. I'm a big believer in the benevolent dictator model of open source.

I don't like other models very much. I think there should be someone in charge because someone can make the final decision. And if you don't like it, you can fork into your own thing. That's something that's actually in our last show, Jerry can help me out with this, but wrong.

He was just lamenting on this with open source that you can go and say, trying to find who's in charge and go back and listen to him. He's like, no, he's in charge. He's like, ah, how it drives and crazy, because it's good for open source that it is open, but it's bad that there isn't really someone in charge that can say, here's where we're going and drive like he's with the VDFL model. Right, so a few things happen.

One, have you got too big for me to be the, I couldn't really be benevolent. It became a huge amount of work. And I got the point where I was slowing things down because we had 30 to 50 modules and I was basically responsible for all of them and I just, it just was too much. So, and Corey, happy Corey, we got so big that, you know, like we had everything inside, the router was inside, cookie parsing was inside, bunch of security stuff was inside, file processing, you know, view rendering, like all these features.

And what we did is we broke it up and everything that could be moved out was moved out. So it was, it wasn't a question of what belongs or did not be long in court was can we, from an engineering perspective, move this piece of software somewhere else. And every night we could we moved out. So we kind of smashed the core framework into a lot of tiny little pieces.

And then, I think I said, hey, who wants what? And in order to take over one of those pieces, all you have to do is just gonna show up and start working on it. You know, they all had no documentation. So the first thing you do is you go and add documentation and kind of clean up the code and more tests and show that you're willing to put in the time on the, you know, kind of annoying pieces, right?

If someone is willing to do documentation, that's a good sign that they'll be willing to do the much more exciting work of writing code. And so we know that at the same time, we also want to make sure that we're welcoming to everybody. So we put in a code of conduct, we put in, we put a bunch of effort into getting a more diverse core team. So we recruited prominent community members that are not just white men.

In order to kind of change the face of the project, so the project is more welcoming to everybody. And the goal wasn't necessarily to like, you know, have better statistics about how many people, you know, from different backgrounds are participating. It was more that if someone comes in, they look at the project pages with the team, they can say, okay, well, you know, I can see people like me there, I'm not gonna be like, you know, the first of my 100% group in our environment. And I'm not sure how actual success we had ultimately in changing the percentages.

But at the same time, I think that we created a very welcoming environment so that, you know, and some of the stuff succeeded, some of it didn't work, we tried to do a mentoring program, but that is something we're still trying to get working, but it's so much effort to maintain it that, you know, that's always tricky. But yeah, so we kind of broken into pieces, but the governance model that is kind of codifying how the relationship is between the different modules and the different, you know, lead maintainers who are their own, you know, their own benevolent dictatorship for their piece. So we did put it all in place. We got, I think at this point, Walmart employees account for probably one to 4% of the active maintainers on the ecosystem as a whole.

And that was great. So it was a long process, but it was a very planned process in order to take something that was very much a corporate sponsorship set up and move it into a completely community-based environment. And we actually recently introduced a sponsorship policy so that companies can't get their logos and their name associated with the happy module so that they, you know, people who are getting paid by their company to do this work and give some benefit back to their company. And notice in the read me that the site logos are actually, so that there is some sort of sponsors option for happy.

Yeah, that one is funny. Basically the, I kind of calculated on the cost, kind of like my lost wages on happy work every month is between, it's between $3,000 to $6,000 a month in terms of if I take the hours I'm spending on the project and I was just billed for them at my extremely overpriced rate. And so I kind of decided like I'm not quite ready to go and get other people to do the sponsorship. I'm almost there, probably like a month or two away from that.

I'm probably gonna wait for another major release. And then I'll just say, hey, if the company wants to put their name on the read me, get a few tweets from the happy account about the sponsorship and basically cover my cost of doing this work then I'm probably gonna do that to some of the two, three months arrangement. But for now, basically when I do happy work but it's not directly benefiting my own startup then it's basically my startup is paying for it in a way. And so yeah, I put that up there.

We'll see where it goes. It's not a new territory. I haven't really seen projects doing that kind of temporary sponsorship of open source. That's interesting.

I think it's an interesting amount of, if someone that was listening and they were like, hey, I wanna sponsor happy one month or something like that. How would they submit an issue, get into it probably what's the best way? Oh, whatever they want. They can email us all over the place.

They can do what they know. Yeah. So they're comfortable. Usually companies don't want to be public about asking to sponsor.

And so my email is everywhere. It's Aaron at hammer.io. If you can't find my email, then you probably can't read. There you go.

That's always interesting to think about the copyright and the licensing permission that goes into these sponsored community projects, especially when they seem to like spawn out of Walmart and then become a community project. Looking at your license, it looks like there's multiple copyright holders. Can you speak to that? Yeah, so copyright is really simple.

It's basically whoever creates something has the copyright and then you can't technically ever waive your copyright. You can assign it and you can kind of give it to someone else. But copyright law is really, really tricky and also doesn't really matter much because for the most part, you can't really sue people for the vast majority of copyright on code. But the bottom line was we kind of asked everybody and we kind of looked at how the BSD licenses set up.

And if you see the license, it just says that you need to retain the copyright statement from any previous code you've used and you need to retain the terms. You don't have to retain them as an atomic unit. So originally, happy started with Yahoo and a lot of the initial code just lifted from the post-mile project that I worked on at Yahoo and then Yahoo opened source before I left and that was copyrighted to Yahoo. And if you look at the happy core license, it's basically saying it's copyright to Yahoo, it's copyright to Walmart, it's copyright to other people.

Anybody who contributes basically has a piece of the copyright and then by contributing, you're basically buying into the BSD license that's sitting there. So it's at some point it became just hard to maintain that list of copyrights because every pull request you technically need to go and add that name to the license. So we just ended the link, we have the lawyers and the lawyers said, yeah, it's perfectly reasonable that you have a link to say, you know, here are the main copyright holders, you know, the vast majority of the code, but then there's all these other people. And so copyright is held by whoever contributes the code.

If they work for an employer, then their employer has whatever rights they agreed to. And all we do is just say, hey, all of you are bound by this license agreement. And so when it's time to decide on a new project, like who gets their name on the license, who gets the other contributors, right? That's not the main question people have.

And to me, it's usually whoever starts something get their name. So whether everything I started Walmart, Walmart got their name there. Everything I started after I've left got my name on it. If something was started by someone else, then they can choose who they want to be the primary copyright holder on.

Ultimately, it doesn't really matter as long as it's not out of control. So I would say that if I'm contributing signature into something now that will start somewhere else, I might go and add my name as another copyright holder because I'm doing significant work. But it's kind of more of like a credit for big contributors than anything legal. The other contributors clause kind of covers it.

And in practice, because it's only a copyright license and it's a very liberal one, it doesn't really matter at the end. You can't really do anything about any way. Yeah. Was it VSD from day one?

Yeah, it was three clause VSD from day one. That's the one that the Yahoo lawyers asked to use and since that was the one. You know, once you switch to something else, and that's face it, all the copyright, all the MIT and VSD and all those are exactly the same. You know, one will give you a little bit of liability.

I won't give you a little bit of brand protection, but it's all nonsense. It's basically do whatever you want and, you know, if we suit you, the person who has the more money will win anyway. So were there conversations at Walmart about licensing or was it just, you know, you were trusted to do what you thought was appropriate? We had, I come through with the lawyers.

Walmart lawyers were focused more on trademark issues than copyright issues. It's, you know, it's a bigger concern for them. Trademark is a, especially for a company that's, you know, basically selling brands and is in business with pretty much every, every manufactured good electronic or otherwise in the world. The trademark relationships are really strict.

And so they want to make sure that they're not opening themselves for liability and they're not, you know, people can go out after the fact and kind of take credit for the work. So what we've done is, I've kind of worked with them and that's really great team, the legal team there. And we basically did two things. One, we made sure that none of the marks were using are trained like anybody else worldwide.

So we're not infringing on anybody else's work. And at the same time, we kept everything public domain. So as a matter of policy, we did not trademark a single happy related mark, not no logos or names. And so they're basically in the public domain.

So in fact, everything is just covered by the BSD license. There are no trademarks and happy. It's all just copyrighted stuff. And you can do whatever you want with it.

That covers the logo, it covers everything else. We even removed the copyright statement from the website, you know, it's basically the same as all the other licenses. So it's, it's a little different, I think now. I think that Happy was the very first meaningful open source project done at Walmart.

And so the organization was catching up with us. We were basically doing things. And after the fact, they came and said, oh, I guess we're doing open source now. So maybe the files have it.

And so we, as a general, the team I was part of, I can say pretty much everybody that is relevant is left as well over the last year. But basically, we were kind of like, you know, do an S forgiveness kind of attitude versus first, you know, go through the entire corporate ladder and make sure it's all proved. But in practice, Mike, I had extensive engineering IP experience. You know, I play a lawyer on the internet.

And having done three full years of Yahoo working with the legal team there on exactly this kind of stuff, all but, you know, copyrighted patents and trademarks. I have a pretty solid understanding of it. So whenever we did something without asking permission, the lawyers came, you know, semi freaking out about it. And I was saying, oh, yeah, we know, here's what we did this.

And here's what we did this. And here's what the policy. They were like, oh, I guess you know everything about this already. And so that was really helpful.

It really helped create the kind of trust that they needed in order to feel comfortable. We're not doing something, you know, particularly stupid. And then the other thing is, which made things really easy. And that's not like an advice for everybody who wants to game the system is if you fork something with a license, you're basically making yourself life, sorry, you're making your life really easy.

Because you can just inherit what's going on there. And the lawyers can't really argue anymore because it's kind of required for you sustaining that license. So find yourself a product with very little code, fork it and change something else. But it's like a loophole in all these big corporations.

And so I know it came to the extreme. But basically, if you join a company, if you're the day before you join, you go and open source of the time you're working on it, then it's much easier to get the legal team to just agree with the terms that you set up there than if you're starting from scratch. And now you have a... So all we need is a bunch of shell projects with each license available for forking.

Yes, pretty much. You think fork away the empty folders. You need to have something for something in there so that when you go to the legal team, the big shot lawyers are not stupid. So they'll say, hold on, there's no code here, so why can you just start from scratch?

So there basically is. If you are forking a particular Jared said, that's sort of a shell project for license only. Yeah, so it's helpful if you're starting from something that has some meaning and some value to what you're doing. But it's really a great system because once you fork an existing piece of fork, the default requirement is to just keep that.

Switching license is tricky because now you have dual licensees and some code is under this, some code is under that and nobody likes that. It's also generally easier for most companies to allow you to contribute to an open source project and to open source their own stuff. And so really if you're instead of creating original work, you are doing a fork or contributing something else, the legal stuff within big companies becomes much, much simpler to manage. So there's a lot of way of gaining the system, but ultimately if you want to make your life easier in a big corporation, being versed in the area is really important because the lawyers, if they feel comfortable, then they let you do a lot more.

I mean, the same thing with security. I mean, I did, I got yelled at multiple times for posting code snippets on just from like Walmart code during Black Friday and the InfoSec team, immediately found it and freaked out that there's Walmart code now being shared and it has port numbers and other security stuff and they freaked out. And I was immediately called to the principal office and I was immediately able to tell it, well, I said, first of all, maybe you look up who I am and they looked up and oh, okay. We're using all these protocols for security so maybe he knows something.

And then I said, well, your concerns aren't, he said, you can't publish this and this and this and this. And I said, well, all the ports have already been changed. All the sensitive, passive, all have been changed. So basically what we posted is exactly what we're running, only not and everything that's meaningful for anybody to understand that anthropology has been already changed in a random way so that it's not even, and so they saw that and they're like, oh, I guess it's okay then.

And then the next time it happened, they basically said like we just want to confirm that you did that already on all this stuff, right? It wasn't like freaking out. It's just like we just want to cover our assets. Yes, we have told you that you can't post this confirmation and you agree that you didn't.

So it's, if you give the, you know, a lot of these, these policies are important by the same time that people who enforce them are sometimes they care more about for taking their jobs and for taking the actual IP or security of the environment. And if you just make them comfortable, then that goes a long way. I'm glad you mentioned Black Friday because that kind of leads us into the next quick topic. I want to mention, but I do want to take a quick break before we do that.

So let's break and hear from a sponsor. And when we come back, we're talking a bit about Node, specifically the foundation, the formation of IO and then a lot of stuff has changed in STEM. So we're right back. Say hello to top tile designers, our friends at TopTow have done something really, really awesome.

They've expanded into a new market. They're talking designers. TopTow has been known as a thriving network of some of the best software developers and engineers out there, many of the developers in their network. No extremely talented designers.

And they've always had this sort of informal relationship with designer involvement in TopTow. They've done a little bit, you know, but it hasn't been an exact, you know, product, so to speak, or internal model. And so they've expanded, they've evolved today. They're extremely excited to announce the official launch of TopTow designers.

What this means now is the same experience that you've had on both sides of the fence, whether you're someone that's looking for really awesome designers or you're a really awesome designer, looking for really awesome opportunities. This is the place for you, not only if you're engineers, but also if you're designers out there as well. So designers, listen up. It is time to go check out toptow.com slash designers at steop.tow.com slash designers.

And tell them that she's all sent you. All right, we're back with Aaron Hammer. And Aaron, it's been a while since you've been on the show. And the last thing on the show, you were talking about those performance at Walmart on Black Friday.

This was a pretty interesting conversation. And as a matter of fact, me and Andrew Thorpe was hosting the show then. And Jared, you weren't on that show, so that's a bummer. But since then, Node was Fort.

Iogs was created. The Node.js Foundation was formed. And ultimately, I own Node decided to reconcile. I haven't been keeping up day to day for the past few months on exactly what's going on there.

So if you know anything, feel free to school me. But you did write a post that had some pretty clear thoughts from you. And just quote one thing you said was for the sake of full disclosure, I'm genuinely opposed to any foundation. And this was a wide enough support of Node Foundation.

And this is probably back in that drama days. What's happened since the last time we talked to you around, know that it's interesting to you that you talk about here on the show? So I think a bunch of interesting things have been going on. One is that contribution and participation has really skyrocketed.

I think that the drama part was somewhat necessary, given that their cooperation involved and legal agreements and copyright and names and all that stuff in trademarks. And it took about a year of this path, a little portrait path. But it took about a year to get to a point where the community could fully own the project and set course and decide on the things that mattered. I don't like foundations in general.

I think it's just a way for people to make a living off corporate money without really adding value. I'm not accusing the Node Foundation of any of that. And right now, most of the work is done by Michael Rogers, who is awesome. And in general, Michael gets a blank check for me in terms of drafting into the right thing for the project and community.

So I'm OK with the current staffing. I don't really care much about the foundation part. I kind of think it's unnecessary. And I personally don't find any use for it.

I was doing just fine working with the joint people. I had great collaboration with them. And if I have to collaborate with someone else, that's fine. The more interesting part for me is the fact that the project now has significant amount of contribution and is able to move faster.

IO was a good phase as well because it kind of gave all these new contributors and new core core members. It gave them a little sandbox to kind of play and mature and grow up and understand how to run a project with a tremendous amount of influence and importance in a responsible way. When IO was going on, I didn't really want to touch it because it was just crazy. The amount of changes and the amount of just modification and add-ons and just noise that was going on was just unmanageable.

I can't imagine anybody with a day job that is not full-time, working on Node, core was able to keep track of anything that was going on there. And I think a lot of people felt, and the people who were using IO were primarily the people who either just like the latest of anything and don't really care much about it, or they just really needed the new V8 features, the new ES6 and so on. And that was not available to them in the O10 releases. So now, things are kind of different.

And I think that version four represents a significant milestone for the project. I've been using it for a couple of months now. I'm really satisfied with it. I'm using it for, you know, for sideways, I was going to be all starting from Node four.

For another project I'm doing as part of my consulting work. As far as I'm concerned, that's what everybody should be. It will take a few more months before some big players will move their environment to Node four and kind of come back and say, yes, we're running it at scale, and it's working really well for us. The kind of, you know, Walmart, Black Friday, memory leak story, we know there's more of those in there, and so we just need somebody to find those first, or at least give us the confidence to know that the code base is sufficiently solid, that even if there are problems, they're not going to be devastating for you once you reach scale.

I don't think we're far from that point. I think we're almost there, but that's not where it is. And as far as, you know, I'm concerned, you know, I moved happy to Node four. Version 10 is no longer supporting happy Node zero 10.

It still works with it, but we don't write any tests with it, so we are no longer guaranteeing that it will work. And also we have said that even, you know, within version 10, we're going to start using Node version four features in there, so we're going to start using constant let and error functions and a bunch of those features that will completely break on zero 10. So what are some features in Node four that have you excited? I'm most excited about just the project using a newer V8.

Honestly, I'm not one of the, those people who are super excited about all the new language features. I'm excited about Let and Const, just because they finally make sense in terms of proper scoping of variables. But the other features I don't really care about that much, I'll see how I like them as I use them more. I'm probably just, I really just want to get access to the latest V8, the performance improvement or significant amount of bug fixes that are included, the fact that it's running the same version as Chrome, which makes it a lot easier for quick testing of things and kind of having the same performance profile across the client and server.

So, and I think those are those significant improvement. But I also, I'm glad that the project has more people working on it and so it's, the team is more responsive now to issues and it's kind of more democratic now. You don't need to have. Did you ever have any particular issue with joins and it's the way it kind of helps node move along?

Not really, I'm a big fan of Joant and I felt that up until the point where the financial discussion started, I felt that they did a pretty good job leading the project and promoting the values that were of main concern to me, which was mostly stability and security and performance and those things were working well. I think that there was a lot going on, both internally at Joant with the new CEO and some internal changes, as well as around the community with a bunch of new startups focused on node and trying to make a living off node, as well as more of the big players, if it's IBM and Oracle and others like that, who start showing interest. And it got to a point where the status quo was clearly not sustainable. And I think that at that point, Joant in hindsight could have managed that transition better.

But that said, I don't think that they were completely unreasonable in the way that they acted and ultimately, with their new CEO, they came to the right conclusion and they did a pretty smooth transition to the environment and to the foundation. And at the same time, the definition was set up purposely to make it really easy to merge it with the IO community so that that was all done very well. So there's a typical corporate flexing and trying to get the most out of the situations for your shareholders and your own corporate needs. But ultimately, I think that it took time because it was a dramatic change and people had to be comfortable with it, especially within their corporate boards.

But I don't really think that I was an insider and I was pretty much everything I was going on from the very, very beginning. I knew about the things growing on even before all the other players knew about them just because I was in the middle and everybody was treating me as a confidant. And so I kind of was able to get a big picture a long time ago. And everybody had a great intention.

Everybody was approaching it from really the right motives and primarily with the project well-being in mind, the reason people can disagree. So I think that the drama played out, some of it played out because people like drama, and so it's fun. But ultimately, I've never seen that as an issue. And even throughout the process, I kind of blogged about it and tweeted about it.

And everybody, if you want drama, you can enjoy it. But otherwise, you can ignore this. It's just noise and everything is good. And keep using it.

It's still the best platform to use. So no, I don't have a concern. I think for the most part, I've never seen companies behave like companies when it comes to open source. I've seen people working for companies, sometimes making bad calls on open source policy.

Sometimes your legal team is a little too eager, and they don't want to take risk. But ultimately, it's about making sure that the company understand the value, what they're giving up, what they're gaining. And for the most part, participating in open source is a huge asset for being with every company out there. I guess when it comes to companies, I guess big as Duane or Walmart, if, for some reason, we had the ear of someone inside of a company like that.

It was like, maybe they want to do more in open source, but they're not really sure how to approach it. What are some, I guess, now that you've gone through a couple different scenarios, what kind of advice would you give to corporations other than how they should approach open source and what they should look at towards value back to them and value back to the community? Open source is like any other scale. You need to bring experience people to the table to help you out with it.

Companies that have done a bad job have typically tried to do it on their own without learning from anybody's experience and we are using other people's help. So if a corporation has the resources and is looking to invest seriously in open source, they should go and bring in someone who is an open source expert, whether they are a policy maker, which is the approach Yahoo took, they brought in someone when I was working there to lead open source policy and he did a great job setting up a good balance between what the company was going to afraid of and what the engineers wanted to do and kind of where the balance, what the balance approach would be. You can do something that's more like, what Walmart end up doing, maybe not consciously, but just hiring a few people that brought in a significant amount of open source experience, whether it's Ben and Dion or myself or other people to the organization that can help them, can kind of hold their hand and say, hey, look, open source days, this is why we're doing it. We know how to do it correctly to gain value.

So it's the same way that if you have a company that has never done node before or JavaScript before, you're not gonna go and hire job engineers and buy them a JavaScript book and say, learn this and let's build everything in JavaScript now. That would probably be a terrible idea. What you do is you go and you find people who are experiencing the area and you hire them and then use them to leverage other people and grow. So open source is the same way.

It's a really complex ecosystem between the tooling and the community and the legal part and also just managing the logistics of an open source project. You have to understand the cost involved, it's not cheap and you have to understand the pitfalls, open source projects against no traction is really bad. It can actually cost you more than if you did nothing. So you kind of have to understand those things.

And at this point, there's plenty of experts. And if you don't have the money to, or you just don't want to hire someone just to manage open source policy, hiring, go find a really successful open source project and hire that maintainer and ask them to be your guide to do open source. So there's all these different approaches on how you can navigate it, but it's not just a matter of taking your source because then dumping it on GitHub, that is not open source, that is just show and tell. Well said, well, let's take another break.

When we get back, I want to dive deep into the topic at hand, really, your thoughts on OAuth and your replacements, your OAuth replacement, Oz. So let's take a break and we'll kick off that topic. Guess what, everyone? We've partnered with Casper, the online retailer of premium mattresses to give you $50 towards your new mattress.

The mattress industry has inherently forced consumers, myself included into paying notoriously high markups and Casper has revolutionized the mattress industry by cutting the cost of dealing with resellers and showrooms and they pass those savings directly onto you. Their mattress is a one of a kind, it's a new hybrid mattress that combines premium latex foam with memory foam and the Casper experience was designed with you in mind and optimized for sleep. And this is my favorite part, it's backed by a 100 night, no hassle return policy with full refund and a 10 year warranty. And what's even cooler is how they ship this mattress to you.

It comes in a box that couldn't possibly fit a mattress and when you open it, the mattress unravels for you to lay down and catch some Zs. Head to Casper.com slash change log and use the code change log when you check out to get $50 for your new mattress. Enjoy. I were back with Aaron Hammer and Aaron, this call started as a tweet, I guess, in a way, right?

As they all do. As they all do. And I thought I had my notes here perfectly, but I didn't. And I went away from my tweet that I had saved me.

But long story short, you were announcing Oz and you were saying, hey, I don't want to give me talks about Oz right now, but I wouldn't mind coming on the podcast. And so I chimed in and said, hey, well, technically the change log in me as the change log in. And here we are. So this is pretty interesting.

So what is happening, I guess, with OAuth one, two, and then this rode the hell as you've said. And what the heck is Oz? So that's interesting, because a lot of, almost all my cool stuff from the last couple of years all came from this Yahoo post-mod project. And Oz is also a byproduct of that work.

I was working on OAuth and OAuth 2. I think the story about me and the messy divorce with OAuth 2 is well-known. If you don't, there's some highly entertaining blog posts and videos online, enjoy. And the way I look at it is that when I stop working on OAuth 2, I felt that once I had enough, I just spent four or five years on doing that kind of work, and I just couldn't take it anymore.

But also, I felt that the atmosphere wasn't very conducive for meaningful alternative at the time. I felt that we tilted too much to the side of convincing people that the security provided by OAuth 2 was just good enough. And it was so much easier to use and so much less to develop a friction, that if it's good enough for Google and Facebook and Yahoo and Microsoft, then it must be just good enough. The problem was that, like I said back then, OAuth 2 is an outline.

It's not really a useful implementation. If you took OAuth 1 and you did a compliant implementation to the spec, you got pretty good security out of the box. It's very hard to implement OAuth 1 insecurely in terms of the protocol itself. Yeah, you can always leak stuff and just do stupid things.

But the message flow, the workflow, the structure of the tokens, all that stuff is pretty solid. With OAuth 2, because of all the compromise that were made, it just became an outline, which meant that if you are Google or Microsoft, you can hire the best security expert and can write the great implementation that will be very secure. But if you're not, then what you have is a, whatever random stuff you end up understanding from it, and you just have a simple bare token protocol where if that token leaks out, then it's game over. And if you look at the implementation, for example, the vast majority of OAuth 2 implementation today don't expire their tokens.

So you get a token from, I don't want to put anybody on the spot, but there's, I'm sure if you've used OAuth 2, you got an OAuth 2 token and you've gotten pasted somewhere, and you're happy and it's been a year now, two years now, and it's still working. That's pretty bad. If you think about it, you have this really long-lasting credential that has no security attached to it. And if anybody gets hold of it, an employee with the company, they take that token with them, and now they have access to all that data.

And you can even tell that it's them, because there's no traceability, there is no binding to the identity of whoever's making the call and so on. So I kind of look at the environment and I said, that's not for me, I'm not going to use it. And so I started playing with two protocols, Oz and Hawk. If you're familiar with OAuth 1 terminology, there was the three-legged and the two-legged, where basically if it's just client server, and you're just using the signature stuff, you're not really doing any of the dans of authorizing it, you're just using it as basically a replacement for basic auth.

That was the two-legged use case. And then the three-legged was when there's an app, a server, and a user, and the user's authorizing third-party access. So I kind of split those two concerns, and Hawk is the authentication protocol. It's basically like basic auth, which I just off.

It's just a client server authentication that's using a holder of key principles, a little bit of crypto. If you look at the code, unlike OAuth 1, it's super simple. It's basically taking OAuth 1 in terms of the signature and bringing it to the modern era. So OAuth 1 is so awful because it was designed to support PHP 4.

And PHP 4 didn't give you access to the role request URI, so we had to reconstruct it. This is why we're doing all this encoding and storing and all that stuff. It's all PHP 4-fold. And at the time, it was a requirement because PHP 4 was the only available cloud hosting environment you could buy.

And we wanted something that is accessible to everybody. And so that's now where OAuth 1 came from. And so I basically said, all the principles around it were solid. They all came from, if you look at the people who developed OAuth 1, some of the best security experience in the world, not exploit known so far against it.

So why reinvent something? If you can just simplify it. So that's why I did with Hawk. And that has been published for a few years now.

It's pretty widely used. And if you're using Node request, you already have a Hawk client available to you. It has been bundled with requests for a few years now. And it's a very simple protocol.

And it works really well for client server authentication. And then what OAuth does is basically takes that and adds the whole third-party authorization on top of it. Now, in the beginning, both of these protocols were part of OAuth 2. So Hawk originally was the Mac token that was supposed to ship with OAuth 2.

And when I quit, the interest in maintaining that work disappeared and it just died in committee, as they say. People just felt that the bear token was just good enough. Then after that, they decided that the right way to do it is with the JSON web tokens instead of anything else. And they don't come with their own set of security, but I don't find it to be good enough, to be honest, because they're not bound to be requested at all.

So I kind of looked around and I said, OK, here's my problem. I'm not going to use OAuth 1 because I'm already over it. It was great to know in OAuth 7, but I need something else. I'm not using OAuth 2 because I rather poke my eyes with needles.

And so what do I use? And what I did is I basically said, I'll take what was good of both of these protocols and the pieces I liked. And I'll throw away everything that's just garbage. I'll throw away all the accessibility of OAuth 2 that I just don't care about.

I'll throw away all the stuff that is not secure enough, like bear tokens. And I'll combine the best of both worlds, the best of OAuth 1, the best of OAuth 2, and produce something else. Now, OAuth could easily be a fully compatible OAuth 2 implementation. There's nothing in it that cannot just be an add-on on top of it.

But I kind of felt that would be kind of productive, because the OAuth 2 mindset, the culture around at this point, is so hostile to any meaningful security. Anything that is a little bit inconvenient. If you have to use anything, I'm like, oh, my god, I have to use some client code now to make API calls? No, that's no longer acceptable.

And so you go to that crowd, and you're not really adding any value, because nobody will use it in that context. So I felt that instead of trying to stay committed to the OAuth 2 track, I'm just going to throw it out. And so when this was part of the written post-mail code, it was basically OAuth 2. So what is called OAuth 2 with a bunch of add-ons, the self-encrypted ticket with request authenticity, and all those things with just add-ons.

And what I did is I just threw out all the OAuth 2 compliant pieces and gave it a new name. And that thing's set there for a while. I haven't done much work on it for about two years now. Most of this code has been written shortly after I left Yahoo.

And the reason why I didn't work on it much, because I didn't really need any use for it. And I don't like working in a vacuum where I'm developing solutions for unknown, soon-to-be problems. And now that I have my startup, I needed something again. And that's kind of why this work kind of got resuscitated and I decided to go ahead and just finish it and properly document and all that.

So that's kind of why it became like news a few weeks ago. But in practice, this was kind of done a long time ago. There's parts of the project that, like you said, go back a couple years. So what was just perfect timing, I guess, with your departure from Walmart and maybe some sponsored time from your current company, which is your startup, that this became your forefront of tension, or is this just a good timing for you?

This is a good time to solve this problem. It was because I needed something. So I said, OK, I'm building this app and I need a security protocol. I need exactly what OAuth 1, OAuth 2 provide.

I don't want to use either one of them. So now what? And it's actually kind of sad that in the last, OAuth 1 was in 0.7, so it's been eight years now. Eight years should be, if you look at most other protocols, look at JavaScript, look at HTML, look at pretty much every technology over eight years.

People are kind of eager to change and fix and grow and improve. And this work has kind of been stale for a long time. And so I needed something and I kind of looked at one of my options and I said, OK, I started this thing a couple of years ago. I liked using it when it was in its previous incarnation.

And I just decided to go ahead and finish it. And to be honest, I wrote it for me. I do a lot of happy work and a lot of the work I'm doing for Happy is not for me. I'm just trying to help other people and kind of grow a community.

With Hock and Oz, at this point, I mostly care about my use cases. And it's a very tricky project to talk about and answer question about because you're kind of making security recommendation guarantees, which I don't want to do, because it's just the wrong thing to do to advise people on security on unknown projects that I don't understand. So it's a really interesting project right now that there's a bunch of codes and stuff sitting there. And when people open issues and asking me really deep questions about how I would recommend them using it, I'm kind of going, well, sorry, I can't help you really.

You can't have to read the code and figure it out on your own because these are all pretty complex security issues. And the tool is really designed for people who really understand all of these principles well and just want to use something cleaner with a different feature set. Maybe speak to the security aspect a little bit because, like you said, making security claims is a big deal. And one thing you can say about a committee or a working group, at least you would think you'd be able to say, is there a group of experts working together to come to sort of some sort of solution now?

In practice, that sometimes is successful, sometimes fails miserably, but it's a group of experts. And I think my first thought when I saw your Oz announcement was Aaron, oh yeah, Aaron Hammer. He does happy JS and he's the Walmart guy that we had on the show. Wow, he knows security.

When I see an announcement of like, oh, I'm replacing OAuth too. It's like, who's replacing OAuth too? There's this question of authority and expertness on the word, but maybe just give a little bit of background or after reading your code a little bit and reading or you're reading these, I was convinced that, okay, he actually knows what he's talking about. But do you have to give authority sometimes or do you have people questioning your ability to create security protocols?

I mean, if you know my background, and if you look at the OAuth specs, my name is Olavrit. Well, there was the example you said earlier at, I mean, there was the example you had earlier when you wrote Walmart with the InfoSight people about the gist that you were posting. You're like, well, you know who I am. So you have to throw it on kind of like your authority there too.

Yeah, I do it once in a while when I actually have to. But basically, yeah, just like going to Wikipedia and look up OAuth and then come back. But it's, I'm not a security expert. I mean, I'm very well versed in security and I am an OAuth expert, you know, after spending a few years serving my time.

And what is really, really key here is that, one, I'm not trying to be about anything new. If you look at what this does from a protocol perspective, it's exactly the same as what OAuth and OAuth 2 are doing. And if you look at the implementation, that's really where the scrutiny should be focused on and nobody does that. And so one of the complaints I always had about, you know, people saying, oh, it's a compliant, an OAuth compliant implementation.

And I said, well, you look at an NPM and you find an OAuth module and it says it's compliant and you're trying it out and you're working well. That doesn't make it secure because you have to look at a source code and understand how it's operating and where it's storing its information and how it's generating its randomness and is actually verifying the nonce or not. And if you look at OAuth 2, it requires a whole bunch of server validation that if you don't perform, the protocol will still work perfectly well. You know, it's not gonna fail you.

And so it's very misleading to say that a spec is secure. Implementation can be secure, specs are not secure. You know, they're just paper, it just works. And so that has been kind of my right against, I'll get most of the OAuth 2 and even somebody off one crowd is that, you know, people saying, I'm gonna pick OAuth 2 and that makes my system secure, like, no, it doesn't.

And what I want people to do is to, it's a little bit of protocol, like, you can look at OAuth and serialize a protocol. It's, if you know what you're doing, it's very easy to do. And I do have a bunch of, you know, the same, you know, top level security expert that have looked at OAuth, have looked at OAuth and, and, and, and, and give it their blessing. You know, there's a lot of, like, building involved in security.

So nobody, I'm not gonna put their name and say, this has been approved by, you know, X and Y. But I feel very confident that the protocol itself is solid and it's basically identical to OAuth. You know, parameter names are changed and, you know, some of those things are different, but fundamentally, it's exactly the same protocol. What's much more interesting and important is the code I wrote and how it implemented.

And I'll give you, you know, one concrete example. OAuth 2 was created specifically to help Yahoo and Google and Microsoft scale their OAuth operations. That was the main concern they had. The secondary goal was to make it easier for developers to use, but the primary goal for them is to scale it.

And what they wanted to do was to make the tokens self-encoded so that when they get a token, they don't have to do a database lookup to find out if a token is still valid. What they wanted to do is to decode the token using, you know, some, some kind of crypto. And then inside of it, they'll find information they need it and that was good enough. The thing is that once you have this kind of design, it's a very highly scalable design because there's no data center.

You don't have to synchronize your storage across, you know, multiple locations and all that. So it's great, but now you have credentials that don't expire. Cause if the credential is self-encoded, if the credential itself includes what you need in order to use it, then there's no lookup, then you can never invalidate. You can revoke it.

And so what they wanted to do is they wanted to issue short-lived credentials in like Yahoo case, I think it was an hour. And you can use that for after an hour, but after an hour, you have to go and come and get a new one. That's not what you all have to refresh token came in. So if you're using OAuth 2 and you're not using refresh tokens, you're actually doing a really pick-to-service to yourself because you're issuing these long-lasting credentials.

Now, if you are doing a database lookup for every request, then well, maybe you should reconsider that if you have any kind of scale for your authentication. And every API con I had a database lookup just for the token, which is challenging. So if you kind of think about it, now you need to have some kind of self-expiring encrypted token. So the JWT work is doing some of that.

But then there's other layers that are missing. And I can, you know, I can like stack it up for hours, but basically what I've done is I said, okay, I'm going to produce a token that is self-encrypted, that expires, that can do password rotation, that can do all those things, that is going to give you both privacy and authenticity. And I'm just doing it in a way that is going to be solid. So I talked to a bunch of my crypto friends, and I said, okay, how do I do it in the right way?

And what is the right algorithm to use in the right crypto to use? And how do you generate the keys and all that stuff? And I wrote a module called iron. And iron basically does that.

It takes a JSON object and turn it into an opaque string that is fortified. And if you don't understand how to do that, then you can't really properly use OAuth 2. And that's kind of my point is that to properly use OAuth 2, you have to be a pretty advanced developer and understand security and crypto really well, which most people don't. So what I was just trying to do is take all these great engineering principles and implementation principles and just put them together and say, you know what?

Let's talk about this interrupt and all this standard nonsense because nobody really cares. When was the last time you were trying to reuse code across multiple providers? Like, you know, that was a grand vision of like, you know, 2005, 2006, when we were trying to kind of like, you know, make API standards across the web and open up the social web walls. And it is for nobody cares about this anymore.

You know, that's all dead. And so since we don't care about, you know, making sure that the Twitter API and the Facebook API are compatible to each other, and because there's only two of them now and we don't care, you know, when there was like 100 of them, it was painful, why are we bothering with interrupt? So if you throw away interrupt, now you can do whatever you want. And now what I wanted was a great solution for a JavaScript-based environment.

That will work well on the server, well on the client, getting all the security I want. And what I want you to do is to take the code I wrote and scrutinize that, go line by line, and find where I'm doing something stupid versus, you know, here's the protocol documentation and you can kind of say, oh, here's the flow and this is where, you know, you send the parameter in, like, that's not really interesting. It's kind of needed just to understand what I'm doing, but it's not really helping you understand if this is secure or not. But I think that's a key goal of this work, is that I'm trying to shift the focus from an academic exercise of writing security specification to a very practical exercise of writing a piece of code that you can reason about in absolute terms because it's a piece of code, it does one thing.

And then you can find out if that is secure is an end product versus a theoretical, secure protocol. They got three modules, you have Iron, which you said was the cryptographic piece, which basically just takes a JSON object and does, I'm assuming it's like symmetric encryption on it, just encodes that or encrypts that thing. Then you have Hawk, which is the authentication protocol, or scheme, as you call it. And then Oz is kind of the, as the authorization layer, am I breaking those up three out correctly?

Yep, exactly right. Okay, so we're talking about Hawk. One of the things that you say in the introduction to Hawk as a primary design goal is that it simplifies and improves HTTP auth or services that are unwilling or unable to deploy TLS for all resources. And I thought, I stopped there for a second, I thought, why is this necessary?

Can't we just, can't we just be willing and able to deploy TLS and use basic auth? And will that require not having this library? Well, that's just the perfect world, looking at it in the real world, that's not the case. So it's part of the answer.

So there's a really important principle in any secure system and that's to have separation of concerns and layering of defenses. Also known as don't put all your eggs in one basket. And the reality is that even if you are deploying TLS everywhere, you don't have control over your clients. I mean, the TLS protocol doesn't ensure that the client is doing the right thing, right?

The server can make sure that the channel is encrypted, doesn't know if the client is leaking stuff, there's no way of knowing. Doesn't know if the client is probably validating the server certificates, which in most cases it doesn't. I think Rails still doesn't validate client certificate by default, if I'm correct. I don't know, I had to, you know, scream and yell for node dot 10 to change the default to throw on invalid server set instead of ignored by default.

And so if you just assume that the developer will do stupid things, I mean, it's just, because code has stupid things a lot of time. And it's not good enough for you. So if you think about it, in the perfect world, where the credential is guaranteed to be sent over TLS to the right server and not leak anywhere, then yes, bare tokens are just fine. But it's never a perfect world.

And so you have to ask yourself, should I do anything else? And the reality is that if you're sending a bare token to the wrong server, either it's typo or you fail to check your TLS certificate, you're on an airport Wi-Fi and someone is basically giving you bad certs and you have a code that ignores bad certs because that's what most developers do, because it's like, hey, look, it wasn't working and I put this ignore and now it's working, awesome. And you go and stack overflow, see how many people answer questions about bad certs by saying, oh, just add this leg of ignore, problem solved. And if that's the case, then whatever app is not validating properly is not fully exposed because they don't know who they're talking to.

So you don't actually get TLS protection. So I think that's a really important point to make is that it's just not enough. And there's a lot of different ways where you can leak those credentials. That's one thing.

The other thing is that without some kind of crypto, it's very hard to know that the request came from the right person and it's meant for the right server. And I'm gonna try to keep this as simple as I can, but basically if you think about a simple scenario, let's say there's Facebook and then I have an app, I have two apps that use Facebook to log in into them. Because they both use the Facebook token as the authentication key. Because what they do is you go to Facebook, you come back to the app with the token and then the app goes back to Facebook and says, who is this token, who does this belong to?

And then Facebook say, oh, it's Steve, great. Now we can log in Steve. So that token is really powerful. What happens if I trick you into logging into my app using Facebook and I take that ticket that I got for you from Facebook and I got now go back and log in to another app that's using Facebook to log in.

I can now log in as you to the other app. I can't really attack you on Facebook itself. That doesn't work. But I can now, because those tokens are not bound to any, if you remember in OF1, we had everything had to be signed by both the client secret and the token secret.

In OF2, because there's no signatures, there's nothing that binds the tokens to everything in the request. So I can now trick another app to thinking that I'm you using your Facebook ticket that you gave me perfectly legitimately. And so once you start removing these layers, you have all these outcome. And for example, Facebook has a feature to solve that.

When you make the who am I API call, Facebook gives you an option to include with it a hash of I think your client ID or something. And then they'll check for you if the ticket was issued for you. And if it's not, I'll say, oh, sorry, you're using a ticket that wasn't really meant for you. Someone is tricking you.

But it's an optional argument. And if you look, for example, at the, I mean, at least last time I looked at the Node Express Passport Facebook implementation, that feature is off by default. So you get all these details. And look, everything I just said, I'm sure mostly audience has never heard about it and not aware of it.

And doesn't even know that Facebook has this feature that allows you to protect your app from wrong logins. But the whole point that they shouldn't need to, and if the protocol is written correctly, then the protocol may be a little more difficult to use, but at least it does their work for you. And it gives you the protection that you need. It doesn't require you to go and invent your own extension.

So for example, that extension is a Twitter, it's a Facebook invention. They added it to the protocol because they had some attacks on some, I don't know if they're calling it the Canvas apps or whatever they're calling it. People were able to like trick one and kind of like log into another. I don't remember the specific of the export it found, but that's kind of what they've done to solve it.

And there was no standard for that. So now, as the Cure Facebook implementation is no longer compliant with any other off implementation because they had to add their own parameter to the mix. So that's not the reality of it. Which is why all this crypto stuff, it really matters.

The other thing is being able to invalidate these credentials and being able to validate that they're, that they're still, that they're having expired. All those requirements are all implementation details. So in the perfect world, if you're client, to your question, if you can guarantee, if you control your client code, let's say you're running your own private client server implementation. So you have full control of your client, you know what you're doing.

It will never run on hostile networks. You're fully checking the credentials. No one will ever see those credentials outside of you. You know, like if you put all these constraints on it, you don't actually have third party apps accessing your API, it's just your own software.

Then yes, basic off over TLS is just fine. All right, that's an excellent answer. That's like, if you disconnect your server from the network, it's completely secure. I mean, it's, you know, there was a really, there was a really interesting debate, really interesting debate going on, on the Express session middleware a few weeks ago, a few months ago, where Express uses an HMac to hash every session ID so that it cannot be messed with.

And you know, all the people who play crypto expert on internet showed up and basically said that if you use a properly randomized session ID, it's as secure and you don't need to do any crypto to it. And that got brought all the same arguments that yes, in theory of an extremely well-randomized, hard, impossible to guess session identifier doesn't need to be hash or any kind of crypto protection. But it's not where the story ends. And there's so many ways in which that can fail.

He used the wrong crypto function. He used math random instead of, you know, properly secure crypto generator. Or you just don't know it and you kind of somewhere in, you're fudging a different identifier because you like to have them sequential. Or it comes from a database and the database can be hacked and the database ID generator can be managed, can be changed to be non-random.

Like there's all these layers. So it's at the end of the day, when you come to security, it's always, you know, eggs and baskets is what, you know, the two words you have to like ask yourself. Now I think that's a strong point. And I think the layering is a compelling argument of why you'd want to use talk even in scenario described.

We're gonna stop here for our final break. You're from another one of our amazing sponsors. And when we get back, we're gonna close up this conversation with more on Oz. And we're gonna have Aaron describe the protocol a little bit and maybe compare and contrast specifics with OAuth 2.

So we'll be right back. ImageX is a real-time image processing proxy in CDN. And let me tell you, this is way more than image magic running on EC2, this is way better. It's everything your friend and developers have dreamt of.

Outputs of PNG, JPEG, GIF, JPEG 2000, and several other formats. And if you're like me, you've ever argued with your boss or a teammate about serving red images to non-red devices, you'll appreciate their open source of Pinnacle Free, JavaScript library that allows you to easily use the ImageX API to make your image responsive to a device. Now all of this takes a platform. And the ImageX platform is built on three core values, flexibility and quality, performance and affordability.

When it comes to flexibility and quality, ImageX has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformation that you need for your images. And they take quality very seriously. And because of their commitment to quality, several top 1,000 websites in the world trust them to serve their images. Now when it comes to performance, ImageX operates out of data centers filled with top-of-line Mac crows and Mac minis, and they're set up for a completely streaming solution.

This means your images never hit the disk. Images are served by the best SSD base CDN for delivery around the world anywhere extremely fast. And while we're talking about speed, almost all the image processing happens on GPUs. This means transformations are super fast when compared to competing virtualized environments.

And lastly, it's all about affordability. Everyone wants to save a buck. That's how the world works. Because ImageX processes close to a billion with a B images per day, they're able to make certain optimizations at scale and pass those savings on to you.

To learn more about ImageX and what they're all about, head to imgix.com slash changelog. Once again, imgix.com slash changelog. And tell them Adam from the changelog sent you. All right, we are back with Aaron Hammer discussing Oz, his web auth protocol based on industry best standards.

Aaron, you said Oz is not a spec. It's an implementation. You don't really care if it's ported to other environments because what you want is an awesome JavaScript implementation. Tell us a little bit more about Oz.

And specifically, from my perspective, as an OAuth user, I've never written a provider I've dealt with as an application developer quite often. Reading through it, on the surface, it kind of does look like OAuth 2. So I know you've done it a little bit on the surface that during the intro, but maybe give us a little bit of deeper dive into Oz itself. We've talked about Hawk and Iron.

And the compare and contrast it with OAuth 2, perhaps from the perspective of a user. Sure. So OAuth 2 is focused on two main pieces. One is the authorization flow, which is how do you go about redirecting the user from one place to another to authorize and kind of move and pass along the necessary credentials, whether the authorization code or the grant or I honestly don't remember all the terminology I made up for OAuth 2 at this point.

And that's one part of what it's doing. And the other part is once you have obtained a token, is how do you use that token to make authenticate requests? So those are two pieces. And in OAuth 1, they're kind of like all mushed together into one flow and in OAuth 2, we kind of separate that.

And it ended up being two specs. One was the authorization protocol, and the other one was the bare authentication scheme. And then the bare authentication scheme was enhanced later on to use JWT tokens, which are the JSON web token. It's a protocol of taking a JSON object, which is very similar to SAML principles, taking those into creating some kind of credential that is self-describing versus just a random bare token string that we use.

So that's not what OAuth 2 provides. If you look at the three protocols that I have, I think the parallel would be that iron is, in a way, similar to JWT. So it's basically a token format. The main difference is that iron tokens are opaque to the client, but they are meaningful to the server.

It's basically taking a JSON object, stringifying it, encrypting it, and then targeting a hash on top of that, and then also baking into the structure additional features for expiration and pass-up rotation, which is really important for proper crypto hygiene. And so what that gives you, it gives you a token format that you can use. What HOP does is take the part that is completely missing from OAuth 2, which is an authentication scheme that is using some kind of crypto. Similar to how OAuth 1 was written, it's basically requiring you to sign every request.

So every token comes with a token and a secret. You use a secret to calculate a hash, and you send a hash with a request. So in those terms, it's very simple. It's basically competing with the OAuth bare token scheme, only it adds some kind of layer of cryptography and extra security to the security layers.

And then what OAuth does is more of an implementation component versus a protocol component, it's basically taking the elements from OAuth 2. So if you think of OAuth 2, it's basically in the traditional OAuth 2 flow, where you go and you send a user to a page to authorize, they come back with the transition code, then you exchange the relation code for a token. What OAuth does is basically says, we're not going to tell you how to do the flow itself. We're not going to tell you how to redirect.

At the end of the day, that's how you're improving your app. But we are going to introduce the basic building blocks. And so the first building block is that the application itself need to authenticate and obtain its own HOC credentials. So the same with OAuth, where you pre-register your client with the client secret and all that, you do the same thing with OAuth.

You establish a relationship out of bound. And once you do that, you cannot use your client credentials, because basically everything is always HOC. So if you think of OAuth 2, the first step is you're using basically either basic auth or some kind of form encoded credentials to get the initial interaction with the server. In OAuth, everything is HOC.

So it's all secure from the very beginning. And what happens is that the only thing you can do with your HOC credentials is exchange for OAuth credentials. OAuth credentials are called tickets. And basically, it's not going to token, it's called a ticket.

You need a ticket to get in. And a ticket can be provisioned for either the app or the user. So you have two kind of tickets. The ticket itself is just an iron object.

So that's not where it's using that piece. The flow is very similar. The user is being told to go to some server page to authorize access. They go there, and when they authorize access, they come back to the app with an RSVP.

And that RSVP is basically an authorization code. It's a smart authorization code. So it has some stuff encoded in it. And then they go out to the server, and the server can take that RSVP and issue you ticket.

It's exactly the same as the traditional OAuth 2 flow. The only difference is that OAuth gives you APIs to build it, and doesn't forces you to do any kind of the redirection, or which query parameters should I stick the RSVP in? None of that stuff is really interesting. That's up to you.

You can join any way you want. For example, one information I've done doesn't even use those flows. It's just using cookies. So what it's doing is you go to a login page and you log in with Twitter, and when you're done, you end up with a valid session cookie on your server.

And then what you do is you make a call and say, hey, can you exchange the server this cookie basically and issue me a ticket that has the same permissions. And internally, it's using all these elements in order to do that. And you can see how it works there is the original post-mile project that was working on Yahoo is using a study older version of OAuth right now, but it's all the same principle. And you can see exactly how the flow works there in terms of you come to the website, you log in, and then those credentials are sent to the one page app.

And then from there, you're just doing OAuth authentication. Now, OAuth authentication is basically just hot authentication with two extra parameters, which gives you built-in support for delegating access. So you can have one app delegating access to another app, if they're allowed to. That's already built-in.

And it also gives you some support for scoping. So you can scope APIs and it's part of the ticket. So there's all these extra features that it gives you are the box as far as the solution. So that's kind of what it does.

In practice, you can very easily adapt this protocol to be exactly OAuth 2. You can use iron and even use OAuth tickets as OAuth tokens. That will work just fine, as long as you properly sign the request. You can use Hoc authentication as just a valid OAuth 2 token type.

And in fact, it used to be that. If you Google the OAuth 2 Mac MAC authentication scheme, you'll find a very old draft that I wrote that was basically what Hoc is now before I quit the working group. So these are all very old principles. I think the big change here is I'm shifting focus from protocol to code.

And I'm focusing on this implementation instead of trying to create an ecosystem around it. So has that been successful from the perspective of code review and criticism? Like have you drawn to your code base the eyes that you have hoped for? Yes, for Hoc and for Iron.