OAuth2 erste Schritte

[Bbommel]

Hätte ich mal so eine super Erklärung gehabt wie die von Phoenix als ich angefangen habe, mich mit OAuth2 beschäftigen zu müssen, das hätte mir ein paar Knoten im Hirn erspart.

Eine Ergänzung aber noch, um das Ganze noch etwas komplizierter zu machen: es gibt bei OAuth2 unterschiedliche "Flows", also unterschiedliche Wege, auf denen man ein Token bekommen kann, wobei nicht immer alle zur Verfügung stehen müssen. Was Phoenix beschreibt, ist im Wesentlichen der "Authorization Code Flow". Den benutzt man normalerweise in interaktiven Anwendungen. Also: der Benutzer klickt irgendwo drauf oder startet eine Anwendung, ein Fenster geht auf, in dem er sich anmelden muss, und die Anwendung bekommt dann irgendwann das Token, wie von Phoenix beschrieben.

Daneben gibt es auch den "Client Credential Flow". Der ist eher für die Server-zu-Server-Kommunikation gedacht. Zwei Anwendungen unterhalten sich also im Hintergrund und tauschen Daten aus. Microsoft dazu. Das Ganze ist etwas "einfacher", weil es ohne die Interaktion mit dem Browser abläuft (logisch). Da du geschrieben hast, dass deine Anwendung die Mail eigentlich im Hintergrund abholen soll, könnte das genau so ein Fall sein, wenn die Anwendung nicht doch unterschiedliche Konten von unterschiedlichen Benutzern abfragen soll. Auch für Exchange/IMAP/POP scheint Microsoft den Client-Credential-Flow zur Verfügung zu stellen. Habe ich aber selber bisher nicht genutzt/getestet.

Ich hoffe, ich habe jetzt nicht zu mehr Verwirrung beigetragen, aber dieses "die Anwendung macht da was im Hintergrund" ist dafür schon ein entscheidendes Stichwort gewesen.

[Phoenix]

Da hat Bbommel recht. Wenn es ein Hintrgrund-Dienst ist, der eigentlich keinen Benutzer am Bildschirm erfordert, dann wäre client credentials vermutlich der richtige Grant Type (ja, "Flow" stand dazu zwar mal in Spec, aber der eigentlich korrekte Begriff ist Grant Type).

Das Ding ist dann aber, dass der client ja Zugriff auf Nutzerdaten (also deren Emails) haben soll. Dazu ist dann auf Seiten von Microsoft/Azure noch ein sogenannter Admin-Consent notwendig, mit dem der Admin bzw. alternativ auch der User dann sagt, Ja: Dieses Stück Software da darf auf meine Mails zugreifen.

[haentschman]

Danke...

Zitat:

Dazu ist dann auf Seiten von Microsoft/Azure noch ein sogenannter Admin-Consent notwendig, mit dem der Admin bzw. alternativ auch der User dann sagt, Ja: Dieses Stück Software da darf auf meine Mails zugreifen.

...ist freigegeben.

Zitat:

6.) Was meinst Du mit Deinen Zugangsdaten? Meinst Du die Client-Infos

Die Clientinfos.


Das Ganze riecht nach einer Kapselung in einer Klasse...

[gubbe]

Wow, das ist ja mal eine ausführliche und verständliche Beschreibung von Phoenix. Danke, sehr interessant.

Zur Diskussion ein paar Anmerkungen:

Lokal einen Webserver auf localhost zu starten, um per Redirect vom Server (dem Identity Provider) den Code zu empfangen ist tatsächlich gängig. Das Problem, dass man vorher den lokalen Port kennen muss, kann man aber lösen. Üblicherweise sucht man lokal nach einem freien Port und startet den Webserver erst dann. Die Redirect-URL übergibt man mit dem Port. Auf dem Server muss es dann natürlich möglich sein, bei der Registrierung der Client-Applikation den Port als Wildcard zu definieren oder mehrere URLs mit einer Auswahl an möglichen Ports anzugeben. Wenn man den Webserver vorher startet, kann auch kein anderes Programm den Port belegen.

Für Localhost braucht man kein Zertfikat. Der Redirect im Browser passiert ja nur lokal direkt an localhost. Das bleibt alles auf dem Client und kann folglich nicht von Dritten abgehört werden. Ausnahme wäre ein lokales Programm, aber das hätte dann ja auch ganz andere Möglichkeiten, z.B. die Tastatureingaben mitzulesen. Die Gefahr, dass sich eine andere Applikation dazwischen drängelt, hättest du ja auch bei einem Custom-Protocol, denn das ist nur ein Registry-Eintrag, den eine andere Applikation überschreiben könnte.

Wenn einen stört, dass für jedes Login ein neues Tab im Browser aufgemacht wird, kann man das Login im Prinzip auch im eigenen Programm in einem eingebetteten Browser abhandeln. Das entspricht nicht den offiziellen Empfehlungen, wird aber trotzdem häufig so gemacht, auch von Microsoft. Die Nachteile sind, dass der Benutzer ohne Adressleiste nicht sieht, wo er seine Daten eingibt, deiner Applikation also unbedingt vertrauen muss und dass er sich neu anmelden muss, auch wenn er in seinem Standard-Browser ggf. schon angemeldet war.

Zum Thema Hintergrund-Dienst: Da kenne ich die APIs von Microsoft jetzt nicht, aber im Prinzip gibt es dafür bei OAuth2 die Offline-Tokens. Das sind Refresh-Tokens mit einer sehr langen Laufzeit. Wenn man den Dienst einmal über den Browser angemeldet hat, speichert er das Token und kann es immer wieder verwenden, um es gegen ein aktuelles Access-Token einzutauschen.

Was mich interessieren würde, ist das von dir erwähnte Verfahren bei Postman. Ich kenne Postman jetzt nur als Tool zum Debuggen von APIs. Wo könnte ich denn hier das beschriebene Verfahren finden, dass der Redirect an einen Server geht und der Client die Daten mit diesem austauscht?

[Phoenix]

Zitat von gubbe:

Wenn einen stört, dass für jedes Login ein neues Tab im Browser aufgemacht wird, kann man das Login im Prinzip auch im eigenen Programm in einem eingebetteten Browser abhandeln. Das entspricht nicht den offiziellen Empfehlungen, wird aber trotzdem häufig so gemacht, auch von Microsoft. Die Nachteile sind, dass der Benutzer ohne Adressleiste nicht sieht, wo er seine Daten eingibt, deiner Applikation also unbedingt vertrauen muss und dass er sich neu anmelden muss, auch wenn er in seinem Standard-Browser ggf. schon angemeldet war.

Auch ein Passwort-Manager greift in den Embedded Browsern nicht. Google z.B. investiert auch jede Menge Zeit und Geld darin, dass die Google-Anmeldeseite bewusst nicht in embedded Browsern funktioniert. Auch das steht in der Spec: Ein IdP-Anbieter sollte verhindern das die Login-Seite in solchen Embedded Browsern funktioniert.

Zitat von gubbe:

Was mich interessieren würde, ist das von dir erwähnte Verfahren bei Postman. Ich kenne Postman jetzt nur als Tool zum Debuggen von APIs. Wo könnte ich denn hier das beschriebene Verfahren finden, dass der Redirect an einen Server geht und der Client die Daten mit diesem austauscht?

Wenn Du eine mit OAuth abgesicherte API testen willst, kannst Du beim Request (oder auf der Collection) bei Authorization einstellen das Du OAuth 2.0 haben willst.
Dann kannst Du bei der Konfiguration weiter unten sagen: Authorize using Browser und dann wird die Callback-Url automatisch auf "https://oauth.pstmn.io/v1/callback" gesetzt.
Auf den Postman-Server verbindet sich Deine Postman-Instanz dann im Hintergrund und bekommt der dann die Daten, die mittels des Browsers an den pstmn.io-Server übertragen werden. Da das natürlich viele Leute gleichzeitig machen muss der Server dann rausfinden welche Postman-Instanz welche Callback-Daten bekommt, das dürfte sehr wahrscheinlich anhand des State-Parameters passieren.

PostmanAuth.png

[gubbe]

Zitat von Phoenix:

Auch ein Passwort-Manager greift in den Embedded Browsern nicht. Google z.B. investiert auch jede Menge Zeit und Geld darin, dass die Google-Anmeldeseite bewusst nicht in embedded Browsern funktioniert. Auch das steht in der Spec: Ein IdP-Anbieter sollte verhindern das die Login-Seite in solchen Embedded Browsern funktioniert.

Ja genau, die fehlende Möglichkeit die Login-Daten zu speichern fällt dann auch negativ auf. Aber es kommt ja immer auf den Anwendungsfall an. Dass Google es verhindern möchte, ist absolut verständlich, denn die Benutzer sollen eben nicht dazu animiert werden, ihre Google-Anmeldedaten in irgendwelchen Apps einzugegen, wo sie dann abgegriffen werden können. Soweit ich weiß, ist aber die einzige Gegenmaßnahme die Auswertung des Useragents, was "ganz schlaue Leute" dann natürlich wieder umgehen können, jedenfalls habe ich schon entsprechende Foren-Diskussionen gesehen. Das Risiko ist dann zurecht, dass Google seine Erkennung verbessert und die Applikation aussperrt. Bei einer Applikation mit breiter Benutzerbasis sollte man sich an die Vorgaben halten. Wenn es aber wie hier um eine interne Applikation und nicht um Google geht, muss man es abwägen. Microsoft zeigt selbst z.B. für die Anmeldung in Outlook einen eingebetteten Browser an.

Aber das Problem mit den vielen Browser-Tabs nach dem Login sollte in diesem Fall eigentlich gar nicht auftreten. Eine einmalige Anmeldung sollte je nachdem wie lange das Refresh-Token gültig ist, genügen.

Zitat von Phoenix:

Wenn Du eine mit OAuth abgesicherte API testen willst, kannst Du beim Request (oder auf der Collection) bei Authorization einstellen das Du OAuth 2.0 haben willst.
Dann kannst Du bei der Konfiguration weiter unten sagen: Authorize using Browser und dann wird die Callback-Url automatisch auf "https://oauth.pstmn.io/v1/callback" gesetzt.
Auf den Postman-Server verbindet sich Deine Postman-Instanz dann im Hintergrund und bekommt der dann die Daten, die mittels des Browsers an den pstmn.io-Server übertragen werden. Da das natürlich viele Leute gleichzeitig machen muss der Server dann rausfinden welche Postman-Instanz welche Callback-Daten bekommt, das dürfte sehr wahrscheinlich anhand des State-Parameters passieren.

Danke! Das schaue ich mir mal genauer an. Mir leuchtet nicht so recht ein, warum sie das so machen. Eine offizielle Lösung für das Anbinden von lokalen Applikationen ist das jedenfalls nicht. Vielleicht geht es hier eher um das Testen von Web-Applikationen und ist eben ein Workaround, damit man diese auch mit einem lokal installierten Postman testen kann?

[Phoenix]

Vermutlich. Ist auch eher für manuelle Tests gedacht. Für automatisierte Tests kann man ja auch keine Auth verwenden die einen Benutzer erfordert

[gubbe]

Zitat von Phoenix:

Wenn Du eine mit OAuth abgesicherte API testen willst, kannst Du beim Request (oder auf der Collection) bei Authorization einstellen das Du OAuth 2.0 haben willst.
Dann kannst Du bei der Konfiguration weiter unten sagen: Authorize using Browser und dann wird die Callback-Url automatisch auf "https://oauth.pstmn.io/v1/callback" gesetzt.
Auf den Postman-Server verbindet sich Deine Postman-Instanz dann im Hintergrund und bekommt der dann die Daten, die mittels des Browsers an den pstmn.io-Server übertragen werden. Da das natürlich viele Leute gleichzeitig machen muss der Server dann rausfinden welche Postman-Instanz welche Callback-Daten bekommt, das dürfte sehr wahrscheinlich anhand des State-Parameters passieren.

Das habe ich jetzt mal getestet. Die obige URL leitet einfach um auf postman://app/oauth2/callback. Das ist also letztlich nur eine Variante des Vorgehens mit dem lokal registrierten Protokoll, das du ja auch beschrieben hattest. Bei Postman steht auch in der Doku dazu, dass man sicherstellen muss, dass Popups für die URL erlaubt sind. Das könnte also auch ein Nachteil der Protokoll-Variante sein, dass der Browser Popups blockiert und der Benutzer es somit gar nicht mitbekommt.
Auf der Umleitungsseite steht auch "A new window should open directing you back to the Postman app. If nothing happens, check to make sure your browser allows pop-ups."

Schade, ich hatte kurz die Hoffnung, es gäbe noch eine andere Möglichkeit als den Webserver auf localhost oder das registrierte Protokoll.

[Thomasl]

Ich habe es mit SMTP und OAUTH2 mit Google und Microsoft ans laufen bekommen.
Nur mit Indy/TLS1.3 und einmalig Browserfenster.
Wenn man den Refrehkey zum anderen PC Kopiert geht es da auch ohne Browser.


Einmalig:
Lokal http Server erstellen.
Mit ShellExecute den Browser mit Url und Parameter öffen (optional S256 Signatur)
Der Browser schickt einen Code zum lokalen http server
Mit diesem Code kann man sich den Refreshkey holen

Regelmäßig:
Mit dem Refreshkey kann man sich den Accesskey holen. Dieser ist eine Stunde gültig

Mit dem Accesskey kann man dann Smtp/Pop/Imap etc.