An ODe to OAuth
Hochrein, Akos
We all know that remembering passwords is hard, so why not leave it to someone else? In this talk, I would like to introduce how we improved our social authentication system in our Django applications at Prezi with the aid of the Python Social Auth package. After a long time coming, we at Prezi introduced social authentication using Google mid last year. This seemingly trivial problem soon became a nightmare after we realized that our custom built session management systems completely misalign with the standards of the industry and open source. However, our team did not give up the dream of having a fully scalable and easy-to-maintain component that we can be proud of. In this talk, I would like to present you the war story of how we revamped the social authentication systems at Prezi (whilst becoming open source contributors) using the Python Social Auth package, enabling a significant amount of users to access our services on all platforms.
 You can hear me. You can see me. Hello. How you doing? We almost ran the marathon. And yeah, my name is Akash Harkrine. I work at a company called Prezi. It's an online presentation tool. We live in the cloud. 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 going to 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. All right. 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. 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 30 years ago or 40 whenever the internet and security started. And you know, we are still living with it. I did some research. And you know, I found like two dozen articles of what the greatest password managers and tools to help us remember things and generate new passwords and only remember a master password and stuff like this. And then you remember your master password and another master password and it just gets crazy. The good news is that we have realized that this is getting an issue a couple of years ago, actually. It's not that long ago. And 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 today I would like to talk to you about how essentially we built the OAuth 2 protocol and reused it using tools provided to Django and Python 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, Revo mentioned that the OAuth 2 protocol in itself is quite complicated and he was not really going into details. The good news is I'm giving it all to you right now. So what is the OAuth 2 protocol? A little bit of fun history first. It all started at Twitter, actually. So one day, 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 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 OAuth 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 access to the external system. So implicit grant basically means that you have a very thin client, like a 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 basically, this is the least secure of the protocols. There's a resource owner 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. They will mention this as well. And the thing is that 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 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 also going to share my slides after the talk. So the authorization code grant, it basically supports, it basically has 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 the information. You know your name. You know your email address, 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 it's really important to stop here for a second and talk about this a little bit. So all of us heard that recently there were issues with Facebook walls and you know, personal data being leaked by third parties and stuff like this. If you want to stop people from 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 if the user gives access to their information, well, it's really difficult to do anything afterwards that. Yes. So let's assume that I have given consent to for Prezi to access my information from Facebook and after this, the authorization server is going to send back a code. All right. I have generated this code with 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 on the client. And also the server, the authorization 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 short lift token. 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 lock the user in again. Whoo! That was crazy. All right. You did great. Here's a polar bear. All right. So the flow is quite complex. But in a sense, what it does is it makes sure it basically, this protocol ensures that when a user wants to give access to their data, they want the 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 OLS 2 protocol is great in ways. Maybe not so great in other ways. All right. 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 gone fast, twisting like an hourglass. All right. So as I mentioned, there's a legacy application that we call Prezi. The Prezi back end to be very specific. And it's 11 years old. It's a Django application. And it's humongous. Let's just say that. At least it was. And you have to understand that an 11-year-old application brings a lot of things with it throughout the years. For example, we have custom authentication implemented in our systems. We have custom session handling. Everything that session, so basically server-side sessions were not maintainable for us because we had too much traffic, which is a great problem to have. But still, we had to find different solutions to 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 auth package. And we have added multiple other models to it that actually describe what a Prezi user looks like. And it's quite search to say at this point that we are kind of 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, a request came in from product that we need to enable more people to sign up to Prezi.com. And, you know, 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 that was maintained by OMab. His name is Matias, he's from Uruguay, he's a great guy. And basically, at that point, we already had, like, super custom stuff implemented. So the Django social auth package did not cut for us entirely. So what is the sensible thing to do? Yes, we did a gigantic fork. Wow. Ooh. What's going to 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 service that's hosted our code. So it probably happened way before 2011. Let me give you another reminder. It's 2018 now. All right. So quite a few years have passed. So this code base started rotting. And we started adding more stuff to it. We started patching it. We started manually maintaining everything basically from the Facebook backend, 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 happy my team was to burn the old system to the ground. So basically, what we did is 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, during these research times, we encountered the social core package. The avocado is only there because I love avocados. I'm super millennial. It's fine. So we discovered the social core package. And the social core package, in essence, what it does is it provides social authentication that's framework independent. And this is exactly what we needed. This is exactly what Prezi needed at this point because we had so much custom code that we didn't want to fork another Django social authentication package again. We wanted to write a little bit of code around the core part of social authentication 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. Back ends are really simple. This is most likely the easiest to understand. The idea behind the back ends 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 some examples. The first one is the Google one. This is quite standard. Everybody has nowadays a Google login button on their website, even Prezi. And you can see here that, you know, it's got the URL where I can fetch the access token from. It's got where I can revoke the access tokens. It's got what scope I can get from these tokens. And you know, the Facebook one is awfully similar to this. So why not have a system for this? And this is exactly what Matthias was thinking when he was designing the social authentication systems. So I want to highlight one small thing, though, that comes from the OOS 2 protocol. 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 OOS 2 protocol is not too strict on what exactly 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 back ends. This is the Battle.net OOS. So basically you could sign up to Prezi.com. And save with your Battle.net account if we enable the button there on the front end, which is, you know, I find super ridiculous and that you can import your World of Warcraft characters into your Prezi. I don't know. I just came up with this. But yeah, so I think if I remember correctly, there are around 170 supported back ends in social core. So if you want to log in, you are users using any type of back end. I'm fairly certain you're going to find it. All right, 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 has a lot of implications and is super powerful. You can, for example, do custom login, sign up flows. You can do logging if you want. So we put the audit logging for our security team in this part of the code. You can also send that marketing email if you're really like, hey, we just noticed that you signed up. Want to 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 signing up part, though. So 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 button that says login with Google, then 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 a user creation step and then immediately we did not need to care about, you know, the user being 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, 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. Touching on strategies just for a couple of words. Stategies are the things that take care of the request, the response objects, how rendering happens in the framework, how 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, everything from this is done for Django. So if you are not running super custom code like we do, you can just pip install social app Django, put like three configurations in your config files, and you are already good to go with your social login system. It's insanely powerful. All right. I want to talk a little bit about roadblocks and achievements that we have bumped into on the way. I searched so high, I searched so low, and wiped the cool sweat of my bro in quest of someone who would be just themselves in front of me. So we're going to touch two things here. What type of issues we had with the databases and the native clients, the mobile applications, and the desktops 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 complicated database queries and set up a connection between RDS and, I mean, the Amazon web services and physical servers. We had to set up complex applications, but 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 after the release a couple of weeks later when we stopped the A-B test for the Google login, then we 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 after the release we started getting notices from Apple, actually, that our login and sign up flow is too good, because apparently when you are working with Apple, every DOS application, you cannot sign up users unless your application is paying and you are paying some money to Apple. So our application is free, so we decided to just disable Google user sign up from iOS devices, but using the power of pipelines, it only took like two hours of work to do, 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 a new monitoring system immediately alerted us. There are a lot of users who are coming in without a valid email address, and we were like, what the hell? And then we read the Facebook user manual or whatever that is, and then we found out that, oh, you can 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. 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. A couple of achievements that I want to talk about regarding this project, apart from having a super scalable social authentication system now with scales horizontally and vertically as well. I showed it the other way. No, I showed it right. Let's go. So with scales horizontally and vertically as well, I'm also really proud of the association flow. So here I'm going to tap sign in with the Google, and I tapped my email address, and now what the application is going to tell me, it's a bit slow because in my hotel the internet was not that good, that I received an email. I tapped the button. It opens my email client. I opened the email itself. It tells me all sorts of stuff, like 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 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 we were so happy about this package that we decided to contribute back, and practically we fixed bugs, security concerns, we improved on the pipeline system, and it was really great collaborating with Matthias. Cool. To wrap this up, if there are two things that you take away today, these should be the two GitHub 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 send me an email at akosch at presi.com if you have any questions that I cannot answer here or offstage. And yeah, that was an all to all off. Thank you so much.
 You can hear me. You can see me. Hello. How you doing? We almost ran the marathon. And  yeah, my name is Akash Harkrine. I work at a company called Prezi. It's an online presentation  tool. We live in the cloud. 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 going to 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. All right.  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. 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  30 years ago or 40 whenever the internet and security started. And you know, we are still  living with it. I did some research. And you know, I found like two dozen articles of what  the greatest password managers and tools to help us remember things and generate new passwords  and only remember a master password and stuff like this. And then you remember your master  password and another master password and it just gets crazy. The good news is that we  have realized that this is getting an issue a couple of years ago, actually. It's not  that long ago. And 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 today I would like to talk to you about  how essentially we built the OAuth 2 protocol and reused it using tools provided to Django  and Python 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, Revo mentioned that  the OAuth 2 protocol in itself is quite complicated and he was not really going into details.  The good news is I'm giving it all to you right now. So what is the OAuth 2 protocol?  A little bit of fun history first. It all started at Twitter, actually. So one day,  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 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 OAuth 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 access to the external system. So implicit  grant basically means that you have a very thin client, like a 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 basically, this is the least secure of the protocols.  There's a resource owner 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. They will  mention this as well. And the thing is that 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 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 also going to share my slides after the talk.  So the authorization code grant, it basically supports, it basically has 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 the information. You know your name. You know your email address,  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 it's really important to stop here for a second and talk about this  a little bit. So all of us heard that recently there were issues with Facebook walls and  you know, personal data being leaked by third parties and stuff like this. If you want to  stop people from 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 if the user gives access to their information, well, it's really  difficult to do anything afterwards that. Yes. So let's assume that I have given consent  to for Prezi to access my information from Facebook and after this, the authorization  server is going to send back a code. All right. I have generated this code with 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  on the client. And also the server, the authorization 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 short lift token. 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 lock the user in again. Whoo! That was crazy. All  right. You did great. Here's a polar bear. All right. So the flow is quite complex. But  in a sense, what it does is it makes sure it basically, this protocol ensures that when  a user wants to give access to their data, they want the 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 OLS 2 protocol is great in  ways. Maybe not so great in other ways. All right. 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 gone  fast, twisting like an hourglass. All right. So as I mentioned, there's a legacy application  that we call Prezi. The Prezi back end to be very specific. And it's 11 years old. It's  a Django application. And it's humongous. Let's just say that. At least it was. And you have  to understand that an 11-year-old application brings a lot of things with it throughout  the years. For example, we have custom authentication implemented in our systems. We have custom  session handling. Everything that session, so basically server-side sessions were not  maintainable for us because we had too much traffic, which is a great problem to have.  But still, we had to find different solutions to 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 auth package. And we have added multiple other models to it that actually  describe what a Prezi user looks like. And it's quite search to say at this point that  we are kind of 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, a request came in from product that  we need to enable more people to sign up to Prezi.com. And, you know, 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 that was maintained by OMab. His name is Matias,  he's from Uruguay, he's a great guy. And basically, at that point, we already had, like, super  custom stuff implemented. So the Django social auth package did not cut for us entirely.  So what is the sensible thing to do? Yes, we did a gigantic fork. Wow. Ooh. What's going  to 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 service that's hosted our code. So it probably happened way before 2011. Let  me give you another reminder. It's 2018 now. All right. So quite a few years have passed.  So this code base started rotting. And we started adding more stuff to it. We started  patching it. We started manually maintaining everything basically from the Facebook backend,  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 happy my team was to burn the old system to the  ground. So basically, what we did is 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, during these research times, we encountered the social core package. The  avocado is only there because I love avocados. I'm super millennial. It's fine. So we discovered  the social core package. And the social core package, in essence, what it does is it provides  social authentication that's framework independent. And this is exactly what we needed. This is  exactly what Prezi needed at this point because we had so much custom code that we didn't want  to fork another Django social authentication package again. We wanted to write a little  bit of code around the core part of social authentication 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. Back  ends are really simple. This is most likely the easiest to understand. The idea behind  the back ends 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 some examples. The first one is the Google one. This is quite  standard. Everybody has nowadays a Google login button on their website, even Prezi. And you  can see here that, you know, it's got the URL where I can fetch the access token from.  It's got where I can revoke the access tokens. It's got what scope I can get from these tokens.  And you know, the Facebook one is awfully similar to this. So why not have a system for this?  And this is exactly what Matthias was thinking when he was designing the social authentication  systems. So I want to highlight one small thing, though, that comes from the OOS 2 protocol.  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 OOS 2 protocol is not too strict on what  exactly 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 back ends. This is the Battle.net OOS. So basically you could sign up to Prezi.com.  And save with your Battle.net account if we enable the button there on the front end,  which is, you know, I find super ridiculous and that you can import your World of Warcraft  characters into your Prezi. I don't know. I just came up with this. But yeah, so I think  if I remember correctly, there are around 170 supported back ends in social core. So if you  want to log in, you are users using any type of back end. I'm fairly certain you're going  to find it. All right, 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 has a lot of implications and is super powerful. You  can, for example, do custom login, sign up flows. You can do logging if you want. So  we put the audit logging for our security team in this part of the code. You can also send  that marketing email if you're really like, hey, we just noticed that you signed up. Want  to 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 signing up part, though.  So 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 button that says login with Google, then 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 a user creation step  and then immediately we did not need to care about, you know, the user being 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, 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. Touching  on strategies just for a couple of words. Stategies are the things that take care of  the request, the response objects, how rendering happens in the framework, how 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,  everything from this is done for Django. So if you are not running super custom code like  we do, you can just pip install social app Django, put like three configurations in your  config files, and you are already good to go with your social login system. It's insanely  powerful. All right. I want to talk a little bit about roadblocks and achievements that  we have bumped into on the way. I searched so high, I searched so low, and wiped the  cool sweat of my bro in quest of someone who would be just themselves in front of me. So  we're going to touch two things here. What type of issues we had with the databases and  the native clients, the mobile applications, and the desktops 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 complicated database  queries and set up a connection between RDS and, I mean, the Amazon web services and physical  servers. We had to set up complex applications, but 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 after the release a couple of weeks  later when we stopped the A-B test for the Google login, then we 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  after the release we started getting notices from Apple, actually, that our login and sign  up flow is too good, because apparently when you are working with Apple, every DOS application,  you cannot sign up users unless your application is paying and you are paying some money to  Apple. So our application is free, so we decided to just disable Google user sign up from  iOS devices, but using the power of pipelines, it only took like two hours of work to do,  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 a new monitoring system  immediately alerted us. There are a lot of users who are coming in without a valid email  address, and we were like, what the hell? And then we read the Facebook user manual or whatever  that is, and then we found out that, oh, you can 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. 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. A couple of achievements that I want to talk about regarding  this project, apart from having a super scalable social authentication system now with scales  horizontally and vertically as well. I showed it the other way. No, I showed it right. Let's  go. So with scales horizontally and vertically as well, I'm also really proud of the association  flow. So here I'm going to tap sign in with the Google, and I tapped my email address,  and now what the application is going to tell me, it's a bit slow because in my hotel the  internet was not that good, that I received an email. I tapped the button. It opens my  email client. I opened the email itself. It tells me all sorts of stuff, like 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 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 we were so happy about this package that we decided to contribute  back, and practically we fixed bugs, security concerns, we improved on the pipeline system,  and it was really great collaborating with Matthias. Cool. To wrap this up, if there  are two things that you take away today, these should be the two GitHub 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  send me an email at akosch at presi.com if you have any questions that I cannot answer  here or offstage. And yeah, that was an all to all off. Thank you so much.
DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__0_1223.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__1224_1319.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__1320_1607.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__1608_1715.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__1716_7127.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__7128_7235.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__7236_8087.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__8088_10115.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__10116_10163.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__10164_10235.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__10236_11279.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__11280_13319.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__13320_13787.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__13788_14471.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__14472_15431.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__15432_16895.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__16896_17159.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__17160_20111.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__20112_20195.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__20196_20291.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__20292_20339.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__20340_21467.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__21468_21779.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__21780_27335.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__27336_29339.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__29340_33383.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__33384_33539.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__33540_41147.png DjangoCon_2018_-_An_ODe_to_OAuth__1080p_25fps_H264-128kbit_AAC__41148_41222.png
You can hear me. You can see me. Hello. How you doing? We almost ran the marathon. And yeah, my name is Akash Harkrine. I work at a company called Prezi. It's an online presentation tool. We live in the cloud. 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 going to 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. All right. 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. 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 30 years ago or 40 whenever the internet and security started. And you know, we are still living with it. I did some research. And you know, I found like two dozen articles of what the greatest password managers and tools to help us remember things and generate new passwords and only remember a master password and stuff like this. And then you remember your master password and another master password and it just gets crazy. The good news is that we have realized that this is getting an issue a couple of years ago, actually. It's not that long ago. And 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 today I would like to talk to you about how essentially we built the OAuth 2 protocol and reused it using tools provided to Django and Python 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, Revo mentioned that the OAuth 2 protocol in itself is quite complicated and he was not really going into details. The good news is I'm giving it all to you right now. So what is the OAuth 2 protocol? A little bit of fun history first. It all started at Twitter, actually. So one day, 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 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 OAuth 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 access to the external system. So implicit grant basically means that you have a very thin client, like a 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 basically, this is the least secure of the protocols. There's a resource owner 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. They will mention this as well. And the thing is that 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 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 also going to share my slides after the talk. So the authorization code grant, it basically supports, it basically has 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 the information. You know your name. You know your email address, 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 it's really important to stop here for a second and talk about this a little bit. So all of us heard that recently there were issues with Facebook walls and you know, personal data being leaked by third parties and stuff like this. If you want to stop people from 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 if the user gives access to their information, well, it's really difficult to do anything afterwards that. Yes. So let's assume that I have given consent to for Prezi to access my information from Facebook and after this, the authorization server is going to send back a code. All right. I have generated this code with 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 on the client. And also the server, the authorization 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 short lift token. 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 lock the user in again. Whoo! That was crazy. All right. You did great. Here's a polar bear. All right. So the flow is quite complex. But in a sense, what it does is it makes sure it basically, this protocol ensures that when a user wants to give access to their data, they want the 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 OLS 2 protocol is great in ways. Maybe not so great in other ways. All right. 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 gone fast, twisting like an hourglass. All right. So as I mentioned, there's a legacy application that we call Prezi. The Prezi back end to be very specific. And it's 11 years old. It's a Django application. And it's humongous. Let's just say that. At least it was. And you have to understand that an 11-year-old application brings a lot of things with it throughout the years. For example, we have custom authentication implemented in our systems. We have custom session handling. Everything that session, so basically server-side sessions were not maintainable for us because we had too much traffic, which is a great problem to have. But still, we had to find different solutions to 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 auth package. And we have added multiple other models to it that actually describe what a Prezi user looks like. And it's quite search to say at this point that we are kind of 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, a request came in from product that we need to enable more people to sign up to Prezi.com. And, you know, 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 that was maintained by OMab. His name is Matias, he's from Uruguay, he's a great guy. And basically, at that point, we already had, like, super custom stuff implemented. So the Django social auth package did not cut for us entirely. So what is the sensible thing to do? Yes, we did a gigantic fork. Wow. Ooh. What's going to 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 service that's hosted our code. So it probably happened way before 2011. Let me give you another reminder. It's 2018 now. All right. So quite a few years have passed. So this code base started rotting. And we started adding more stuff to it. We started patching it. We started manually maintaining everything basically from the Facebook backend, 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 happy my team was to burn the old system to the ground. So basically, what we did is 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, during these research times, we encountered the social core package. The avocado is only there because I love avocados. I'm super millennial. It's fine. So we discovered the social core package. And the social core package, in essence, what it does is it provides social authentication that's framework independent. And this is exactly what we needed. This is exactly what Prezi needed at this point because we had so much custom code that we didn't want to fork another Django social authentication package again. We wanted to write a little bit of code around the core part of social authentication 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. Back ends are really simple. This is most likely the easiest to understand. The idea behind the back ends 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 some examples. The first one is the Google one. This is quite standard. Everybody has nowadays a Google login button on their website, even Prezi. And you can see here that, you know, it's got the URL where I can fetch the access token from. It's got where I can revoke the access tokens. It's got what scope I can get from these tokens. And you know, the Facebook one is awfully similar to this. So why not have a system for this? And this is exactly what Matthias was thinking when he was designing the social authentication systems. So I want to highlight one small thing, though, that comes from the OOS 2 protocol. 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 OOS 2 protocol is not too strict on what exactly 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 back ends. This is the Battle.net OOS. So basically you could sign up to Prezi.com. And save with your Battle.net account if we enable the button there on the front end, which is, you know, I find super ridiculous and that you can import your World of Warcraft characters into your Prezi. I don't know. I just came up with this. But yeah, so I think if I remember correctly, there are around 170 supported back ends in social core. So if you want to log in, you are users using any type of back end. I'm fairly certain you're going to find it. All right, 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 has a lot of implications and is super powerful. You can, for example, do custom login, sign up flows. You can do logging if you want. So we put the audit logging for our security team in this part of the code. You can also send that marketing email if you're really like, hey, we just noticed that you signed up. Want to 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 signing up part, though. So 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 button that says login with Google, then 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 a user creation step and then immediately we did not need to care about, you know, the user being 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, 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. Touching on strategies just for a couple of words. Stategies are the things that take care of the request, the response objects, how rendering happens in the framework, how 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, everything from this is done for Django. So if you are not running super custom code like we do, you can just pip install social app Django, put like three configurations in your config files, and you are already good to go with your social login system. It's insanely powerful. All right. I want to talk a little bit about roadblocks and achievements that we have bumped into on the way. I searched so high, I searched so low, and wiped the cool sweat of my bro in quest of someone who would be just themselves in front of me. So we're going to touch two things here. What type of issues we had with the databases and the native clients, the mobile applications, and the desktops 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 complicated database queries and set up a connection between RDS and, I mean, the Amazon web services and physical servers. We had to set up complex applications, but 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 after the release a couple of weeks later when we stopped the A-B test for the Google login, then we 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 after the release we started getting notices from Apple, actually, that our login and sign up flow is too good, because apparently when you are working with Apple, every DOS application, you cannot sign up users unless your application is paying and you are paying some money to Apple. So our application is free, so we decided to just disable Google user sign up from iOS devices, but using the power of pipelines, it only took like two hours of work to do, 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 a new monitoring system immediately alerted us. There are a lot of users who are coming in without a valid email address, and we were like, what the hell? And then we read the Facebook user manual or whatever that is, and then we found out that, oh, you can 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. 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. A couple of achievements that I want to talk about regarding this project, apart from having a super scalable social authentication system now with scales horizontally and vertically as well. I showed it the other way. No, I showed it right. Let's go. So with scales horizontally and vertically as well, I'm also really proud of the association flow. So here I'm going to tap sign in with the Google, and I tapped my email address, and now what the application is going to tell me, it's a bit slow because in my hotel the internet was not that good, that I received an email. I tapped the button. It opens my email client. I opened the email itself. It tells me all sorts of stuff, like 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 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 we were so happy about this package that we decided to contribute back, and practically we fixed bugs, security concerns, we improved on the pipeline system, and it was really great collaborating with Matthias. Cool. To wrap this up, if there are two things that you take away today, these should be the two GitHub 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 send me an email at akosch at presi.com if you have any questions that I cannot answer here or offstage. And yeah, that was an all to all off. Thank you so much.
good at yet? It's remembering passwords. How many The good news is that we have realized that this protocol. And today I would like to talk to you Connect does not give you access to resources in user's Google data, for example, like their email the client applications to have access to it. The that I have given consent to for Prezi to access the access token. So after this, you can get all we have custom authentication implemented in our systems. We have custom session handling. implemented. So the Django social auth package awfully similar to this. So why not have a system how we solved for this problem in a moment. huge learning, and now at least we can do it, phone, your phone number? We did not know this, sign up using your phone number. So we could not this project, apart from having a super scalable social authentication system now with scales well, I'm also really proud of the association fixed bugs, security concerns, we improved on the