An ODe to OAuth

You can hear me? You can see me? Hello How you doing? We almost ran the marathon. Uh and yeah, my name is Akosh Hawkhrin. I work at a company called Prezi. It's an online presentation tool. We live in the cloud, and I'm going to demonstrate the product a little bit today for you guys. And it's really cool because if you work at a presentation company you learn a good number of things on how you can improve some of your presentation skills. This doesn't mean that I'm gonna be a good presenter today But for example you can learn that if you rub your ears then you can increase your focus. You guys can try it out as well.

Alright, so I'm really good at remembering silly things like this. Do you know what Oh wait a second. Oh there we go. Do you see me? Yes. Do you know what I'm really not good at yet? It's remembering passwords. How many of you use a password manager? Oh yes. Okay, if keep your hands up. So if you are using two password managers, keep your hands up. Okay. Uh how many of you use three or more? I do actually. It's pretty embarrassing, maybe. But so the thing is that the market is flooded with password managers.

And this notion to me is quite ridiculous to be honest. So we have created technical depth for ourselves roughly thirty years ago or f forty when uh whenever the internet and security started and and you know we are still living with it. Um I did some research and uh you know I found like two dozen articles of what the greatest uh password managers and uh tools to help us remember things and generate new passwords and only remember a master password and stuff like this and then you you know you remember your master password in another masper master password and It just gets it just gets crazy. The good news is that uh we've realized that uh that this is getting an issue

a couple of uh well years ago actually it's not that long ago and we started building uh we started building standards to avoid These things and to outsource hosting our users at different user identifying systems So in 2005, for example, the OpenID standard started to be established and implemented, and then in 2007 came the OAuth 1 protocol, and then later on came the OAuth 2 protocol. And uh today I would like to talk to you about uh how essentially we built the OS2 protocol and and reused it using tools provided to Django and Python.

uh at my company. So let's start off. Chapter one. Knowledge is an onion. It appeals to us to peel layers upon layers, reels and reels. So Two days ago uh Revo he mentioned that uh that the OAS protocol uh the OAS two protocol in itself is quite complicated and we're not really going he was not really going into details. The good news is I'm giving it all to you right now. So what is the OAuth2 protocol? A little bit of fun history first. Uh it all started at Twitter actually. So One day uh external Twitter users wanted to get access to their data in the Twitter systems, and engineers at Twitter decided to implement this using the OpenID Connect.

Protocol. But the thing is that OpenID Connect does not give you access to resources in the in the in the system. It only gives you login permissions. So that's clearly not enough. And that was the point when in 2006, I believe, the project to build the OAuth 1 protocol started, and then later on it evolved to the OAuth 2 protocol. There are not a lot of differences between them. The biggest one is that the OAS 2 protocol was designed to support multiple types of clients and multiple types of ways to get information from these systems. So there are a couple of grants here. A grant is basically what type of client can get in can get access to the external system.

So implicit grant basically means that you have a very thin client, like a uh single-page web application, but you still need access to a user's Google data, for example, like their email address or first name and last name and and basically this is the least secure of the protocols. There's the resource owner gra credentials one. This one you know very well is the username password. So that's how it's easy to remember it. There's the client credentials, Javon mentioned this as well. And uh the thing is that this this one is probably the easiest to understand. There's a key on the server and the client side, only two of them know about this, and then they exchange it and make sure, and this way you can get information information from the external system.

And what's really interesting for us is the authorization code grant. And this is what we are going to dive deep into. If you want to learn about the other ones, there's going to be a link and I'm going also going to share my slides after the talk. So the authorization code grant, it basically uh supports uh it basically has four uh four people who are taking part in this or machines. The first one is the resource owner. That's me. That's you. It's the actual person who has who has the information. You know your name, you know your email address. You know who should have access to this data. There is the client.

The client is the application you are going to use to connect, and you are going to give access to your information. There's going to be an authentication server which is going to allow us to access this information actually and to verify that you can actually have this data. And then we have the resource server, which actually you have uploaded your data previously, like your first name, last name, email address, and then afterwards you want the client applications to have access to it. The entire flow starts by having a request to access this data. It's quite simple actually. Basically you click a login button on a website. There are a couple of things that are being sent here.

For example, the client ID, this describes who would like to get this information The response type, that's code, this describes basically that, hey, I want to get the information and access in this format. And the redirect URI, where should the external system call back if the authorization has happened The next part is the coolest one and the most important one. This is when you get a nice consent screen that you know the external client application would like to get access to your data. And uh it w it's really important to stop here for a second and talk about this a little bit. So all of us heard that uh recently there were issues with uh Facebook Oalls and you know personal data being leaked by third parties and stuff like this

Uh if you want to stop people from uh accessing from third-party clients giving out the data that you host about your users This is the place where you can stop them. Because if the user does not understand what's going to happen if they click continue here. Then everything is messed up, right? So uh if the user gives access to their information, well it's really difficult to do anything afterwards that Um yes, so let's assume that I have given consent to uh for Prezi to access my information from Facebook. And after this the authorization server is going to send back a code. Alright, I have generated this code with a with a

the special secret that we share with each other. And then please send me the validation that it's actually you. So there's going to be an exchange at this point and there's an authorization that's going to happen. There are two key parts of this authorization. The first one is the auth code that was sent just before, and the second one is the client secret that's that's on the client and uh and also the server deauthorization server knows about it as well So the authorization happens. We get back two tokens. The first one is the access token and the second one is the refresh token. The access token is a shortlift token. That's what that's what you use for communication with the external service. And the refresh token

you use to refresh the access token. So after this, you can get all the information you want until the refresh token expires, and after that you only need to log the user in again. Whoo! That was crazy. Alright. You did great. Here's a polar bear. Alright. So uh the flow is quite complex, but in a sense what it does is it makes sure it it basically this protocol ensures that When a user wants to give access to their data, they want a third-party application to get access to their data, then it's 100%

sure that they have to consent to it And I think this is super important to understand, and this is why the OALS 2 protocol is great in ways. Maybe not so great in other ways. All right. Um let's shift on. And I would like to talk to you about a legacy application that is 11 years old. Names and places times time 's gone fast, twisting like an hourglass. Alright. So as I mentioned There's a legacy application that we call Prezi, the Prezi backend to be very specific, and it's 11 years old. Uh it's a Django application, and uh it's humongous, let's just say that, at least it was.

And uh you have to understand that an 11-year-old application being brings a lot of lot of things with it throughout the years. Uh for example we have custom authentication implemented in our systems. We have custom session handling. Uh everything that session uh so basically Server-side sessions were not maintainable for us because we had too much traffic, which is you know a great problem to have, but still we had to find different solutions to make it make our website faster. And of course I bet most of you just like us we have custom user objects, we have overridden the user model in the in the auth package uh and We have added multiple other models to it that actually describe what a prezi

user looks like. And It's quite safe to say at this point that we are kind of, you know, unicorns in this, but I bet that a lot of you feel the same way about your own code base here. So, you know, some time ago um a request came in from product that we need to enable more people to sign up to Prezi. com. And uh And you know, the the solution, the obvious solution is always social authentication in this case. So back in the day there was a fantastic package called Django Social Auth uh that was maintained by Omab. Uh his name is Mathias, he's from Uruguay, he's a great guy. And uh basically at that point we already had like super custom stuff implemented.

So the Zang Django social art package Did not cut for us entirely. So what is the sensible thing to do? Yes, we did a gigantic fork. Wow. What's gonna go wrong, right? Let me remind you that this fork happened in 2011 At least that's the latest trace I could find about it because before 2011 we were not on GitHub but a different uh service that hosted our code. So it probably happened way before 2011. Let me give you another reminder. It's 2018 now. Alright, so uh quite a few years have passed.

Um So this code base started rotting and rotting and rotting and we started adding more stuff to it. We started patching it. We started manually maintaining everything basically from the Facebook backend to the LinkedIn backend to whatever login you can imagine. And then in 2017 came our favorite project, the classic one -button project, right? We all had these projects, you just need to put out one button, it's super easy, right? Well, luckily we had time to work on it So let's go to the next chapter. Fly dark despondency away, parent of frenzy and despair.

Go seek the lurid haunts of care, nor hear thy haggard form display. I think Mary Robinson's beautiful poem described perfectly how t how happy my team was to burn the old system to the ground. So uh so basically uh what we did is uh is uh we started research. We don't want to maintain an authentication system excessively. We want a beautiful shell that's going to cover everything for us. that's going to deal with everything. We don't want to write custom code. We just want it to work, right? And then doing these research times

We encountered the social core package. The avocado is only there because I love avocados. I'm I'm super millennial. It's fine. Um so we discovered the social core package. And the social core package, what it In essence, what it does is uh it provides social authentication that's framework independent. And this is exactly what we needed. This is exactly what uh what Prezi needed at this point because we had so much custom code that we didn't want to fork uh another Django social authentication package again. We wanted to write a little bit of code around source uh so the core part of social authentication and then uh and then you know Just maintain that part and the rest is going to just work.

So the social core I want to explain to you what are the parts of it in very high level and it's got three main parts The first one is the back ends. The second one are the pipelines. And the third one are the strategies Backends are really simple. This is most likely the easiest to understand. The idea behind the backends is what is the external provider that I want to get my information from? What data do I want from this external information provider to give me? And a couple of other functionalities. So let's run a couple some examples. The first one is the Google one. This is a quite this is quite standard.

Everybody has nowadays a Google login button on their website, even Prezi. And uh you can see here that uh you know it's got uh the URL where I can fetch the access token from It's got uh where I can revoke uh the access tokens, it's got what scope I can I can get from these tokens. And you know this uh the Facebook one is awfully similar to this. So why not have a system for this? And this is exactly what Matias was thinking when he was designing uh the social authentication systems. So um I want to highlight one small thing though that comes from the OAuth2 protocol. Please uh please check what the revoke token

method is for the Facebook one. It's a delete, right? For Google it's a get. So this shows that the OAuth two protocol is not too strict on what exactly uh it sh uh the implementation should look like, it only gives us this framework of consent from the user. And I just want to throw in one more that blew my mind when I was scrolling through the backends. This is the Battle. net uh OALS. So basically you can sign you could sign up to Prezi. com, let's say with your Betonet account if we enable the button there on the front end, which is you know I find super ridiculous and that you can inv import your World of Warcraft characters into your Prezies. I don't know, I just came up with this.

But Yeah, so I think if uh if I remember correctly there are around 170 supported backends in social core. So if you want to log in your users using any type of backend, I'm fairly certain you're gonna find it. Alright, pipelines, this is my favorite part. Yeah, we already went through this, so we're not going to go through it again. Basically the idea of pipelines is that during the authentication flow you can run custom code. You can run whatever code you want to write. And essentially this can this has a lot of implications and it's super powerful. It you can, for example, do custom login, sign-up uh flows. you can do logging if you want like so we put the audit logging for our security team in these in this part of the code.

You can also send out marketing emails if you really like. Hey, and we know just noticed that you sign up. Wanna try out these cool things? For example, we integrated Google in this way, blah, blah, blah. Very, very cool. I would like to focus a little bit on the on the signing up part though. So Uh we separate three real cases when their social sign in or sign up. First one is logging the user in. The second one is signing the user up. And the third one is association. And I'm going to explain what these are. Logging in is Basically the case when the user exists in your system and they exist in the external system as well. You want the login to be as smooth as possible. It should be one click and that's it.

The user is already in your system. and you're done. Signing up. So when you go on your mobile phone and you download an application and there's a and there's a button that says login with Google, then uh you tap it. And if you don't have an account in the system, you should still be able to log in immediately, right? So in the social authentication pipeline, we just simply added uh a user creation step and then immediately we did not need to care about you know the user being uh not logged in. And then the association, and this is probably the most interesting part of all of it. It's when the user somehow already exists in your system.

And essentially what you want to achieve here is that when they click the button, but oh sorry, so they exist in your system, but the two accounts are not connected with the external system yet. So somehow you have to verify that these are the two same people and connect the two accounts. And I'm going to show a quick demo of how we solved for this problem in a moment. Uh touching on strategies just for a couple of words. Strategies are the things that take care of the request, the response objects, how rendering happens in the framework. uh how uh sessions are handled and how settings are accessed in this framework. Now the good news is that this sounds super overwhelming. But if you just go to the Python social

out github handle uh everything from this is done for Django. So if you are had don't are not running super custom code like we do You can just pip install uh social app Django, put like three configurations in your in your config files, and you are already good to go with your social login system. It's insanely powerful. Alright. I want to talk a little bit about uh roadblocks and achievements that we have bumped into on the way. I searched so high, I searched so low, and wiped the cool sweat off my bro in quest of someone who would be just themselves in front of me. So uh we're going to touch two things here, uh what type of issues we had with the databases

and uh And the native clients, the mobile applications, and the desktops that that we have implemented. It was quite unfortunate that we wanted to do the social authentication system migration during the time when we were moving from pure iron to the cloud with our massive infrastructure. So we ran into a couple of issues here and we had to run a couple of you know complicated database queries and uh and set up uh set up a connection between between uh RDS and uh I mean the Amazon Web Services and physical servers. We had to set up complex replications But uh in the end it was a huge learning

and now at least we can do it, right? So if it comes up again then it's cool. It was really good that we moved to the cloud by the way, because uh after the release a couple of weeks later uh when we stopped the A-B test for the Google login, then uh then we had uh we had a had an outage because our database servers got overloaded and All I had to do was select a bigger database size from a drop-down on the Amazon console and two minutes later the outage was over. So that was cool. All right, let's talk a bit about the mobile clients. Did you guys so uh after the release we started getting uh We started getting notices from Apple

actually that uh our login and sign up flow is too good because apparently when you are working uh working with uh Apple uh with iOS applications You cannot sign up users unless your application is paying and you are paying some money to Apple. So our application is free. So uh we decided to just disable Google uh user sign -up uh on uh from iOS devices. But you know using the power of pipelines it only took like two hours of work to do, uh deployment included. Also, did you know that you can sign up to Facebook using only your mobile phone, your phone number We did not know this, but luckily our new monitoring system immediately alerted us that there are a lot of users who are coming in without a valid email address.

And we were like, what the hell? And then you know we read uh the Facebook user manual or whatever that is, and then you you know we found out that, oh, you could actually just sign up using your phone number. So we could not come up with a very elegant solution, but still we built a quick view for this and we notified the users that, hey, we noticed that you don't have an email address set up with your account. Uh you uh we saw that you were trying to use Facebook. You can go to this website and learn how you can add an email address to your Facebook account. Super nice, right? So some users were able to find their way back to our website this way and that's super useful. All right. Um a couple of achievements that I want to talk about uh regarding this project. You know, apart from having a super

scalable social authentication system now which scales horizontally and vertically as well. I showed it the other way. It's fine. No, I showed it right. It's cool. So uh which scales horizontally and vertically as well I'm also really proud of the uh of the association flow. So here I'm going to tap sign in with the Google. And uh I tap my email address and now what the application is gonna tell me, it's a bit slow because in my hotel the internet was not that good. uh that you know I received an email, I go uh I tap the button, it opens my email client, I open the email. itself. It tells me all sorts of stuff like you know where the login happened and stuff like this. I click verify my account

and with the power of deep linking We were able to open back the application. And this basically means that you know we keep the user in one flow, they don't have to think about anything, and everything just works. So yeah, make sure to look at your tool set when you are building your association flow because you can do really really cool stuff with today's technologies. The other really cool thing is that uh you know we were so happy about this package that we decided to contribute back and uh and practically uh we fixed bugs, security concerns, we improved on the pipeline system, and uh it was really great uh collaborating with Matias.

Cool. To wrap this up, if there are two things that you take away today, these should be the two GitHub uh handles that you check out. If you did not have time to take a screenshot, I'm going to send out this link in roughly three minutes to the talks channel. This is basically this presentation. You can click through it and find all the links in there This is my face in my natural habitat next to a glass of wine. Yeah, you can find me on social media, GitHub, you can And send me an email at akosh at preszi. com if you have any questions that I cannot answer here or uh offstage. And yeah, that was an O to OAuth. Thank you so much.