OAuth

Hi everyone and welcome to the first part of our 100th series.
In this class we're just going to very basically what is OOF.
Never heard of OAF or you heard the word and you have no idea what it means.
So this is absolutely basic.
What is OOF?
So the first thing I want to say is that it is pronounced Owaf.
It's not pronounced oath.
It's a very good way to let people know that you have no idea what's going on.
So it is pronounced Owath.
So the basic problem with OO, let's say you have a new Web application, such as a new version of LinkedIn, a new version of Facebook, Just some new social application, and you sign up for this application, You sign up for this website, and this website says, Hey, Would you like to know if your friends are on this website too?
If you give me your email password, I will check your email contacts and I'll go find you Friends and hook you up with them.
And you say, that sounds great, here's my email password.
Go find my friends.
So the problem with that is you just gave an app your email password.
How do you control what that app does with your password?
How do you make sure that new social network, that new social website doesn't sell Your password doesn't change your email context; doesn't read your inbox.
Doesn't delete your inbox?
You don't know; you have no control over this because you just gave this application Your email password.
But you still want this Website to be able to go find your friends.
You still want this website to look at your Contact list.
So there has to be a way to do this without actually giving out your password.
So the solution to that is OO.
The solution to that is giving out these tokens.
Instead of giving out your password, You give out a token.
It's like a coupon.
It says, you can look at my contacts, you can only look at my contacts.
That's what this is good for.
Can't see my email inbox, only see my contacts.
There's no sharing of passwords.
Again, you don't give out your password.
You've basically given out this coupon, this token.
If you change your email password, that's OK.
They don't have your password, They have a token.
The token still works.
If you decide you don't want them to have that token anymore, If you want to take away their access to your email contacts, Just revoke the token; just take the token away.
So it's much more manageable.
It's giving an application access to what you Want to give them without giving out your password.
That's the idea.
Oh well.
You're giving out these tokens instead of your passwords.
So these tokens can be limited by scope, time, and action.
So we're saying, hey, this new social website can only see my contacts for the next hour.
That's more than enough time for a website to look through your contacts, And it's read-only.
Not only can you not see my inbox, but it's timed, and you can't change my contacts.
You can't delete any.
You can just look at them.
O tokens are scoped, so they're safe to be exactly what you need them to do.
So the real-life example of this is a valet key.
If I have a 300,000 Lamborghini convertible, I have a super expensive car.
If I go to a restaurant, I am not going to park this car myself.
If I can afford a $300,000 Lamborghini convertible, I am probably not going to want to Park it myself.
I'm probably just wanting to go inside.
So I'm going to give the valet a key to park my car, but I'm not going to give the valet the Real key to park my car.
I'm not going to give the valet a key which Will pop the trunk, which will open the glove compartment, which will put down the hood.
I'm not gonna give the valet a key that does all of that.
He's going to steal my car if I give him the car key.
So instead, expensive cars have a valet key.
This valet key only lets the valet do what he needs to do, so it only lets him drive 2 miles.
It doesn't let him put down the hood.
It doesn't let him go on a cruise down the Highway.
It doesn't let him open the glove compartment, only lets him do what he needs to do, which is park my car.
OS tokens are like your valet key to the web.
OS Tokens, again, they're limited.
They only let this website or whoever you're Giving this to do what they need to do.
I just want to point out a difference in terminology here.
I know we all know these words, but they're both used with OAuth2 and it gets confusing Very quickly.
So authentication is, are you who you say you Are?
Who are you?
If I go to Google, I log into my Gmail account, I put in my username and password.
I authenticate against Google.
Versus Authorization.
Authorization is what am I allowed to see.
I am not allowed to see the internal workings of Google's domain.
I am not allowed to see your Gmail accounts.
I am only allowed to see my Gmail account.
So, authentication: are you who you say you are?
Authorization: What are you allowed to see?
OAuth is an authorization protocol.
We don't care how the user authenticates.
We just care what that website is allowed to do.
That website's allowed to look at my inbox or look at my contacts, And that's all.
If we go through a walkthrough, Now we're going to switch examples.
Now we're going to have a music website called Tunes Partner, And we're going to have a bank called IDel.
I would like to buy a song from Tunes Partner, and I'd like to pay for it with my bank account.
The first thing I'm going to do is I'm going to click on the album I want to buy.
I'm going to click in the bottom left, this week's Top 10.
I want to buy this album.
Toon's partner redirects me to the bank.
Toon's partner redirects me to Iytel, and I log into the bank.
I put my username and password.
I authenticate against the bank.
The bank says, Do you have an account here?
I say yes.
And then the bank asks me, Toon's partners Requesting permission to charge your account.
Is that OK?
So these pages are presented by the bank.
Toon's partner doesn't see this.
Toon's partner doesn't see my password.
They don't put up this page.
The bank is asking me.
Are they allowed to do this?
And if I say yes, then Toon's partner gets that token in the background, and Toon's partner can use that token, and that token says, Tounes partners allowed to charge me $10.
So Toon's partner never saw my bank password.
I logged in at the Bank domain.
The bank asked me if this was OK.
Toon's partner never saw my password.
So this is akin to if I go back a screen here.
If you've ever bought anything with PayPal, PayPal will present you.
Please log in.
Hey, is it OK if this website charges you some money?
And those pages are put up by PayPal.
Whatever website you're buying from doesn't Ever see your PayPal password.
That's OAF.
OAuth is an open protocol standard for web API Authorization.
It's essentially a way to grant these third parties access to your resources, to your stuff, without giving out passwords.
So we're giving out tokens.
Again, the music website gets a token to charge My bank account.
I don't have to give the music site my bank Password.
The social media website, I can give a token to Look at my email contacts.
I don't have to give them my email password.
That's the idea of OLAF.
The whole idea of OLAF is to get tokens.
That's all of OAF.
It's a protocol standard for API authorization.
Is whoever holds this token allowed to access something?
So that's our summary of what OAF is.
For more information, keep watching our series.
The next presentation is on terminology, so you can learn more about the different terminology In OAF that you're going to hear.
You can learn about the different types of tokens because there are different types of Tokens.
That's the next series, and thanks for joining.
U.S.