Was sind die Unterschiede zwischen öffentlichen und vertraulichen Clients?

Wenn du Logto verwendest, um eine Anwendung zu erstellen, wirst du feststellen, dass es mehrere verschiedene Anwendungstypen zur Auswahl gibt, darunter Single Page Application (SPA), Native App und traditionelle Webanwendung. Intuitiv, vom Namen her, ist klar, dass eine Native App auf Betriebssystemen läuft, die üblicherweise auf Geräten wie Telefonen zu finden sind. Aber was genau sind SPA und traditionelle Webanwendung? Warum müssen wir zwischen diesen verschiedenen Arten von Apps unterscheiden? Dieser Artikel wird die Antworten auf diese Fragen offenlegen.

Bevor wir beginnen, müssen wir eine kurze Einführung in einige Konzepte geben.

Was ist OAuth?#

OAuth ist ein offener Standard für Zugriffserteilung, der typischerweise als eine Methode verwendet wird, damit Internetnutzer Websites oder Anwendungen den Zugriff auf ihre Informationen auf anderen Websites gewähren können, ohne ihre Passwörter anzugeben.

In den letzten zehn Jahren hat es sich allmählich zum Standardautorisierungsprozess entwickelt und wurde von den meisten Unternehmen wie Google, Meta, Microsoft und so weiter weitgehend akzeptiert. Die aktuell verwendete Version ist OAuth 2.0.

Im Kontext von OAuth wird die von uns erwähnte Anwendung als Client bezeichnet. Sie können Anfragen zu geschützten Ressourcen stellen, sofern sie die Genehmigung des Ressourceninhabers (normalerweise Endnutzer) erhalten haben.

Öffentliche Clients und vertrauliche Clients#

OAuth definiert zwei Clienttypen, basierend auf ihrer Fähigkeit, die Vertraulichkeit der Client-Anmeldedaten zu wahren.

Vertraulicher Client#

Ein Client, der in der Lage ist, die Vertraulichkeit seiner Anmeldedaten zu wahren (zum Beispiel ein Client, der auf einem sicheren Server mit eingeschränktem Zugriff auf die Anmeldedaten des Clients implementiert ist) oder einer, der in der Lage ist, eine sichere Client-Authentifizierung auf andere Weise durchzuführen.

Öffentlicher Client#

Ein Client, der nicht in der Lage ist, die Vertraulichkeit seiner Anmeldedaten zu wahren (zum Beispiel ein Client, der auf dem Gerät des Ressourceninhabers läuft, wie eine Native App oder eine Web-basierte App) und der auch nicht in der Lage ist, sich auf andere Weise sicher als Client zu authentifizieren.

SPA, Native App und traditionelle Webanwendung#

Mit dem zuvor erwähnten Hintergrundwissen lassen Sie uns ansehen, was SPA, Native App und traditionelle Webanwendung im Kontext von Logto bedeuten, sowie ob sie als öffentliche Clients oder vertrauliche Clients betrachtet werden.

SPA#

Der clientseitige Code einer SPA wird von einem Webserver heruntergeladen und im User-Agent (wie einem Webbrowser) des Ressourceninhabers auf ihrem Gerät ausgeführt. Die Protokolldaten und Anmeldedaten sind für den Ressourceninhaber leicht zugänglich (und oft sichtbar).

Native App#

Eine Native App wird auf dem Gerät des Ressourceninhabers installiert und ausgeführt. Die Protokolldaten und Anmeldedaten sind für den Ressourceninhaber zugänglich. Es wird allgemein angenommen, dass alle Client-Authentifizierungsdaten, die in der Anwendung enthalten sind, extrahiert werden können.

Traditionelle Webapp#

Eine traditionelle Webanwendung ist ein Client, der auf einem Webserver läuft. Der Ressourceninhaber greift auf den Client über eine HTML-Benutzeroberfläche zu, die im User-Agent auf ihrem Gerät dargestellt wird. Die Anmeldedaten des Clients sowie alle dem Client ausgegebenen Zugriffstoken werden auf dem Webserver gespeichert und sind dem Ressourceninhaber nicht ausgesetzt oder zugänglich.

So können wir deutlich sehen, dass SPA und Native App öffentliche Clients sind, während die traditionelle Webanwendung ein vertraulicher Client ist.

Du wirst feststellen, dass es beim Erstellen einer SPA oder Native App in Logto kein App-Geheimnis gibt, während eine traditionelle Webanwendung sowohl eine App-ID als auch ein App-Geheimnis hat. Dies liegt daran, dass das Geheimnis eines öffentlichen Clients nicht sicher garantiert werden kann.

Wie funktioniert ein Client im OAuth-Autorisierungsfluss?#

Beim Entwickeln von OAuth-Anwendungen ist der erste Schritt, den Client beim OAuth-Dienstanbieter zu registrieren. Die Registrierung des Clients erfordert die Bereitstellung von Details über die Anwendung, wie ihren Namen und die Redirect-URI. Dann generiert der OAuth-Dienstanbieter eine Client-ID und ein Client-Geheimnis, die als Anmeldedaten der Anwendung angesehen werden.

Die Client-ID wird als öffentliche Information betrachtet und während des OAuth-Prozesses mit dem Benutzer geteilt. Sie wird typischerweise in der Autorisierungs-URL einbezogen und ist für Endnutzer sichtbar.

Andererseits dient das Client-Geheimnis als Passwort für die Anwendung und muss geheim gehalten werden. Es wird im OAuth-Prozess verwendet, um den Autorisierungscode (vorausgesetzt, es handelt sich um den Autorisierungscodefluss) einzutauschen, um das Zugriffstoken zu erhalten. Die Existenz von Client-Geheimnissen stellt sicher, dass nur registrierte Anwendungen den Austausch von Zugriffstoken abschließen können.

Einführung von Proof Key for Code Exchange (PKCE)#

Wie bereits erwähnt, können die Client-Geheimnisse von öffentlichen Clients nicht sicher garantiert werden, und Angreifer können Client-Anmeldedaten erhalten und Clients fälschen, um auf geschützte Ressourcen zuzugreifen, was in keiner Situation akzeptabel ist.

PKCE (Proof Key for Code Exchange) löst dieses Problem, indem es zu Beginn jedes Autorisierungsflusses vorübergehend einen Code-Prüfer generiert, der lokal gespeichert und gehasht wird, um eine Code-Herausforderung zu generieren, die an den Autorisierungsserver gesendet wird. Der Code-Prüfer wird erneut an den Autorisierungsserver gesendet, wenn das Zugriffstoken ausgetauscht wird. Der Autorisierungsserver überprüft, ob der Code-Prüfer und die Code-Herausforderung übereinstimmen, was sicherstellt, dass der öffentliche Client nicht gefälscht wurde.

Der Code-Prüfer in PKCE funktioniert tatsächlich als dynamisches Client-Geheimnis. Seine Sicherheit wird durch die Unumkehrbarkeit des Hash-Algorithmus gewährleistet.

Zusammenfassung#

In diesem Artikel haben wir die Konzepte von vertraulichen Clients und öffentlichen Clients in OAuth diskutiert. Wir haben gelernt, dass vertrauliche Clients die Fähigkeit haben, Geheimnisse zu bewahren und sensible Informationen sicher zu speichern, während öffentliche Clients diese Fähigkeit nicht haben. Wir haben Beispiele für die beiden Typen von Clients untersucht, einschließlich traditioneller Webanwendungen, SPA und nativer Apps im Kontext von Logtos Produktpraktiken.

Wir haben auch den Registrierungsprozess des Clients in OAuth und die Rollen von Client-ID und Client-Geheimnis besprochen.

Darüber hinaus haben wir festgestellt, dass öffentliche Clients Einschränkungen beim sicheren Speichern von Client-Geheimnissen haben. Um diese Einschränkung zu überwinden, haben wir PKCE (Proof Key for Code Exchange) eingeführt, eine OAuth-Erweiterung, die es öffentlichen Clients ermöglicht, Autorisierungscodes sicher auszutauschen, ohne ein Client-Geheimnis zu benötigen.

Unser Produkt, Logto, ist eine umfassende CIAM-Lösung, die den bewährten Methoden der OAuth- und OIDC-Protokolle folgt, um Sicherheit in jeder Phase zu gewährleisten, einschließlich der Einführung von PKCE zum Schutz der Sicherheit öffentlicher Clients.