OAuth
OAuth is an open-standard framework for API authorization. It defines how an API client can obtain security tokens that express a set of permissions against the resources fronted by that API. These permissions often reflect the consent of the user that owns those resources. The tokens are attached by the client to its API messages to serve as proof of the client’s authorizations relative to the requests it makes of the resources.
Instead of requiring a user to share login credentials with one application in order to give that application access to another, OAuth delegates authorization decisions to a separate authorization server that hosts the user account. Essentially, OAuth acts on behalf of the user, providing delegated access to a third-party service without the user exposing their credentials to that third party.
For example, if you create an account on YouTube, and YouTube offers you the ability to sign on with your Google credentials, you can be authorized to access YouTube resources with those credentials without you ever having to supply them.
Note: OAuth 1.0a and OAuth 2.0 are the two different specifications available. They are different from each other, cannot be used together, and are not backward compatible. But most people today use OAuth 2.0, so that’s the specification we discuss here.
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.
The hotel check-in process is another example of how OAuth works. You visit the front desk and authenticate yourself by providing your ID. After you’ve proven who you are, the concierge at the desk exchanges that information for a hotel key card.
Your key card allows you to access your room, as well as the pool and fitness room. However, you will not be able to access the custodial closets to get additional towels yourself because you lack authorization.
The hotel check-in process is similar to the OAuth authorization process:
- The hotel can revoke your access at any time, just as the authorization server can revoke access at any time.
- Your key card does not have your identity or credentials on it, just as the access token granted by the authorization server doesn’t require user information to be included.
- You can use your keycard to access multiple hotel resources. In a similar way, the access token lets you access specified resources and denies access to others.
- Your key card will expire when you check out of the hotel. Your OAuth access token will also expire.
How does OAuth work?
Users give one application permission to access data in another application without having to provide their usernames and passwords. Instead, access tokens are used to complete the authorization process.
These tokens contain information about the authentication session, the user identifier, an identifier for the identity provider who issued the token, and an identifier for the client for which the token was created. Tokens also contain information about the length of time they'll be valid and the length of time that has passed since the authorization process began.
With OAuth, there are four different roles:
Resource Owner: The resource owner is you. You own your data and authorize an application to access your account information.
Client: The client is the application that wants to access your account information. Before it can access this information, you must authorize it, and the authorization must be validated by the API.
Resource Server: The resource server hosts protected user account information.
Authorization Server: The authorization server verifies the identity of the user then issues access tokens to the application.
There are a variety of different OAuth flow types available, but here's how OAuth flows work at a high level:
- When you sign on to an application, you’re prompted to authorize or deny the client application access to your account information.
- When you authorize the request, the client application receives an authorization code.
- The application presents authentication of its own identity, the authorization code to the authorization server, and requests an access token.
- If the application is authenticated and the authorization code is valid, the authorization server issues an access token to the application. Access tokens are similar to badges or key cards that give the client permission to perform specific actions on your behalf. Scopes are included in the token and define these permissions.
- The application requests the resources from the resource server API and presents the access token.
- If the access token is valid, the resource server API provides the user with a redirect URI that provides access to the application and the appropriate resources.
OAuth is not an authentication protocol
OAuth is used in a wide variety of applications and is used in a variety of different ways, which is why many people think it’s an authentication protocol, but it’s not. It even says so on their site.
Much of the confusion comes from the fact that OAuth is used inside of authentication protocols, and developers will see the OAuth components and interact with the OAuth flow and assume that by using OAuth, they can authenticate their users.
But there are a lot of different ways OAuth can be used, OAuth doesn’t define a specific token format or a common set of scopes for the access token, it doesn’t address how a protected resource validates an access token, and identity providers implement API identity differently, so custom code might be needed to integrate with vendors.
For example, a user's identifier might be found in a user_id field with one provider but in the subject field with another provider. Even though these identifiers are semantically the same, they would require two separate code paths to process. In other words, while the authorization might happen the same way at each provider, the ways in which they are conveyed could be different.
Start Today
Contact Sales
See how Ping can help you deliver secure employee, partner, and customer experiences in a rapidly evolving digital world.