© ideyweb/Shutterstock.com
Authentifizierung und Autorisierung mit Hilfe von Tokens

Sicher ist sicher


Authentifizierung und Autorisierung innerhalb einer Webanwendung sind kein Problem, über Anwendungsgrenzen hinweg oder gegenüber Web Services aber schon. OAuth und OpenID Connect lösen dieses Problem.

Die Authentifizierung ist der Nachweis der Identität des Benutzers gegenüber der Anwendung. Nach der Authentifizierung weiß die Anwendung, wer der Benutzer ist, bzw. dass er der ist, der er behauptet zu sein. Zu wissen, wer der Benutzer ist, ist bei vielen Funktionen nur der erste Schritt vor der Ausführung. Oft muss die Anwendung auch prüfen, ob der Benutzer überhaupt berechtigt ist, eine bestimmte Funktion aufzurufen, auf bestimmte Daten zuzugreifen – das ist die Autorisierung. Jeder Benutzer hat bestimmte Berechtigungen, und bei jedem Zugriff auf eine geschützte Ressource wird geprüft, ob der Benutzer die für diesen Zugriff nötigen Rechte besitzt.

Benutzerprüfung über Anwendungsgrenzen hinweg

Solange sich die Benutzerprüfung innerhalb einer Anwendung abspielt, ist alles recht einfach zu lösen: Die Anwendung kann ihre eigenen Benutzer problemlos selbst verwalten und sowohl festlegen als auch durchsetzen, welcher Benutzer welche Funktionen nutzen und auf welche Daten er zugreifen darf. Anders sieht es aus, wenn eine Anwendung im Namen des von ihr authentifizierten Benutzers auf Funktionen eines anderen Diensts, z. B. einer anderen Webanwendung oder einen Web Service, zugreifen soll. Solange dafür auf Dienstseite keine Authentifizierung nötig ist, ist das kein Problem. Allerdings ist das nur sehr selten der Fall, meist sind viele Funktionen und Daten nur bestimmten Benutzern zugänglich. Und sobald die Benutzer sich einloggen müssen, um den Dienst zu nutzen, wird es schwierig. Die zugreifende Anwendung benötigt dafür den Benutzernamen und das Passwort des betroffenen Benutzers für den Dienst. Und das bringt einige Probleme mit sich:

  • Passwortweitergabe an Dritte erwünscht (durch den Dritten): Der Benutzer muss seine Zugangsdaten für den Dienst auf einer fremden Website eingeben. Was man bekanntlich keinesfalls tun sollte, um nicht Opfer eines Phishing-Angriffs zu werden. Wenn man nun anfängt, den Benutzern zu erklären, dass sie die Daten auf dieser bestimmten fremden Seite eingeben dürfen, erleichtert das den Phishern die Arbeit enorm. Die Benutzer haben dann ja schon gelernt, dass sie die Daten manchmal auf einer fremden Seite eingeben dürfen. Dann ist es kein größeres Problem, sie mittels Social Engineering dazu zu bewegen, sie auch auf einer weiteren Seite einzugeben – der Phishing-Seite.

  • Passwortweitergabe ist verboten (durch den Anbieter): Der Benutzer muss in vielen Fällen gegen die Nutzungsbedingungen der genutzten Webanwendung bzw. des Web Service verstoßen, denn die verbieten im Allgemeinen die Weitergabe der Zugangsdaten an Dritte.

  • Speichern oder nicht? Das hängt davon ab, ob die Zugangsdaten von der nutzenden Webanwendung gespeichert werden oder nicht. Werden sie nicht gespeichert, muss der Benutzer sie immer wieder eingeben, was je nach Häufigkeit der Nutzung nicht besonders komfortabel ist und die Benutzer leicht abschreckt. Das möchte man natürlich nicht, weshalb die Betreiber der Webanwendung dazu neigen werden, die Zugangsdaten zu speichern. Dann muss der Benutzer darauf vertrauen, dass sie mindestens so gut geschützt werden wie bei der eigentlichen Webanwendung bzw. dem Web Service. Das wiederum ist technisch nicht möglich: Der eigentliche Anbieter wird die Passwörter als Passwort-Hashes speichern, mit denen ein Angreifer nichts anfangen kann. Der Dritte muss die Passwörter als Klartext speichern, da sie als Klartext an den genutzten Dienst geschickt werden müssen. Er kann sie verschlüsseln, aber das bietet nur einen geringen Schutz: Der Server muss sie ja entschlüsseln können, um sie zu nutzen, und das kann auch ein Angreifer nutzen, um sich die Klartextdaten zu verschaffen.

  • Beim zweiten Faktor ist Schluss: Wenn die genutzte Anwendung bzw. der Web Service eine Zwei-Faktor-Authentifizierung verwendet, wird die automatisierte Nutzung nahezu unmöglich, denn die nutzende Anwendung ist natürlich nicht im Besitz dieses zweiten Faktors. Es bleibt also nur die Möglichkeit, den Benutzer jedes Mal die Authentifizierung durchführen zu lassen. Was diesen wiederum abschrecken dürfte.

Die Lösung dieses Problems: OAuth

Die Lösung dieser Probleme heißt OAuth (Open Authorization [1]), ein offenes Protokoll für eine standardisierte, sichere API-Autorisierung. Ein Benutzer (der Resource Owner) kann mit Hilfe des OAuth-Protokolls einer Anwendung (dem Client) den Zugriff auf seine Daten erlauben, die von einem anderen Dienst (dem Resource Server) bereitgestellt werden. Und das, ohne dem Client die Zugangsdaten für den Resource Server verraten zu müssen. Stattdessen erhält der Client vom so genannten Authorization Server ein Access Token, mit dem er auf den Resource Server zugreifen kann. Der Benutzer kann also einen Dritten damit beauftragen, in seinem Namen einen Dienst zu nutzen, ohne ihm z. B. sein Passwort mitteilen zu müssen. Eine weitere Möglichkeit zum Einsatz von OAuth ist die Nutzung eines Autorisierungsdiensts. Der Benutzer benötigt dann kein eigenes Konto bei allen möglichen Onlineportalen, Newsseiten etc., sondern nur eins bei einem Autorisierungsdienst, z. B. Facebook. Er kann sich dann überall mit seinem vorhandenen Autorisierungsdienstkonto anmelden. Die Authentifizierung erfolgt dementsprechend gegenüber dem Autorisierungsdienst, der danach die Autorisierung für alle weiteren Dienste übernimmt.

OAuth im Überblick

Wie schon erwähnt, gibt es im OAuth-2.0-Protokoll vier Entitäten:

  1. Der Client ist die Anwendung, die im Namen des Resource Owners auf den Resource Server zugreifen will.

  2. Der Resource Owner ist der Benutzer des Resource Servers, der dem Client den Zugriff darauf in seinem Namen und mit seinen Rechten erlauben will.

  3. Der Resource Server ist der Dienst, auf den der Client im Namen des Resource Owners mit dessen Rechten zugreifen soll.

  4. Der Authorization Server ist der Server, der die Authentifizierung des Resource Owners durchführt und nach erfolgreicher Authentifizierung nach dessen Erlaubnis das Access Token ausstellt.

Der Ablauf der Autorisierung

Wenn ein Client auf die Daten eines Resource Owners auf dem Resource Server zugreifen möchte, läuft die OAuth-Autorisierung folgendermaßen ab (siehe auch Abb. 1, die Nummerierung der Schritte entspricht der Nummerierung in der Abbildung):

  1. Der Client sendet einen Authorization Request an den Resource Owner, mit dem er um seine Zustimmung zur Autorisierung gebeten wird.

  2. Nachdem der Resource Owner der Autorisierung zugestimmt hat, erhält der Client ein sog. Authorization Grant zurück.

  3. Der Client sendet den erhaltenen Authorization Grant an den Authorization Server.

  4. Der Authorization Server prüft das Authorization Grant und stellt dem Client ein Access Token aus.

  5. Der Client verwendet das Access Token für die Autorisierung seiner Aufrufe an den Resource Server (5. ff).

eilers_oauth_1.tif_fmt1.jpgAbb. 1: Die OAuth-Autorisierung im Überblick

Im Fall von Webanwendungen wird der Benutzer im ersten Schritt zur Autorisierung im Allgemeinen über eine Weiterleitung zum Authorization Server geschickt, der ihn um seine Zustimmung zur gewünschten Autorisierung bittet. Wenn keine laufende Session vorhanden ist, muss der Benutzer sich dazu vorher einloggen.

In diesem Spezialfall sieht der Ablauf unnötig kompliziert aus, da der Authorization Server nach der Zustimmung des Benutzers das Authorization Grant an den Client schickt und es daraufhin postwendend zurückbekommt. Das liegt aber nur daran, dass der Authorization Server in diesem Fall auch die Frage nach der Zustimmung übernimmt. Die Autorisierung kann auch auf anderen Wegen erfolgen, und dann bekommt der Client das Authorization Grant z. B. direkt vom Resource Owner, um es danach beim Authorization Server gegen sein Access Token einzutauschen (Abb. 1).

Regeln für Rechte und Zugriff

Der Resource Server kann anhand des Access Tokens feststellen, im Namen welches Benutzers der Client agiert und welche Rechte dieser ihm übertragen hat. Der Benutzer muss dem Client nicht alle seine Rechte übertragen, sondern kann sie auch einschränken. Muss der Client z. B. nur Daten lesen, kann der Benutzer ihm auch nur reine Leserechte einräumen und muss nicht zusätzlich seine Schreibrechte übertragen, mit denen ein Missbrauch des Resource Servers möglich wäre.

Access Token...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang