Sommerloch? Von wegen!

Beim Treffen der Softwerkskammer Magdeburg am 25. August trafen sich Experten und Interessierte um einen spannenden und informativen Vortrag von Tobias Blaschke zum Thema "Authentifizierung in verteilten Systemen". Von vielen genutzt und mittlerweile etabliert in vielen Anwendungen, zeigte der Vortrag anhand eines interessanten Use Case, welche Möglichkeiten das Protokoll OAuth 2.0 und die Schnittstelle OpenID Connect Software- und Anwendungsentwickelnde bietet, um dem User mit einer Authentifizierung möglichst viele Anwendungen datenschutzkonform zu bieten.

Nachdem die Teilnehmenden sich in den Anwendungsfall einer Fitnessstudiokette, welche ihren Kunden eine Übersicht zu ihrem Trainingsfortschritt digital zur Verfügung stellt, hineinversetzen konnten und der dafür ausreichende "klassische" Authentifizierungsflow als Ausgangslage dargestellt wurde, so wurden anschließend weitere Problemstellungen zum Use Case eingeführt:

Wie kann bei einer Expansion des Geschäfts die Anwendung skalieren, ohne dabei unnötig Ressourcen zu beanspruchen? Dazu wurden verschiedene Lösungsmöglichkeiten wie SessionID und UserID in Verbindung mit JSON Web Token (JWT) aber auch deren Grenzen aufgezeigt. Das Fazit lautete hier: In einem verteilten System ohne public API ist eine zentrale Authentifikations-Instanz welche JWT-Tokens ausstellt hinreichend.

Welche Möglichkeiten aber sind vorhanden, wenn die Anwendung für Drittanwendungen geöffnet werden soll? Wie kan sichergestellt werden, dass die Drittanwendung auch nur auf die Daten zurückgreift, die die Nutzenden auch wirklich freigegeben haben? Hier kommt das Protokoll OAuth ins Spiel, mit dem die Nutzenden den Zugriff auf ihre Daten erlauben, die von einem anderen Dienst bereitgestellt werden, ohne geheime Details ihrer Zugangsberechtigungen preiszugeben.

Also einfach selbst drauf losbauen? Experte Tobais Blascke rät klar davon ab: Da Risiko und Kosten einer eigenen Implementation zu hoch sind, rät er zur Nutzung eines Identy Providers (wie bspw. Kayclock oder zertifizierte OpenID Provider als on-premise Lösung oder Okta oder OAuth als Services).

Unterscheiden sich die Anwendungsfälle, so unterscheiden sich auch die benötigten Authentifizierungsprozesse: Client Credentials Flows eignen sich für für Machine-2-Machine-Szenarien, Authorization Code Flow (PKCE) hingegen mehr für Web und Native Apps, Resource Owner Password Flow für IOT-Geräte mit eigenen Nutzer.

Was tun, wenn die Nutzenden sich über ihre bestehenden bspw. Google- oder GitHub-Konten anmelden wollen, also im sogenannten Single-Sing-On-Verfahren? Neben der Integration alle Provider für jede Komponente im Backend kann auch OAuth 2.0 durch OpenID Connect um die Endpoints für dynamic discovery für Google und Auth0, dynamic client registration und die Informationen über eingeloggten Nutzer per Token erweitert werden. Dies bietet die Vorteile, dass Account-Informationen automatisch aus dem ID-Token synchronisiert werden und sogenanntes Account Linking möglich ist.

In der anschließenden Diskussion wurden Erfahrungen mit der Anwendung von OAuth und OpenID Connect ausgetauscht, wobei hier durchaus unterschiedliche Sichtweisen unter den Teilnehmenden deutlich wurden.

Zusammengefassend bleibt von diesem spannenden Abend, dass Java Web Tokens den Austausch verifizierbarer Informationenerlaubt in verteilten Systemen erlauben, OAuth den Nutzenden ermöglicht den Zugriff auf die eigenen Daten für Drittanwendungen zu steuern (ohne Weitergabe des Passworts), OpenId Single-Sign-On ermöglicht und ein Besuch bei der Softwerkskammer sich immer wieder lohnt.