OAuth 2.0 – Ein Überblick
OAuth steht für Open Authorization und ermöglicht die standardisierte Autorisierung bzw. Absicherung von Schnittstellen. OAuth2.0 wurde 2012 von der IETF veröffentlicht.
Motivation
Traditionell wurden Schnittstellen über die HTTP Basic Authentifizierung abgesichert. Dabei werden bei jeder Anfrage von Client zu Server der Benutzername und das Passwort in Base64 codiert und übertragen. Dabei ist der Transport zwar über HTTPS verschlüsselt, allerdings sind Benutzername und Passwort beim Empfänger einfach als Base64 zu entschlüsseln. Dies führt zum einen dazu, dass für jede Anfrage erneut die Autorisierung durchgeführt werden muss und zum anderen zu einer Sicherheitslücke, da die HTTP Basic Authentifizierung über keinerlei Verschlüsselungsmöglichkeit beim Empfänger selbst verfügt.
Problemstellung HTTP Basic
Max möchte, dass seine SportTrackingApp in seinem Namen ein Posting auf Facebook durchführen darf.
- Max gibt seine Credentials für Facebook in die SportTrackingApp ein.
- Die SportTrackingApp loggt sich als Max bei Facebook ein und führt das Posting durch.
Problem: Die SportTrackingApp verfügt über die geheimen Facebook Credentials von Max. Dies wird in der Fachsprache auch als Passwort-Antipattern bezeichnet und stellt ein absolutes No-Go dar.
Wie sich zeigt, ist der Einsatz von HTTP Basic Authentifizierung mit einigen Nachteilen verbunden. Der Einsatz von Open Authorization mit OAuth2.0 ermöglicht es, genau diese Nachteile zu eliminieren und darüber hinaus einige weitere Vorteile zu schaffen.
Funktionsweise von Open Authorization mit OAuth2.0
Der Anwendungsfall: Max möchte, dass seine SportTrackingApp in seinem Namen ein Posting auf Facebook durchführen darf.
1) SportTrackingApp (Client) kontaktiert den Autorisierungsserver von Facebook und fordert die Berechtigung an, um einen Beitrag im Facebook (Ressource Server) für Max (Ressource Owner) erstellen zu dürfen.
2) Der Autorisierungsserver von Facebook kontaktiert Max (Ressource Owner) und erfordert einen Login.
3) Max (Ressource Owner) übermittelt die Logindaten an den Autorisierungsserver.
4) Der Autorisierungsserver validiert den Login und autorisiert Max als Ressource Owner, dabei wird das Token in der Datenbank des Autorisierungsserver abgespeichert.
5) Der Autorisierungsserver übermittelt das Token an die SportTrackingApp (Client).
6) SportTrackingApp (Client) übermittelt das Token und den Beitrag (Ressource) gemeinsam an Facebook (Ressource Server)
7) Facebook (Ressource Server) kontaktiert den Autorisierungsserver und überprüft somit die Gültigkeit des Tokens.
8) Im Erfolgsfall darf die SportTrackingApp (Client) den Beitrag (Ressource) auf Facebook (Ressource Server) für Max (Ressource Owner) erstellen.
Warum also OAuth2.0 nutzen?
Wie in obiger Funktionsweise beschrieben, kommen die Nachteile der HTTP Basic Authentifizierung nicht mehr zur Wirkung. Durch die Vereinheitlichung von Schnittstellen zum Austausch von Tokens führen Änderungen an Autorisierungsmerkmalen nicht unbedingt zur Anpassung an Schnittstellen, da die Authentifizierung von der Autorisierung entkoppelt ist. Die sonst schwergewichtige Autorisierung muss nicht in vollem Umfang in Anwendungen integriert werden, stattdessen kann die Clientimplementierung von OAuth2.0 in Kombination mit bestehenden Autorisierungsservern verwendet werden. Anwendungen können sich so auf ihre Kernfunktionalitäten konzentrieren und das große und komplexe Thema Autorisierung von der Anwendung entkoppeln. Um unterschiedlichen Anwendungsfällen gerecht zu werden, lassen sich in OAuth2.0 unterschiedliche Grant Types verwenden. Grant Types regeln, wie die Autorisierung genau ablaufen soll. Im obigen Beispiel wurde als Grant Type Implicit Grant verwendet. Dabei stellt der Autorisierungsserver direkt ein Token aus.
Bekannte OAuth 2.0 Anwendungen in der Praxis
- Amazon
Die Rolle von Open ID Connect
Wenn man sich mit der Thematik beschäftigt, selbst so ein Autorisierungssystem aufzusetzen, kommen einige Fragen auf. OAuth2.0 ist zwar ein Autorisierungsframework, bietet aber keine Authentifizierung an. Die Authentifizierung von Identitäten übernimmt an dieser Stelle dem Standard gemäß das Open ID Connect Protokoll. Das im Rahmen des Open ID Connect eingesetzte Token ist in der Regel ein typisches JSON Web Token (JWT). Ob also ein reines OAuth2.0 oder doch die Kombination mit Open ID Connect notwendig ist, hängt vom Anwendungsfall ab. In vielen Anwendungsfällen ist es nötig, nicht nur Zugang zu einer Ressource zu ermöglichen, sondern eine Authentifizierung durchzuführen. Dies ist insbesondere dann der Fall, wenn benutzerbezogene Zugriffsrechte oder Informationen verarbeitet werden sollen. Sobald also letzteres zutrifft, empfiehlt sich der Einsatz von Open ID Connect.
Was brauche ich, um die Open Authorization mit OAuth2.0 zu nutzen?
Generell muss unterschieden werden, welche Rolle die Anwendung im OAuth2.0 Kontext spielen soll. Für den gesamten OAuth2.0 Prozess wird ein OAuth2.0 Provider (Ressource-Server und ein Autorisierungsserver) benötigt, sowie ein OAuth2.0 Client, welcher auf die geschützten Ressourcen zugreifen möchte. Da in den meisten Anwendungsfällen nur eine der Schichten benötigt wird, ist es wichtig, zu verstehen, wo angesetzt werden muss.
Client
Der Client greift auf die geschützten Ressourcen zu. Im obigen Beispiel ist der Client die SportTrackingApp. Der Client hat die Aufgabe, die Berechtigung beim OAuth2.0 Server anzufragen und nach erfolgreicher Bestätigung eine Ressource an den OAuth2.0 Server inklusive Token zu übermitteln.
- Ein Client wird immer dann benötigt, wenn Open Authorization mit OAuth2.0 verwendet werden soll, um auf fremde Ressourcen zuzugreifen, welche hinter einem OAuth2.0 Autorisierungsserver liegen.
- Spring https://spring.io/guides/tutorials/spring-boot-oauth2/
- JAVA EE (siehe 4.) https://www.baeldung.com/java-ee-oauth2-implementation
Autorisierungsserver
Der Autorisierungsserver stellt dem Ressource Owner eine Login Maske bereit. Nach erfolgreichem Absenden des Logins vom Ressource Owner zum Autorisierungsserver überprüft dieser den Login und speichert das Token in seiner Datenbank. Anschließend übermittelt der Autorisierungsserver das Token an den Client. Wenn im späteren Verlauf der Ressourcenserver den Autorisierungsserver kontaktiert, muss dieser das Token validieren und einen Erfolg oder den Fehlschlag mitteilen.
- Ein eigener Autorisierungsserver wird immer dann benötigt, wenn das Usermanagement des Services an einen anderen Service (z.B. IAM-System) delegiert werden soll (Identity Federation)
- Spring https://docs.spring.io/spring-security-oauth2-boot/docs/2.2.x-SNAPSHOT/reference/html/boot-features-security-oauth2-authorization-server.html
- Spring mit Keycloak https://www.baeldung.com/keycloak-embedded-in-spring-boot-app
- JAVA EE (siehe 3.) https://www.baeldung.com/java-ee-oauth2-implementation
Ressourcenserver
Der Ressourcenserver empfängt vom Client ein Token sowie Content, welcher gespeichert werden soll. Das Token wird an den Autorisierungsserver zur Validierung übermittelt. Je nach dem, ob die Validierung durch den Autorisierungsserver erfolgreich verläuft oder nicht, wird der Content des Clients gespeichert.
- Ein eigener Ressource Server wird immer dann benötigt, wenn die eigenen Ressourcen über OAuth2.0 abgesichert werden sollen.
Zusammenfassend lässt sich festhalten, dass OAuth2.0 eine gute Möglichkeit bietet, die Autorisierung von Anwendungen für geschützte Ressourcen abzubilden. OAuth2.0 selbst besteht aus einem Autorisierungsserver für die Autorisierung eines Anforderers, sowie einem Ressourcenserver, welche die geschützten Daten beinhaltet und einem Client, welcher auf die Ressourcen zugreifen möchte. Durch die Vereinheitlichung von Schnittstelle und Login wird nicht nur die Benutzererfahrung verbessert, sondern auch der Aufwand für Anpassungen an Schnittstellen reduziert. Durch die flexible Integrationsfähigkeit mit bestehenden Autorisierungsservern / Ressourcenserver lassen sich kleine Anwendungen gut anbinden, ohne die Gesamtheit eines komplexen Autorisierungssystems bereitstellen zu müssen.
Je nach Anwendungsfall benötigt der Ressourcenserver weitere Informationen über den Anforderer. Dabei kommt Open ID Connect zum Einsatz. Open ID Connect schließt die Lücke von Open Authorization mit OAuth2.0 durch Hinzufügen der Authentifizierungskomponente. Dadurch ergibt sich die Möglichkeit, unterschiedliche Services mit demselben Autorisierungsserver zu unterstützen.
Mehr über Softwareentwicklung erfahren
Quellen
