Neben der Identifizierung und Authentifizierung von Nutzern im Internet ist es wichtig, dass Identity Provider geeignete Schnittstellen für die Autorisierung von Zugriffen auf schützenswerte Ressourcen über verschiedene Instanzen hinweg anbieten. Hierfür hat sich das OAuth 2.0 Protokoll im Internet durchgesetzt.
Konzeptionell ist das OAuth 2.0-Protokoll lediglich für die Autorisierung zuständig. Abhängig von dem benötigten Sicherheitslevel eines Internetdienstes kann ein erfolgter Autorisierungsnachweis mittels OAuth 2.0 ebenfalls als eine Pseudo-Authentifizierung betrachtet werden. Für eine höhere Cyber-Sicherheit sollte OAuth 2.0 jedoch grundsätzlich um ein zusätzliches Protokoll für die Authentifizierung ergänzt werden. Hierfür kann beispielsweise der offene Standard OpenID Connect verwendet werden.
Die Protokollabläufe von OAuth 2.0 sind schematisch aus Sicht einer nativen Anwendung auf einem Endgerät dargestellt. In dieser Darstellung wird davon ausgegangen, dass die Anwendung auf eine geschützte Ressource auf den Servern einer fremden Instanz zugreifen möchte. Die Autorisierung des Zugriffes erfolgt durch den Besitzer der Ressource. In den „Best Current Practice“ nach RFC 8252 wird für diesen Anwendungsfall aus Gründen der Benutzerfreundlichkeit und IT-Sicherheit empfohlen, dass die Kommunikation über einen externen Browser auf dem Endgerät erfolgt. Bei den beiden Endpunkten „Authorization Endpoint“ und „Token Endpoint“ handelt es sich um berechtigte Instanzen für die Erteilung des Zugriffes auf die geschützten Ressourcen. Diese beiden Endpunkte können entweder von einer Instanz zusammen oder getrennt voneinander verwaltet werden.
Die drei wesentlichen Protokollabläufe von OAuth 2.0
1. Authorization Request: Die Anwendung auf dem Endgerät öffnet mit den Werkzeugen des zugrunde liegenden Betriebssystems eine Browsersession zwischen der Anwendung und dem Server des „Authorization Endpoints“. Innerhalb dieser Session wird die Autorisierung realisiert. Hierfür sollte der „Authorization Endpoint“ den Nutzer zuerst mittels zusätzlicher Mechanismen authentifizieren, die von OAuth 2.0 nicht weiter spezifiziert werden.
2. Authorization Code: Nach erfolgreicher Autorisierung und gegebenenfalls Authentifizierung wird dem Browser ein Autorisierungscode zur Verfügung gestellt. Mithilfe dieses Codes kann im weiteren Verlauf nachgewiesen werden, dass eine Autorisierung erfolgreich durchgeführt wurde. Dieser Autorisierungscode wird mit den Werkzeugen des Betriebssystems an die Anwendung weitergegeben. Mit dem Autorisierungscode allein kann noch nicht auf die Ressource zugegriffen werden. Die Anwendung ist aber nun in der Lage, mit dem Autorisierungscode einen Zugriffscode, oder auch „Access Token“ genannt, beim „Token Endpoint“ anzufordern.
3. Access Token, Refresh Token: Der Autorisierungscode wird beim „Token Endpoint“ zuerst auf Gültigkeit überprüft. Anschließend wird der Anwendung ein Zugriffscode ausgestellt, mit dem der Zugriff auf die Ressource erfolgen kann. Ein „Refresh Token“ wird auf ähnliche Weise immer dann angefordert, wenn der Zugriffscode abgelaufen ist.
Anwendungsbeispiel: Facebook Connect
Facebook ist mit seiner großen Verbreitung ein potenzieller Identity Provider für viele Nutzer im Internet. Der Log-in-Dienst von Facebook ist grundsätzlich als proprietäre Alternative zu dem offenen Standard OpenID Connect einzuordnen.
Wesentlicher Bestandteil ist ebenfalls das Autorisierungsprotokoll OAuth 2.0.
Konzept des Log-in-Dienstes von Facebook und die Integration von OAuth 2.0
Als konkretes Anwendungsbeispiel wird die Anmeldung bei dem Internetdienst Stack Overflow mittels Facebook Connect, also mittels Log-in-Daten bei Facebook, betrachtet.
In diesem Beispiel ist Facebook sowohl der „Authorization Endpoint“, als auch der „Token Endpoint“. Der Internetdienst Stack Overflow hat sich im Vorfeld bei Facebook registriert, eine eindeutige Client ID erhalten und die benötigten Bibliotheken für die Kommunikation mit den Facebook APIs in seine Webanwendung integriert. In diesem Anwendungsbeispiel sind die schützenswerte Ressource der Account und die damit verbundenen persönlichen Informationen des Nutzers.
Nachfolgend sind die wesentlichen Protokollabläufe von OAuth 2.0 und ein Ausschnitt zu der zugehörigen HTTP-Kommunikation im Kontext des Anwendungsbeispiels aufgeführt:
1. Authorization Request: Für die Anmeldung bei dem Internetdienst Stack Overflow mittels Facebook-Account wird der Nutzer zuerst auf die Webanwendung von Facebook umgeleitet. Dem entsprechenden HTTP-Request wird die eindeutige ID der Webanwendung von Stack Overflow angehängt. Zusätzlich wird der OAuth-Schnittstelle von Facebook mitgeteilt, dass die Anwendung Zugriff auf die E-Mail-Adresse des Nutzers benötigt und wie der Nutzer nach einer erfolgreichen Authentifizierung und Autorisierung auf die Webanwendung von Stack Overflow zurückgeleitet werden soll. Für die Wiederherstellung eines Kommunikationszustandes und als Schutz vor CSRG-Angriffen wird zusätzlich ein Zustandsobjekt an den Request angehängt.
2. Authorization Code: Nach der erfolgreichen Authentifizierung und Autorisierung wird der Nutzer von der Facebook-Webanwendung auf die Webanwendung von Stack Overflow zurückgeleitet. An den entsprechenden HTTP-Request werden der Autorisierungscode und ein aktualisiertes Zustandsobjekt angehängt.
Mit dem Autorisierungscode kann anschließend ein Zugriffscode bei der Graph API von Facebook angefragt werden. Hierfür muss wieder die ID der Webanwendung von Stack Overflow an den HTTP-Request angehängt werden. Zusätzlich muss die gleiche Umleitungsadresse wie im ersten Schritt angegeben werden. Da der Zugriffscode nicht clientseitig vom Browser des Nutzers abgefragt wird, sondern serverseitig von der Webanwendung, muss ein spezielles Passwort zu der registrierten ID mit angegeben werden. Damit ein passender Zugriffscode erfolgreich angefragt werden kann, muss der vorher erhaltene Autorisierungscode mit an den Request angefügt werden.
HTTP/1.1 GET https://graph.facebook.com/v3.1/oauth/access_token? client_id=145044622175352 &redirect_uri=https://stackauth.com/auth/oauth2/facebook &client_secret<PASSWORD> &code=AQBxewj3LeZBc4NzUJv7FFd0fDfB2UM5jyfeX5C-ac2NaaxQMRxsfY03TDCcdaj…
3. Access Token: Nach der erfolgreichen Validierung des Autorisierungscodes wird der Webanwendung ein Zugriffscode in dem folgenden Format von der Graph API zur Verfügung gestellt: { “access_token”: “<ACCESS-TOKEN>“, “token_type”: “<TYPE>“, “expires_in”: <SECONDS-TIL-EXPIRATION> }
Mit dem Zugriffscode könnte die Webanwendung nun auf die freigegebenen Ressourcen der Graph API zu dem Nutzer zugreifen. In diesem Anwendungsbeispiel ist das lediglich die bei Facebook hinterlegte E-Mail-Adresse des Nutzers. Diese kann anschließend verwendet werden, um beispielsweise erstmalig einen neuen Account bei Stack Overflow zu dieser E-Mail-Adresse zu erstellen oder um den Log-in durchzuführen.
OAuth 2.0 ist ein Protokoll, das Identity Provider für die Autorisierung von Zugriffen auf schützenswerte Ressourcen über verschiedene Instanzen hinweg anbieten. Zusätzlich wird ein Protokoll für die Authentifizierung, wie Z. B. OpenID-Connect, ergänzt.
Author
Prof. Norbert Pohlmann
Publisher Name
Institut für Internet-Sicherheit – if(is)
Publisher Logo
OAuth 2.0 Prof. Dr. Norbert Pohlmann - Cyber-Sicherheitsexperten
