[MUSIC] Hello and welcome back to our final lesson, Security. We'll kick off this lecture with what is OAuth 2. Why do we use OAuth and we'll look at a data flow. Basically, we have a little example and we'll walk through the example of how the data actually flows before we jump into a working demo. So what is OAuth 2? Well OAuth itself stands for Open Authorization. So it's an open standard protocol that provides simple and secure authorization for different types of applications. So basically the whole idea behind OAuth 2, and you will see this, is to allow providers to give access to users without any exchange of credentials. So, you don't have to, when you go to a website, you don't have to create an account. Because every time you go to a different website you'll have to create an account, fill up a form, click on okay. But, instead, if you have an account with, say, Facebook or GitHub or Twitter, Instagram, LinkedIn, all these support OAuth, where when you go to this main page, main web application, you don't have to create an account. Instead, you will get a little login form for any of these common applications and then you can login and get access. So it's a really nice, easy, quick way of using multiple applications with very minimal credentials exchange. And we'll talk a little more about this. So here is another good definition rather. An authorization framework that enables applications to obtain limited access to user accounts on an HTTP service say Facebook, GitHub, Twitter. So the important thing is limited access. You can control as a user how much access you want to give to this application that is requesting information, right? So what is the problem with password approach? Well, the users have to share their credentials so what do I mean by that so let's take an example of say so there is a website called say printingservice.com its just a made up website. Now, they have this feature where they can print pictures for a very inexpensive cost and they have all this different different flavors, different sizes, and all that. And they ship you the pictures for free. You want to obviously take advantage of this. Now, you want to print all of the pictures you have in a Facebook album, but what are the options you have? One, you can download all the pictures from Facebook to you local machine and then upload all the pictures to this new website. A lot of work. And the second option would be, say the website will say this printing service will say hey, why don't you give me the login and password to Facebook, and I'll take care of it. Which is okay, so you give the login and password, but the problem is it's not secure. You're giving of your login and password. And, secondly, what if you go and change the password in Facebook couple days later and you come back to the site a week from now. And then this site will have a problem connecting to Facebook because you changed the password and if you're doing this multiple sites, and you're trying to use multiple applications like Facebook, and LinkedIn, and Instagram. So you can see the problem with so many sites and so many passwords, it becomes a big maintenance problem. And not to forget the big security problem we have. So this is a big problem, and this is how, the OAuth2 will help you solve this problem because you will be connecting real time with one of these services. And they will take care of getting the token and all of that we'll talk about, but you will get away from the sharing of credentials problem. So how do you solve the problem? That's where OAuth comes into the picture. So OAuth approach is to secure without any password. So there's no exchange of log in or passwords that you actually give away to any application, as such. There is a concept of what we call tokens, and token is being used between the application like the printing service in my example with Facebook are, whichever service you decide to use. And we'll talk a lot more about that in the upcoming example. And again, bottom line, it allows providers to give access to users without any exchange of credential. So, you will be able to go to multiple sites without actually, and this is something you can see and today, when you go to website, the multiple website. When you go to glassdoor.com or other websites where you're trying to find some information, and then it'll ask you to either log in with the website's credentials, or you can use, say, Facebook's credentials or LinkedIn or any other service. So, that does save you from actually creating an account and simply getting inside with one of those sites. Okay, so that's the OAuth to an action with our little movie service example. So, in our little demo we have three players, we have a movie editor application, Mr. Ideas who is the user and a movie service. So the Movie Service is the one we've been playing with. It has a list of movies, and in reality will have a list of actors, directors, producers, all kinds of information about a movie. MovieEditor Application is this cool application where you can load a movie, edit, and do all kinds of things on a movie. And Mr. Ideas is a user who has an account with the movie service, and has a whole bunch of movies in his profile and other settings. And basically, he wants to log into the editor application, and he wants the editor application to represent him and fetch all the movies on his behalf from the movie service. So when the user is on this editor application he has all his profile his settings in all the movies that he needs so he can take a movie and make some changes on the service. It's an integrated editor application where all this information from here is put there. So, to get all this going, the first thing that the consumer, the service consumer which is the movie editor application has to do, is to register with the movie service provider, are the OAuth service in this case. So, there's a registration URL that needs to be called by the movie client or this consumer. Now, this is a simple form where you go in and fill in some basic information like the name of the movie and also the redirect URI. Now, we'll talk about the redirect URI a little more later on in the demo, but basically the redirect URI is where the service provider will send back an authorization code. Now the authorization code is basically an URL for the movie editor application in this example. So when you click on submit what happens is you get an app ID or client ID, a secret which is a password, and the callback URL, that we talked about. Okay, so now with the basic registration all done, so now Mr. Ideas will log in to the MovieEditor application and say, hey, I want to work on my movie. Can you go and please get all my movies? So at this point, the MovieEditor Web Application will say, okay, do you have an account with us? Do you want to log in? Or do you want to use Movie Service Login? The integrated OAuth service basically here. And this is, think of this as a button or a link. So when you click on this, what happens is now the movie service will send the app ID that we got, or the client ID that we got in the previous step. And it will send the redirect URI and also the scope, which is like in this example here. I want to create a movie and could be other edit option, delete option. Other things could potentially be here as well. Now, at this pont, the movie service will ask the user, hey, we have a request from this movie service application. The movie editor application. Would you like to authorize this request or deny the request? Also as part of this pop up or this message box, which I don't have the entire thing here, but basically to say do you want to authorize application to create movies, delete movies, post movies. It will give you the list of stuff, it's a Facebook or a linkden or any of those it will say do you want to share pictures, or do you want to share tweets. So, it will give you a profile of the combinations that the user had or rather, the application has basically asked. So, in this example, it's Create Movies, or Edit Movies, or Delete Movies. SImilarly, it could be sharing pictures, or tweets, or any number of combinations. Based on that, the user can take an action as to authorize or deny the request. So, once the user says, yep, I authorize this request, what happens is, the movie service will now send back a code. Now very important, this code is temporary and it's one time use only, so it has a very short life meaning you have to the editor application or the consumer application will have to go back with the code. And then get a token back. And again it's a one time use only. So what happens next is the editor application will take that code, using the app ID, and the secret ID will quick, will go back to the movie service application. And then, in return, if everything checks out and if everything is valid, the then movie service will basically come back and give an access token. This is the token very important that'll replace your credentials, your login and password. So any kind of action that was authorized like editing a movie, deleting a movie, updating a movie, all those actions from the MovieEditor Web Application will have to be done by attaching or sending the access token in every single request. Now here is the same example in a little more technical here compared to the previous chart. So as you can see, and this is pretty much our demo and we will go through every single step here. So here, step A that we talked about the prerequisite step where the admin would actually registered the application with the app name and the callback URL. And then the service, the OAuth service, will come back with AppRegistration information like provider name URL, call back URL, app id and secret which you kind of store this information. So when the user comes in, step 1, hey, can I access the movies for me, can you get the movies for me so that I want to make some edits? And the movie editor application will say, sure, I'll build a authorization URL I will do this in the example using an OAuth 2 gem. And it'll build a URL and will redirect to the provider site like Facebook or in our example the Movie Service. And it'll also give them information like, hey, where is the call back? How do you, once the authorization is done, where does this application need to come back? What is the scope? Whether it's editing or create movies in this example response type. And this information will be sent across. And then the authorization and the log in will happen between the user and the service, whether it shall get Facebook or Movie Service in this example. Now once all that is done, and authorization is done, the movie service, based on this information of redirect and call back and scope and all that. It will go back to the movie editor application here saying, oh I got all the authorization, you're good to go. Here is the callback question mark code equal to some number one two three in this little example. Using that code step seven you will go and get a token and that token is very important because any edits or any postings or whatever operation that you want to support from this application directly to the service. You will be doing that http call, that web service call, and you'll be sending access token equal to. That's the only way that a service will know actually what's going on, based on this access token. So there's no more login and password. It's all driven by this access token. So it's secure, and the transaction is all done using this token. So in summary, OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts. An HTTP service has Facebook and LinkedIn and Instagram and all that. It's basically the next evolution of the OAuth protocol. It was first originally introduced in 2006. So now that we know basics of OAuth and we also have a nice scenario set up, we will actually jump into this example and look at some hands on code and run or build this application block by block. So that we will reach the end result of using OAuth 2 and putting all these three different pieces together. Thank you.
