 And today, we are going to discuss the importance of OAuth2 in a current web scenario and how I implemented OAuth2 standards in Drupal as a part of my Google Summer of Code project last year in 2017. So a little about me. I am currently a 19-year-old student studying computer science engineering from RTU. It stands for Rajasthan Technical University in India. I've been coding since the age of 10. I love to play all the record sports like Scorch, Badminton, and like Ping-Pong, which is popular in north-south eastern countries. And I've been involved with open source for the last five years. So when I was 12, I created a plugin for WordPress as a part of my personal project. I was not able to find a particular functionality in WordPress, then I created it and open sourced it. And currently, I'm running my own startup called Roots, which converts underutilized spaces into and turning them into co-working spaces, so like creating neighborhood co-working spaces in India. So before 2007, whenever you have to give an access of your account to an app, you have to simply enter your password and email, which is like really scary because you are actually giving away your identity to them. So we were always told in our childhood to never share our identity with any stranger, but we are doing the same in the case of apps. We are giving our apps our SS2R accounts, which is not good, totally not good. Before OVOT was, you were giving away apps to your password, apps were getting complete access to your account, and you can't disable the app to use your account, like you can't evoke the access to your account at any point of time. So also like you can't change what an app can do with your account, like for example in Facebook, there is app can access your friend list, can post on your behalf, but you can't change the permissions which that app can use. Before 2008, there were like no open standards out there for authorization. You have to, there were like some systems created by Google and Facebook, like Facebook used MD5 related to some system, but there was no open like common standards. So if you have to implement your own authorization system, it was a tedious task. It required a lot of planning and execution of things and like then testing it out again and again. Also like even for developers to integrate like these into their website, it was not easy task. You, there was no like common library to create servers or like even implement other authorization in their websites. So it was not at all easy to implement. So why we did OVOT? Before OVOT, there was, okay, so like I'm talking about the next thing, open standard supported. So what OVOT did was, it was an open standard. It is an open standard and supported by major like major companies and organization out there provides limited third party access. So apps don't get full access to your account. You can choose which permissions and which task an app can do on your behalf. It is easily implementable, like anyone with basic coding skills can go out there and implement an OVOT integration into their website. Access to the app or the website is provided only when it has been reviewed by the user. So whenever you go to like a Facebook and click on sign up with Facebook, you see what access, like what type of actions the app can perform on your behalf. So this was it. There are like three major components in OVOT. One is resource owner, other one is resource server and authorization server and last one is client. So client and app are the same thing. Let's assume like app is a Drupal website because I'm from Drupal. First of all, a request is sent from Drupal website, authorization request is sent from Drupal website to the resource like owner. Then if you allow that, like if user allows that app to use their account, in return they get an authorization code, which the website can use the authorization code to get access token in the return. And finally you can use that access token to perform actions. And like these are the three basic major components. So how does it all work? So we'll be discussing about just server side implementation of OVOT. So in get request, we usually define three and four parameters which are client ID or app ID, which is just to identify which app is like using, we'll be getting permission. Redact your like URL, which is after you authorize that app, where will the user be redirected. And state parameters, it is basically to prevent CSRF attacks. So like the same thing, client ID is identification number for the app to be used inside and provided by the social network. So you can't decide it around your own. If you go to Facebook, they will give you an app ID. Redact URL. You have to actually define redirect URL in both your get request and in the app settings page in various social networks. So for example, it is just to validate, the user will be getting redirected to a proper valid URL of your website, not getting like hacked in the middle. So like in Facebook, there is like valid redirect, you can define it there. State. So this is the important part. In the whole authorizing process, sometimes hackers can get involved and get access to your data. So what you want to do is implement a token or string which you can later identify or validate if only user has granted you access. So like in the middle, no hacker can get the access. It is basically to prevent the cross site forging. You must pass and code at the starting and can validate it later. And then store it in this session variable and then validate it later. So also like you have to define scopes which are like list of permissions which you want to get from the user. In case of Facebook, it can be name, your birthday, your friend list, permission to post on your behalf and like various other things like what you read, like your movies, movies your watch, et cetera, et cetera. So like all of us are familiar with this. Whenever you click on that link, you get redirected to Facebook. So Facebook asks if you want to like provide scopes or like various data like your profile information, email address and other things to that app. If you continue, then you are redirected, then the app get authorization code or if you don't authorize that app, then an error is sent to the app. So then authorization code can be used to get the access token in written by the authorization server. It allows an app to perform actions on your behalf. Sometimes there are two types of access token, short-lived access token and long-lived access token. So short-lived access token has to be refreshed again and again by the app. So it has some valid timeframe amount. So for example, an access token in case of Twitter is valid for six months. So you have to again refresh it after some period of time with the help of the refreshed token. Now talking about Drupal, Drupal is content management system which was started at the starting of web like in 2000 by Dries Brutite. It is written in PHP. Earlier it was written in like plain PHP and then we have shifted to we are using symphony as our core. But then like one million members are there. It is used by Tesla, General Electrics and like various top corporations out there. We have been participating in Google Summer of Code from 2005. So like this was, this will be our like 13th edition. Apart from that, like there have been various GSOC alumni, Google Summer of Code alumni who grew from like GSOC student to one of the top positions in Drupal who are like managing all the, managing the code and doing all the code reviews and all. Also sadly, before Trump, White House government was using CMS, but after that they have changed to WordPress. So like one more reason to hit Trump for us. Now talking about social initiative, this was my project. What social initiative does is, it is harmonizing social networking functionality in Drupal. So also like also providing like creating like abstract functionalities of social provider and provide easier integration. More than there are like 20 plus social network out there with us. It is developed basically in two GSOC edition. So like before 2006 and we were nothing. It was just an idea and it was plainly developed in 2016 and 2017. Here by Valentin, there are like three major component of social, social oath, social post and social widgets. What social oath is, it is just related to authorization. Social post does is it automatically post on the hooks like post is created. It automatically create your new status on Facebook or like send us message on Slack defining that you have created a new post. Basic underlying architecture of social API, what it is now was created by Valentin in 2016 and like social oath Twitter, which was like one of the social oath implementers was created by my brother as a part of GCI 2016 and he was elected as grand prize winner after that. In GSOC 2017, what we did was integrated that League O2 library in student initiative project. We factor the authentication process to make it more seamless, more fast and like easily extend across various social networks. Added 20 plus social oath implementers which were included GitHub, Instagram, etc., etc. Added three social post implementers, social post LinkedIn, social post Slack created upset method for social oath and social post implementers in social API and kept it like the access token. So earlier, the access token was stored blankly in the database after that we have encrypted it. So like if site gets hacked by anyhow, you're still that access to your account will be protected and we are now also providing an access token to like third party modules which they can use to perform actions on your behalf. In GCI 2017, social oath Amazon and social oath rate were created by Keefa Miran. They updated the documentation and students are now the active maintainer and part of the project. Also, we have a new logo for social entity which was created as part of Google code in this year. Now talking about the project, I was mentored by Valentin and Daniel Harris. Daniel Harris was the guy who came up with this social initiative project. So at the starting of the project in GCI, there are three major timelines, three major timelines of the milestones which you have to comply with. So what I did was in community period is I understand the basic understanding of Drupal and how various social network works. And then in phase one, I implemented the leak library in social oath and social post, refactored the whole authentication process which we will see later in this slide. In phase two, I added like more implementers, social oath, GitHub, Instagram, to our whole project. I wrote documentation and created base implementers which anyone can go and extend like create implementer for their own providers. For example, if you have WeChat in China, then you can go and create for implementer for that. Apart from this, our weekly meetings was conducted by our GSOC administrator, Matthew Leclerder, who was very helpful in the whole GSOC to me. Apart from that, Drupal at core uses symphony and there is API of that which Drupal core provides to the modules and themes. So social oath, social API was created on top of it, on top of Drupal core. And then social API extends social oath and social post, which utilizes the leak or to base library. And you can integrate your own third party implementers and like generic libraries there to create your own implementers. And other centers like OpenID, etc. are also there. Let it be OpenID and HOP. So they are there. One of the reason to choose what to client library, the league library was it is actively maintained, provide common abstract matter for different social networks. Large list of official supported and third party social network providers are there. And it makes social IPREP project more easy to manage and develop further. So authentication flow in social API is if user is logged in, then we add that account to link social provider to account of the user. If he's not logged in, then email address is obtained from social network. If social network provides an email address, then we check for the record of the user. If record already, that email address already exists in the database. We link that account, social network account to that user. Else, if email already exists, then we associate the email account. Else, if in case of some social network, they don't provide email address. So what we do is we ask user to fill other details like email and other required details and then he can complete his sign up or login. So what next for our project? One of the major tasks is adding more and more implementers. So for every social network out there which supports OAuth2, we want to edit in our list. Adding functionality like reordering the social network in our block icons. And creating command line tool with which you can create your own implementer in five minutes and add support for generic OAuth2 applications. So this is from my side if you have any questions. And these are the links to the project. If you want to see and create your own Drupal website and add this functionality, you can go there and find this. Thank you. Yeah. Great. Awesome. So, thanks very much. Yeah. Do you have a question? Is there anyone who has a question? I have a question for you. How did you find working against the Drupal APIs in eight versus seven? Okay, so there was already a project in Drupal seven. Which was based on hybrid OAuth, but we wanted to put it into like a Drupal eight. But hybrid OAuth is depreciated and like no more contribution are being made to the project to support like the ongoing implementers, ongoing social providers and different social providers. We have to like move on to the league library in the end. Yeah, yeah. Thank you. Thank you very much. So the next session here is in a bit.