[MUSIC] One of the benefits of using that single sign-on API, or those aspects of the iOS 9 SDK that enables single sign-on, which is when you, when the user signs into twitter and Facebook through the system preferences. And then apps can use those credentials that the phone has received, when it wants to interact with twitter and Facebook. One of the benefits of using that system, a single sign on system Is that there's a lot less work that the apps have to do in order to interact with these web services, like Twitter and Facebook, Sign-Up, Webo, and 10 Cent weber. Well, the fact of the matter is there are not very many social networks that are built-in deeply into iOS9. There are many more social networks that are out there. But not only social networks, but just sources of data that are out on the internet that might be really valuable for you to have in an app. Anything from weather data to traffic data. Maybe financial data, or political data, or tsunami data, or anything you are interested in. Largely, these sources of data are out there on the Internet, they're not deeply built into iOS 9. In order to get them, you often have to authenticate to those services using some kind of user name or password, in order to get access to the data that's there. This is because the services don't want their data to be abused, or used in ways that they at least can't have some insight into. What has ended up becoming a standard in accessing that data on the internet through these rest APIs, application program interfaces, is a technology called OAuth, and it's version 2.0, so, OAuth 2. On a high-level, what OAuth 2.0 is, it's a way to get access to data and services that require authentication. Most of these data and services require internet authentication. This isn't always the case, but it's very common now. In fact, when the idea of Web 2.0 first came about, and the idea of creating websites from mash-ups, and different sources of data. And that idea first emerged on the scene, maybe, I would say it happened in 2006 or 2007, a lot of the services didn't have any authentication behind them or they had authentication that they made on their own. But now, over time, most web services have centered on authentication using OAuth 2.0. Now, the motivation for this is interesting. Because you could ask, you could suggest maybe that an application, you could suggest maybe users user name and password, and then use that user name and password to log on to a remote service and get access to the data. That seems fine and relatively simple, why are we going to do something different than that? Well, it kinda comes down to trust in third party applications, by third party applications I mean applications that largely exist on smart phones but that aren't created by the service providers. So, like a Twitter app, that isn't written by Twitter, would be a third party Twitter app. But, I'm talking about ones that are not deeply integrated into the IOS system. So, maybe there's some source of data out there called electiondata.com. And you would like to access it. So you need a third-party app. My Election Data access app. In order to get that, in order to get into the data that's out there on the web service. You would have to give that app your user name and password. And the fact of the matter is, there's been a few note-worthy examples of apps that you can get that don't take very good care of your credentials. They can be sometimes just have poor security in them. So, they may be apps that were not written very well, that if you gave them your username and password, just in the process of that app trying to access the data,it might expose your username and password in ways that hackers could get a handle on. Another thing that that app might do if it had your username and password is it might request access to the data too often, or too frequently, or in ways that the data service provider doesn't want you to access them. For example, just speed is a common one. And the third reason why it might not be good to give that app your username and password is just because some apps that are out there are just malicious, they intend to be getting your username and passwords in order to steal your data or do other things with it. So, OAuth 2 was designed as a way to mitigate some of the risk of these kinds of things happening. When you use a third party app, it would be nice if you didn't have to give that app your user name and password, but still get access to your data like on Instagram. And if they do act badly, It would be nice to be able to unauthorize them, or deauthorize your third party app without having to change your username and password. So, that's what OAuth 2.0 enables. It's a way of providing application specific log on credentials. That means, that each App logs into your account with its own password, so you can have several of these apps. And you can remove access to your account's apps, and you can. Cuz if one of those services, you get nervous about, or it's actually demonstrated that it's doing something that you don't want, whether it's just poor design or bad decision making or actually malicious. So here's kind of an example of what it might be. Let's imagine there was a fictitious service out there called SnapGramr, and SnapGramr maybe has some kind of a photo sharing app for friends. You might have a pass username and password, so in this case, DonPatterson and SecretPassword88, and that's what I use to log on to the web service in order to get access to this data to get access to this social network through a web browser. Now, I might have three different third party apps loaded on my phone. Ultimate SnapGramr.App, SnapGramrPlus.App, Friends with SnapGramr, these are each examples of applications that were written by developers that are not associated with SnapGramr. But the application interacts with SnapGramr. Maybe it saves pictures, maybe it creates photo collages of those pictures, maybe it, I don't know, does any number of things that you might want to do, in addition to the services provided by the actual web interface. So, what OAuth 2.0 is gonna do is, it's gonna give each one of those applications its own password, demonstrated here by the number/character combinations on the arrows. So, that when it wants access to my account, it uses that application specific password. If later on, I become suspicious about with friends with SnapGramr, and think that well maybe it isn't actually providing me any value, maybe its done something I didn't want it to do. Maybe, I'm just done using it and I want to make sure its not accessing my SnapGramr account, then what I can do is I can just say, okay, that password's not good anymore. And that means, that friends with SnapGramr, while it still exists on my phone, won't have access to my data on the web service. And the other two applications, they can still continue accessing my data. That's one of the benefits of using OAuth 2.0. So our goal, our goal in making our Instagram app is that we want to get our app. A set of OAuth 2.0 credentials, so that we can access a web service, very specifically, like Instagram. So, we are gonna use the OAuth 2.0 protocol, so that our app can get a password, so that we can access Instagram on behalf of the user of our application. Each application has to authenticate on it's own. So, it's not like a single sign-on. This is a system where when you run the app, you're user's going to have to sign-on while they're using your app in order to have to sign on while they're using. And that's actually the argument for why single sign-on is so helpful. It would really be a pain if every time you had an app that did anything with Facebook, you had to authenticate separately for every single app every time you wanted to share. By building that into the IOS9 application, Apple has given you a little bit of relief of having to type in your name and password over and over again for any app that might interact with Facebook. An application has sign to each service separately. So, each application has to sign on to a single service separately, and a single application that signs on with multiple services has to sign on to each of those services separately, so it's kind of a many to many situation. If you look into the actual specifications for OAuth 2.0, as defined by the Internet Engineering Task Force, IETF, you'll find that there are actually four primary ways of doing OAuth 2.0 authentication. They're called Authorization Code, Implicit, Resource Owner Password Credentials, and Client Credential. They give credentials in different kinds of architectures depending on what sort of client server, client web service, client multiple web service situation you're, we're just gonna focus on one which is the implicit flow. And the implicit flow is the one that talks about how you have a single client authenticating to a remote web service, where you don't completely trust the third-party client. In this case, it would be the third-party app. If you want to look at the full specification, I put the URL on the bottom of the slide here. So that you can go see, what does an actual specification look like. If you're interested in that. Or if maybe someday you wanna write, be part of the team that writes one. That'll give you an example of what that ultimately looks like. So, this is a way the implicit flow works. First, the developer logs into a web service that has an API and registers themselves. So, that's like us logging onto Instagram and registering ourselves as an application developer, then you make the app. Then, when an app wants to access the API on behalf of the user. The user is going to try and do it and your app is going to open up a web browser, not within the app, a separate web browser, in which the user is going to log into that service. So, log into Instagram, if the user logs in correctly, then the browser is going to open a new webpage in response, that has a funny URL. And the thing about the way we set this up is we are going to tell iOS to associate that funny URL with our application. So, that when Safari tries to open that URL, it won't recognize the scheme, the part of the scheme is the part that says http or https. We're going to do something different. Safari's not going to recognize it. It's going to ask the operating system, what should I do when I see this funny scheme? And the operating system is going to say, oh, you're going to start that Coursera app. So, that's going to open up our app and when we open our app, the URL that it opens is going to have the credentials that we need In order to access Instagram on behalf of our users. So now, that's gonna be the next step our app can display information about the data that's out there remotely. So, just here's the flow visually if you're a visual learner. You're gonna start as a developer and you're gonna say hm, okay, I'm a developer, and I know that what I'm interested in is this third-party service called SnapGramr. That would be Instagram, but we'll call it SnapGramr for now. So, what we're going to do is we are going to say, okay, I want to make an app with SnapGramr, and therefore, what I am going need to do is I'm going to register as a developer. So, the service says if you want to develop an app you are going to need to register as a developer, and then we'll talk. Okay, so you're gonna use your username, your developer username and password in order to log into SnapGramr. You're gonna change your profile to identify yourself as a developer, and SnapGramr is gonna respond by giving you an ID and a secret that's used to identify the application. And so, if you make multiple kinds of applications that are going to interface with SnapGramr. Then each one of those kinds of application would use your ID and your secret. SnapGramr will give that back to you as a developer. And you need to have that before you can finish writing your app. Once you have it, though. You can make your app. And within your app you're gonna put those credentials. So, the app is gonna be associated with you as a developer. Then, a user's gonna come along, and the user's gonna get Ultimate SnapGramr App, that's the app that you've developed, and put it on their phone. They're gonna say, hey, I really like this new app. I would love it to be able to manage my SnapGramr account. So, when the user gets to the point where they wanna do that, Ultimate SnapGramr app is gonna try and access SnapGramr, and try and get data on behalf of the user. And SnapGramr's gonna say, whoa, just wait a second. Please authorize Ultimate SnapGramr. Please authorize before I'm gonna let you get access to this user's information. So, what's gonna happen is the user through a web browser on their phone is going to log into SnapGramr, not through the Ultimate SnapGramr App. It's gonna send the login information and SnapGramr is gonna respond with this funny URL. And if you provide the right credentials with that funny URL. The operating system is gonna be confused, Safari is gonna be confused. It's gonna ask the operating system, and the operating system would say, oh, that funny scheme? That is handled by you, Ultimate SnapGramr App. And in that URL is the credentials, so at that point, you have the appropriate passwording credentials to be able to send data back and forth on behalf of the user. And the user continues to say, I love this new app. I'm gonna buy all kinds of in app purchases and make the developer fantastically wealthy. So, in summary, OAuth 2.0 is a way for apps to gain access to web services on behalf of the users. It provides some protection against malicious apps, or kinda more common cases just poorly written apps. Apps that you maybe grow disillusioned with or you were trying out. You don't want them to access your data after that. It requires the develop to register with the web service and it requires. So your app has to. In order to write that app you have to register as a developer, that app has to have network access, and the user has to consent to giving your app access to the web service. And the way they do that, is by filling in their username and password after they start your app. Okay, that's what's happening. And now, what we're gonna do is we're gonna actually implement that into our Instagram app. The first thing that we're gonna need to do in order to pull this off is to go to Instagram, register as a developer, and get the information that we need to put it back in our application. All right, so let's do that next. [MUSIC]
