OAuth v2-Kommunikation zwischen Authentifizierung und Ressourcenserver

Ich habe einige Probleme zu verstehen, wie OAUTH-v2 funktioniert.

Die OAuth Version 2-Spezifikation lautet:

7. Zugriff auf geschützte Ressourcen

   Der Client greift auf geschützte Ressourcen zu, indem er das Zugriffstoken
   dem Ressourcenserver vorlegt. Der Ressourcenserver MUSS das
   Zugriffstoken validieren und sicherstellen, dass es nicht abgelaufen ist und dass sein Bereich
   die angeforderte Ressource abdeckt . Die Methoden , mit dem Ressource - Server verwendet , um
   das Zugriffstoken (sowie etwaige Fehlerreaktionen) zu validieren sind über den Rahmen dieser Beschreibung , aber in der Regel eine Wechselwirkung oder Koordination zwischen dem Ressourcen - Server und dem Berechtigungs beinhalten
   Server .

Wie funktioniert diese Interaktion zwischen Ressourcenserver und Autorisierungsserver in der Praxis?

• Wie stellt der Ressourcenserver fest, dass ein empfangenes Zugriffstoken gültig ist?
• Wie extrahiert der Ressourcenserver den zulässigen Bereich aus dem Token, um festzustellen, ob einer bestimmten Ressource Zugriff gewährt werden soll? Ist der Bereich im Zugriffstoken codiert oder muss der Ressourcenserver zuerst den Autorisierungsserver kontaktieren?
• Wie wird das Vertrauen zwischen dem Ressourcenserver und dem Autorisierungsserver hergestellt?

Zugriffstokenattribute und die Methoden für den Zugriff auf geschützte Ressourcen gehen über den Rahmen dieser Spezifikation hinaus und werden durch Begleitspezifikationen definiert.

Kann jemand Beispiele für Token-Attribute geben?

Der Grund, warum dies für die Spezifikation nicht möglich ist, liegt in der Vielzahl von Möglichkeiten, diese Verbindung zwischen den beiden Entitäten herzustellen. Die Hauptfrage ist, wie komplex Ihre Bereitstellung ist.

Haben Sie beispielsweise einen Server, der die Authentifizierung und den Zugriff verwaltet, und eine Reihe diskreter Dienste mit jeweils eigenen Servern, die die API-Aufrufe bedienen? Oder haben Sie nur eine Box mit einem Webserver, der sowohl die Authentifizierung / Autorisierung als auch die API-Aufrufe verarbeitet?

Im Fall einer einzelnen Box wird nicht viel benötigt, da die Entität, die Token ausstellt, mit der Entität identisch ist, die sie validiert. Sie können Token implementieren, um bei jeder Anforderung einen Datenbanktabellenschlüssel zu verwenden und den Datensatz in der Datenbank (oder im Speichercache) nachzuschlagen, oder Sie können den Bereich, die Benutzer-ID und andere Informationen direkt in das Token codieren und mit einem symmetrischen oder asymmetrischen Code verschlüsseln Algorithmus.

Im Umgang mit einer verteilten Umgebung werden die Dinge etwas komplexer, aber nicht viel. Sie stellen weiterhin Token auf dem Autorisierungsserver aus, aber der Ressourcenserver benötigt eine Möglichkeit, diese zu validieren. Dazu kann dem Ressourcenserver eine interne API zur Verfügung gestellt werden, die den Autorisierungsserver auffordert, das Token "aufzulösen" (was in einer lokalen Umgebung schnell sein kann), oder die beiden können ein öffentliches / privates Schlüsselpaar oder ein symmetrisches Geheimnis einrichten und verwenden Sie dies, um alles, was der Ressourcenserver benötigt, in das Token zu verschlüsseln.

In sich geschlossene Token sind länger, bieten jedoch pro Anfrage eine viel bessere Leistung. Sie sind jedoch mit einem Preis verbunden - Sie können sie nicht wirklich widerrufen, solange sie noch gültig sind (nicht abgelaufen). Aus diesem Grund sollten eigenständige Token sehr kurzlebig sein (was auch immer für Sie akzeptabel ist, um den Zugriff nach dem Widerruf offen zu lassen - z. B. verwenden viele Websites eine Stunde), mit einem Aktualisierungstoken, das ein Jahr oder länger gültig ist, um neue Token zu erhalten.

Ein Beispiel für die API für Ressourcen zum Autorisierungsserver ist die auf der Google Developers Website .
Das Format des Zugriffstokens wird zwar nicht angegeben, aber die Antwort scheint allgemein nützlich zu sein.