 Welcome to OAuth in five minutes, a series where we deep dive on various topics around OAuth in just five short minutes. I'm your host Aaron Parecki and let's get right into it. Today we're going to talk about what OAuth is and why we even have it in the first place. As a developer new to OAuth it's often not obvious why it's so complicated and why there are so many steps involved. And as the app developer maybe you could just take the password and exchange it for a login credential somehow. Well it turns out that's exactly how it used to work before OAuth. So it used to be that when you go try out a new Twitter app you would download the app enter your Twitter password it would go then log in as you and then you could use the app. It probably also had to store your password so that it could use it again later the next time you launch the app. Now it's one thing for a Twitter app to do this because you probably kind of trust the Twitter app developer but it's a whole different story when it's for something like when Yelp asks you for your Gmail password to go find your contacts. It seems unrealistic now but yes this is an actual example of how this used to work on the web. This used to be pretty normal you would land on a new website like Yelp it would ask you for your Gmail password it would then go use your Gmail password to download all your contacts and see if your friends were already using Yelp. Hopefully the app wouldn't hang on to your password but there was really no guarantee of that. This is obviously bad for many reasons which we understand now. You would never give your email password to a random third-party app right? But people are happily doing this they were happily handing over their passwords to Yelp or even Facebook. Yes this is a real screenshot from Facebook so even now as developers who understand this is a bad pattern and we really shouldn't be encouraging users to do this turns out we can't actually stop users from doing this because they just want the end result of whatever this app was promising in this case to find their friends. And users will do whatever it takes to get there including handing over their password to really shady apps. Instead we need to find a solution for users to actually accomplish this goal without having them have to give their passwords over to these random applications. So that was the original goal OWAS set out to solve. How can we let an application access the user's data without having the user have to give it their password? So a bunch of people from a bunch of different companies got together to try to solve this and created what eventually became known as OWAS and it was adopted quickly by a whole bunch of different APIs and now virtually any service with an API on it supports OWAS for this purpose. So the main way OWAS keeps users secure is by forcing them to enter their password in only one place at the OWAS server. So if you're logging into an application with your Google account you don't enter your password into the application you enter it on Google. Same with Twitter if you log into a Twitter app you don't enter your password into that application you get sent over to Twitter and you enter your password there. I'm going to save the specifics of how this works for a different video later in the series but the general idea is that instead of asking the user for their password in the application itself the app sends the user off to the OWAS server they enter their password there and then they come back. And of course that process is entirely automated so what the user really sees is they're using the application they click a button they enter their password and then they're logged in. But the key thing here is that separation where the user is sent off of the application away from the app over to the OWAS server and then they come back separately. That is the particular feature of OWAS that keeps users' passwords safe because users are never then entering their password into the application directly. But here's where it gets interesting. OWAS was originally created with the goal of protecting users from third-party applications. But it turns out it's actually a lot more useful in a whole bunch of different cases as well. It makes sense you'd want to protect users from third-party app developers because of course Twitter can't actually guarantee that every developer on the platform is behaving well. But what if you're an organization building apps on top of your own API? And it turns out that OWAS is also useful in that first-party case as well. And that's why you see things like Google going all in on OWAS where no matter what Google app you're signing into you always get sent over to their OWAS server to log in. Try it. If you go to gmail.com and click sign in you don't enter your password on gmail. You enter your password on accounts.google.com. Same with YouTube. If you sign into YouTube you don't type in your Gmail password into YouTube. So what's interesting to me is that the same reasons that we want to protect users from third-party apps is actually also true here as well even in the first-party app scenario. If you as an organization are sending all of your users to your OWAS server to log in you get a lot of benefits as well. For starters it means that you don't actually have to trust all the developers across all of your teams to handle passwords properly. I'm sure you trust your developers but people make mistakes and the last thing you want to deal with is discovering that an application has been logging passwords in a text file for months. So by having one place users enter passwords it means you have just one place and one team that has to worry about security around passwords. It also reduces the attack surface of your system as a whole. Imagine if users are entering their passwords on a whole bunch of different applications. An attacker now has a whole bunch of different places to go to attempt to steal passwords. If they can break into just one of those apps they can start sniffing for passwords. But here's the one I'm really excited about and why I think it makes sense to always use OAuth for everything. Once you centralize the place users log in you now have only one place to go to add things like multi-factor authentication. So let's say you've been using SMS multi-factor authentication for a while but side note you probably shouldn't and that's a different story. But now let's say you want to go use a more secure method like using the Google Authenticator app. If everyone's always going through your OAuth server to log in it means you only have one place to go to add that and now all of a sudden every application in your ecosystem benefits. That sounds a lot easier to me than having to go around to every application you've built and add multi-factor support to each one. So let's recap what we just covered. OAuth was originally created for third-party apps to access APIs in a way that didn't need the user to give their passwords to these applications. Organizations realized there was a lot of benefit to this pattern even for first-party applications and started using OAuth in their own applications and even internally within an organization. You can get a lot of security benefits by using OAuth across all your applications and avoid relying on passwords everywhere. And that is our five minutes. Thanks so much for watching. I hope this has been useful. As always give us video a thumbs up if you found it helpful and subscribe for more videos like this. Thanks so much and I will see you in the next one.