OAuth
OAuth, das jetzt OAuth 2.0 heißt, ist ein offener Standard für die API-Autorisierung. Er definiert, wie ein API-Client die Sicherheitstoken erhält, die eine Reihe von Berechtigungen für die von dieser API bereitgestellten Ressourcen enthalten. Diese Berechtigungen orientieren sich häufig an der Einwilligung des Benutzers, der diese Ressourcen „besitzt.“ Die Token werden vom Client an seine API-Meldungen angehängt und dienen auf diese Weise als Nachweis der Berechtigung des Clients für den Zugriff auf angefragte Ressourcen.
Anstatt von einem Benutzer zu verlangen, dass er seine Anmeldeinformationen einer Anwendung weitergibt, damit diese auf eine weitere Anwendung zugreifen kann, delegiert OAuth die Autorisierungsentscheidungen an einen separaten Autorisierungsserver, der das Benutzerkonto hostet. Im Wesentlichen handelt OAuth im Namen des Benutzers und bietet delegierten Zugang zu einem Drittanbieterdienst, ohne dass der Benutzer seine Anmeldeinformationen an diesen Drittanbieter weitergeben braucht.
Wenn Sie z. B. ein Konto bei YouTube einrichten möchten und YouTube Ihnen die Möglichkeit bietet, sich mit Ihren Google-Anmeldedaten anzumelden, erhalten Sie mit diesen Daten die Autorisierung für den Zugriff auf YouTube-Ressourcen, ohne jemals dort Ihre Daten angeben zu müssen.
Hinweis: Die beiden verfügbaren Spezifikationen sind OAuth 1.0a und OAuth 2.0. Sie unterscheiden sich voneinander, können nicht gemeinsam verwendet werden und sind nicht abwärtskompatibel. Die meisten Leute verwenden heute jedoch OAuth 2.0, daher werden wir uns hier mit dieser Spezifikation befassen.
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.
Das Einchecken in ein Hotel ist ein weiteres Beispiel für die Funktionsweise von OAuth. Sie gehen zur Rezeption und legen zur Authentifizierung Ihren Personalausweis vor. Anschließend händigt Ihnen der Portier am Schalter anhand dieser Information eine Hotelschlüsselkarte aus.
Mit Ihrer Schlüsselkarte haben Sie Zugang zu Ihrem Zimmer, zum Pool und zum Fitnessraum. Sie werden damit jedoch keinen Zugang zu den Wäscheschränken erhalten, um sich selbst zusätzliche Handtücher zu holen, da Sie dazu nicht berechtigt sind.
Der Autorisierungsprozess bei OAuth ist vergleichbar mit dem Hotel-Check-In.
- Das Hotel kann Ihren den Zugang jederzeit wieder entziehen, ebenso wie der Autorisierungsserver die Zugriffsberechtigung jederzeit widerrufen kann.
- YAuf Ihrer Schlüsselkarte sind weder Ihre Identität noch Ihre Anmeldedaten gespeichert, und auch das vom Autorisierungsserver gewährte Zugriffstoken muss keine Benutzerinformationen enthalten.
- Sie können Ihre Schlüsselkarte für den Zugang zu mehreren Hotelressourcen verwenden. In ähnlicher Weise ermöglicht das Zugriffstoken den Zugang zu bestimmten Ressourcen und schließt andere Ressourcen aus.
- Mit dem Auschecken aus dem Hotel verfällt Ihre Schlüsselkarte. Ihr OAuth-Zugriffstoken läuft ebenfalls ab.
Wie funktioniert OAuth?
Benutzer erteilen einer einzelnen Anwendung die Erlaubnis, auf Daten in einer anderen Anwendung zuzugreifen, ohne dass sie dort ihren Benutzernamen und ihr Passwort angeben müssen. Stattdessen wird der Authentifizierungsprozess mithilfe von Zugriffstoken abgewickelt.
Diese Token enthalten Informationen über die Authentifizierungssitzung, die Benutzerkennung, eine Kennung für den Identitätsprovider, der das Token ausgestellt hat, und eine Kennung für den Client, für den das Token erstellt wurde. Die Token enthalten auch Informationen über die Dauer ihrer Gültigkeit und die Zeit, die seit Beginn des Autorisierungsprozesses verstrichen ist.
Bei OAuth gibt es vier verschiedene Rollen:
Eigentümer der Ressource: Sie sind der Eigentümer der Ressource. Als Besitzer Ihrer Daten ermächtigen Sie eine Anwendung zum Zugriff auf Ihre Kontoinformationen.
Client: Der Client ist die Anwendung, die auf Ihre Kontoinformationen zugreifen möchte. Bevor er auf die Informationen zugreifen kann, müssen Sie dies erlauben. Diese Autorisierung muss von der API validiert werden.
Ressourcenserver: Der Ressourcenserver hostet geschützte Kontoinformationen von Benutzern
Autorisierungsserver: Der Autorisierungsserver prüft zunächst die Identität des Benutzers und gibt dann Zugriffstoken an die Anwendung aus.
Es gibt eine Vielzahl verschiedener OAuth-Flow-Typen, aber das folgende Diagramm erklärt, wie OAuth-Flows auf hohem Niveau funktionieren.
- Wenn Sie sich bei einer Anwendung anmelden, werden Sie dazu aufgefordert, der Client-Anwendung den Zugriff auf Ihre Kontodaten zu gestatten oder zu verweigern.
- Wenn Sie die Anfrage autorisieren, erhält die Client-Anwendung einen Autorisierungscode.
- Die Anwendung legt dem Autorisierungsserver die Authentifizierung ihrer eigenen Identität sowie den Autorisierungscode vor und fordert ein Zugriffstoken an.
- Wenn die Anwendung authentifiziert und der Autorisierungscode gültig ist, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung aus. Zugangstoken sind vergleichbar mit Ausweisen oder Schlüsselkarten, die dem Kunden gestatten, bestimmte Aktionen in Ihrem Namen durchzuführen. Die Geltungsbereiche sind im Token enthalten und definieren diese Berechtigungen.
- Die Anwendung fordert die Ressourcen von der API des Ressourcenservers an und übermittelt das Zugriffstoken.
- Wenn das Zugriffstoken gültig ist, liefert die Ressourcenserver-API dem Benutzer einen Redirect-URI, der den Zugriff auf die Anwendung und die entsprechenden Ressourcen ermöglicht.
OAuth ist kein Authentifizierungsprotokoll
OAuth wird in einem breiten Spektrum von Anwendungen und auf unterschiedliche Weise verwendet, daher wird häufig angenommen, es handele sich um ein Authentifizierungsprotokoll, was allerdings nicht stimmt. Auf der Website wird sogar darauf hingewiesen.
Ein Großteil der Verwirrung rührt daher, dass OAuth im Rahmen von Authentifizierungsprotokollen verwendet wird. Die Entwickler sehen die OAuth-Komponenten, sie interagieren mit dem OAuth-Flow und gehen davon aus, dass sie durch die Verwendung von OAuth ihre Benutzer authentifizieren können.
OAuth kann jedoch auf viele verschiedene Weisen eingesetzt werden. Es legt kein spezifisches Token-Format oder einen allgemeinen Satz von Geltungsbereichen für das Zugriffstoken fest, es gibt nicht an, wie eine geschützte Ressource ein Zugriffstoken validieren soll, und Identitätsprovider implementieren die API-Identität auf eine andere Weise, daher ist für die Integration mit Anbietern möglicherweise ein eigener Code erforderlich.
Beispielsweise kann die Kennung eines Benutzers bei dem einem Anbieter im Feld user_id und bei einem anderen im Feld subject zu finden sein. Obwohl diese Kennungen semantisch identisch sind, würde deren Verarbeitung zwei separate Codepfade erfordern. Mit anderen Worten: Selbst wenn die Autorisierung bei jedem Anbieter gleich abläuft, kann die Art und Weise der Übermittlung unterschiedlich sein.
Starten Sie jetzt
Kontaktieren Sie uns
Erfahren Sie, wie Ping Ihnen helfen kann, sichere Erlebnisse für Mitarbeiter, Partner und Kunden in einer sich schnell wandelnden digitalen Welt zu bieten.