OAuth – Passwort IV

Open Authentication (vgl. OAuth) ist ein weiterer Standard, mit dem Informationen zwischen Diensten ausgetauscht werden können, ohne dass der Benutzer sein Passwort offenlegen muss. Es ist ein Standard, der von Entwicklern von Websites und Apps verwendet wird. OAuth ist anwendungszentriert. SAML verfolgt einen benutzerzentrierten Ansatz

Das OAuth Single Sign-On (vgl.: SSO) Protokoll bietet der Anwendung die Möglichkeit für einen sicheren designierten Zugriff. Es ermöglicht Benutzern in einer Organisation und/ oder Anwendung, sich mittels OAuth/OpenID Connect-Anbietern wie Microsoft Azure AD, AWS Cognito, Google Apps, Facebook usw. anzumelden und die relevanten Benutzerinformationen mit Unternehmensanwendungen zu teilen. Es nutzt einen tokenbasierten Autorisierungsmechanismus, um Benutzern über Unternehmensanwendungen hinweg Zugriff zu gewähren. Kurz gesagt, Benutzer können sich mit einer einzigen Anmeldeinformation bei mehreren Anwendungen und Diensten anmelden. Die Anzahl der durch den Benutzer vergebenen Passwörter wird damit eingeschränkt. Das hat zur Folge, dass die Angriffsfläche durch Benutzerpasswörter kleiner wird für Angreifer.

Funktionsweise

Protokoll Entities

• End-Benutzer/ Ressourcen Besitzer (vgl Resource Owner):
  Resource Owner ist der Endbenutzer, der auf die zu schützende Ressource zugreifen möchte.
• Informationsanbieter (vgl Resource Server):
  Die vom Endbenutzer angeforderte Information wird durch den Informationsanbieter (vgl. Ressourcenserver) zur Verfügung gestellt. Der Informationsanbieter verarbeitet Anfragen für den Zugriff auf/Aktualisierung der Informationen und leitet auch Authentifizierungsanforderungen an den Autorisierungsdienst weiter.
• Autorisierungsdienst (vgl Authorization Server):
  Dienst, der als Instanz Anmeldeanfragen entgegennimmt und verarbeitet. Dazu gehört die Überprüfung der Identität des Benutzers.

OAuth im „echten Leben“

Vor Autos für den US amerikanischen Markt haben verschiedene Schlüssel. Ein Schlüssel entriegelt zum Beispiel weder Kofferraum noch Handschuhfach. Das ist dazu gedacht, dass der Besitzer sein Auto einem Parkservice überlassen kann. Weder der Parkservice, noch irgendwer anderer, der den Schlüssel vom „Brett“ entwendet kann weder auf den Inhalt vom Kofferraum noch auf den Inhalt des Handschuhfaches zugreifen.

Genauso verhält es sich bei OAuth. Der End-Benutzer übergibt dem Informationsanbieter seinen Spezialschlüssel. Der Spezialschlüssel wird vom Autorisierungsdienst – Schliesssystem des Autos – nur für bestimmte Anwendungsfälle zugelassen.

OAuth Ablauf

• Zugriff auf eine Resource durch einen unbekannten Benutzer
• Eine Autorisierungsanfrage wird an den OAuth Dienstanbieter der Anwendung gesendet
• Der Benutzer wird aufgefordert sich anzumelden und die Anwendung wird durch die OAuth Dienstanbieter zugelassen
• Der Benutzer wird zu einer Login Seite weitergeleitet
• Der Benutzer wird durch den OAuth Dienstanbieter authentifiziert in dem ein Zugangscode (vgl. Schlüssel) an die Anwendung übermittelt wird.
• Mit diesem Code vom OAuth Dienstanbieter erstellt die Anwendung eine eigene Benutzer ID und einen individuellen Schlüssel für die Sitzung
• Der Server überprüft die Anforderung und gibt an die Anwendung einen Zugangsschlüssel heraus
• Mit diesem Zugangsschlüssel kann die Anwendung nun auf die Ressourcen, wie Benutzer Attribute, zugreifen
• Der Benutzer ist somit am gewünschten System angemeldet. Die Anwendung gibt entsprechend der Rollendefinition den entsprechenden Zugriff auf Informationen frei

Squenzdiagramm

Einsatz von OAuth

Anfangs habe ich behauptet, dass OAuth einen anwendungszentrierten Ansatz verfolgt. Das versuche ich jetzt zu erklären. Dazu ein kurzer Rückblick, es begann mit einer einfachen Authentifizierung mittels Benutzernamen und Passwort, um sich als Benutzer anzumelden. Diese Anmeldungsprozedur wurde immer stärker abgesichert und komplexer – wie auch die Passwörter. Schlussendlich hat jeder Benutzer eine Vielzahl von Passwörtern und jede Anwendung muss sich selbst um deren Verwaltung kümmern. Das bringt mehr Nachteile, als Vorteile mit sich und vor allem erzeugt das einen vermeidbaren Aufwand und somit Kosten. Mit OAuth ist es jetzt möglich die Anmeldeprozedur durch die selbst Anwendung abwickeln zu lassen indem sie definierte Verfahren und Schnittstellen – ja, das ist OAuth – verwendet. Nebeneffekt ist, wie bei SAML, dass durch die Einräumung einer Vertrauensstellung, keine eigene Benutzerverwaltung notwendig ist. Eine zentrale Benutzerverwaltung ist damit möglich. OAuth ist nicht auf einen speziellen Zweck ausgerichtet und damit frei in der Umsetzung. Wie bei SAML kann damit ein SSO umgesetzt werden. Ganz vereinfacht kann man sagen, dass SAML für die Authentifizierung steht und OAuth für die Autorisierung steht. Also, wer ist der Benutzer und was darf er machen. Aber in einem der nächsten Artikel gibt es genaueres.