OAuth2 erste Schritte

[haentschman]

Hallöle...

Das haben wir verpennt...

Zitat:

Office 365:

Im September 2021 haben wir angekündigt, dass ab dem 1. Oktober 2022 die Standardauthentifizierung für Outlook- und EWS-, RPS-, POP-, IMAP- und EAS-Protokolle in Exchange Online deaktiviert wird. SMTP-Authentifizierung wird auch deaktiviert, wenn sie nicht verwendet wird.

Nun laufen einige Tools mit Abholung von Mails im Hintergrund über POP. Die funktionieren nicht mehr. Umstellung auf OAuth2 ist nötig. (CleverComponents)

Ich habe einiges gelesen, Beispiele ausprobiert (reichlich Fehler - try/error), dann erfolgreich authentifiziert.

Fragen:

1. Die Komponente macht immer eine Browserseite auf. Beim ersten Mal die Frage "Akzeptieren" ist ja noch ok. Aber mit jeder Authentifizierung ein neuer Reiter im Browser. Muß ich einen eigen HTTP bauen der den Request entgegennimmt? Kann man das "abschalten"?
2. Fehlermeldung beim Anmelden trotz "OAuth Authorization Successful!" (interner HTTP der Kompononente) lautet im Beispielprojekt "Im Projekt xxx.exe ist eine Exception der Klasse EclHttpError mit der Meldung 'invalid_client' aufgetreten."
3. Wie bekomme ich das hin, daß das Tool direkt die Mails abholen kann. Erste/einmalige Anmeldung ggf. per Browser ist ok.
4. Irgendwo habe ich gelesen, daß man den Token aus einer funktionierenden Anmeldung "wiederverwenden" kann und man sich damit wieder anmelden kann...
5. Ich mußte im Azure reichlich Einstellungen machen. (App-Registrierungen/Secret/Endpunkte) Wie macht das z.B. Thunderbird? Man kann doch keiner Oma Azure aufbürden?
6. Mit meinen "Zugangsdaten" konnte sich mein Kollege nicht anmelden... Die App ist im Azure imho global registriert. Er kannn sie in seinem Account auch sehen. Was ist falsch?
7. Redirekt:

Zitat:

Die URIs, die wir als Ziele akzeptieren, wenn wir nach der erfolgreichen Benutzerauthentifizierung Authentifizierungsantworten (Token) zurückgeben. Der Umleitungs-URI, den Sie in der Anforderung an den Anmeldeserver senden, muss mit dem hier aufgeführten übereinstimmen.

Die Adresse die mir angeboten wird nicht akzeptiert. "https://login.microsoftonline.com/common/oauth2/nativeclient"
Nur "http://localhost" funktioniert...mit immer neuen Reitern im Browser.

...also wie macht man es richtig.

PS: Die Dokumentationen wiedersprechen sich teilweise. Bsp: Scope: 'https://outlook.office.com/POP.AccessAsUser.All' oder 'wl.imap wl.offline_access' oder 'https://outlook.office365.com/.default'
Manche Beispiele funtionieren nicht...

PS: Alternativen: Indy oder REST brauchbar?

[Phoenix]

Puh. Vorneweg: OAuth ist nicht ohne. Im IT-Security Bereich gibt es einen running gag: "Man kann es einfach haben, oder sicher. Such Dir eins aus."

Der ganze "redirect-Tanz" über den default-Browser wird gemacht, damit a) der Benutzer seine Nutzerdaten (Benutzername, Passwort, 2FA Code etc.pp.) niemals an einen fremden Client (fremd aus Sicht des Identity Providers, im Falle von Azure also Fremd aus Sicht von Microsoft) gibt, und damit b) nach erfolgter Authentifizierung ein für den User individuelles Token möglichst sicher und möglichst nicht abfangbar an den Client übergeben wird.

Das bedeutet ein Client (in dem Fall Euer Tool das Mails abholen soll) öffnet eine Authentifizierungs-Anfrage über das OS, in dem es sagt: OS, öffne mal https://login.whatever.dings/ zum Anmelden. Dabei übergibt der Client dann die notwendigen Auth-Parameter (Client Id, benötigte Scopes, welche Tokens er gerne hätte, wohin der redirect nach erfolgter Authentifizierung passiert, eine Nonce, ggf. Zustandsinfos, optional schon ein vorausgefüllter Benutzername etc.).

Der Identity Provider prüft dann ob für der Client der redirect erlaubt ist, ob die Scopes in Ordnung sind etc. und wenn das alles passt meldet er dann den Benutzer bei sich an. Danach wird, je nach sogenanntem Grant Type, mit dem Redirect zur Anwendung entweder direkt die Tokens oder ein Authorization Code an den Client übergeben.

Der redirect kann entweder ein http-Call auf Localhost sein, den der Browser dann ausführt, ODER aber auch ein eigenes Protokoll. Bsp: mycustomapp://login - wenn Du hinter mycustomapp:// beim Betriebssystem Deine Anwendung registriert hast wird der Browser dem OS sagen starte mal die App hinter mycustomapp mit den Parametern aus der Url.

Meist zeigt ein Client nach dem Redirect eine Seite an die sagt: "Du Benutzer, das hat geklappt, Du bist jetzt hier eingeloggt. Mach bitte den Tab hier zu.". Oder er versucht sogar, den Tab selber mit JS zu schließen. Somit hast Du nicht zig Tabs offen.

Dass die Anwendungen lokal einen Http-Server aufmachen um den redirect (und damit die Tokens bzw. den Auth code) anzunehmen ist zwar gängig, ABER dazu müsstest Du eigentlich garantieren können das ein bestimmter Port auf allen Maschinen auf denen das laufen soll frei ist. Zuverlässiger ist da dann entweder die custom app-Registrierung oder aber ein zentraler Server im Internet auf den redirected wird, und mit dem der Client im Hintergrund dann die Daten austauscht (das macht z.B. Postman so). Ich würde hier am ehesten auf Custom App Registrierung gehen. Ist deutlich zuverlässiger und erfordert nicht den Betrieb eines Dienstes im Internet zum Datenaustausch. Erfordert allerdings ein bisschen mehr Code, weil das OS ja eine zweite Instanz Deines Programmes öffnet durch den Link, und die muss dann die erste finden und ihr mittels Inter-Prozess-Kommunikation die Daten durchreichen.

Wenn der Client gleich die Tokens bekommt ist er damit auch Authentifiziert und kann damit arbeiten. Bekommt er einen Auth-Code muss er den jetzt nochmal mit seinem Client-Secret und ggf. einem PKCE-Code Verifier beim IdP gegen das eigentliche Token austauschen.

Damit kommen wir zu den Token-Arten. Ein Access-Token ist üblicherweise nur eine gewisse Zeit lang gültig. Je nach Dienst wenige Minuten bis zu ein paar Stunden. Das macht man, da ein Token das abgefangen wird so lange wie es eben gültig ist sozusagen als Generalschlüssel funktioniert, und ein Angreifer damit jede Menge Schindluder treiben kann. Damit Du nicht jedesmal den Benutzer für eine erneute Anmeldung fragen musst, wenn das Access-Token abläuft, gibt es sogenannte Refresh-Tokens. Das hebt sich der Client in einem möglichst sicheren Ort auf. Wenn das Access-Token abläuft kann der Client mit dem Refresh-Token zum IdP gehen und sich dort ein neues, frisches Access-Token abholen. In aller Regel sind die Refresh-Tokens nur einmal gültig und der Client bekommt mit dem Access-Token auch gleich ein neues Refresh-Token zurück das er dann beim nächsten Mal benutzen soll.

Also konkret zu Deinen Fragen:
1.) Frage nach einen Refresh-Token und merke ihn Dir. Damit musst Du einen Benutzer nur genau einmal anmelden. (Auch Refresh-Tokens laufen irgendwann mal ab, aber meist leben die sehr lange bzw. können sehr lange erneuert werden, z.B. ein ganzes Jahr).
2.) Da kann ich Dir nix zu sagen, ich kenne die Komponenten nicht, nur das OAuth-Protokoll
3.) Auch hier wieder: Benutze das abgelegte Refresh-Token um einen frischen Access-Token zu holen, mit dem solltest Du dann immer wieder Mails holen können.
4.) Ja, Refresh-Token
5.) Das machst Du als Anbieter Deines Clients. Wenn die Oma Thunderbird selber baut und vertreibt, braucht sie Azure. Ansonsten macht das Mozilla für ihren eignen Thunderbird-Client bei sich einmal und dann ist gut.
6.) Was meinst Du mit Deinen Zugangsdaten? Meinst Du die Client-Infos oder meinst Du wirklich Benutzername/Kennwort?
7.) An den IdP selber zurück redirecten bringt Dir ja nix, weil dann die Antwort für die Tokens ja nie in Deinem Client ankommt. Wie gesagt, der Redirect geht (entweder direkt oder indirekt) zu Deinem Client um die Auth-Antwort des IdP an Deinen Client zu übergeben. http://localhost:port/ geht, ist aber unsicher weil a) jemand anderes auf dem Port einen listener aufmachen kann und damit die Tokens abfangen kann und b) sollte alles was Auth betrifft eh immer https sein und das geht dann nur mit Self-Signed Zertifikaten und das ist ehrlich gesagt ein großes Geschiss. Indirekt über einen Service im Internet ist aufwändig (wie gesagt, Postman macht das so, aber die haben auch viel Kohle . Custom-App Registration ist vermutlich der beste und sicherste Weg. Und ja, die Url muss dem IdP vorher bekannt sein, weil sonst könnte ja jemand der Deine Client-Id kennt (die wird offen in der Url übertragen, ist also nicht sicher), auch einen Login machen und sagen: "Du IdP, Ich bin [Client Id Deines Tool], melde mal den Benutzer für mich an und schicke den Token an https://boeser-token-klauer.de/login". Und dann liest der Angreifer locker flockig alle Mails. Das willst Du nicht
Deswegen musst Du als Client-Anbieter dem IdP vorher sagen, wohin er die Tokens schicken darf.

Und ja, die Doku zu Azure und OWA etc. pp. ist.. sagen wir mal sehr unglücklich bis gar nicht versioniert. Die Daten da ändern sich alle viertel bis halbe Jahre (das Web bewegt sich leider superschnell), und ältere Texte werden - leider - wenn sich was ändert nicht nochmal geprüft und dazu geschrieben, Du der Scope da hat sich in den letzten 3 Jahren fünfmal geändert, der aktuelle ist xyz.

[haentschman]

Danke für deine ausführliche Antwort...

Da taste ich mich mal Stück für Stück durch.

Zur Vervollständigung:
Das Tool ist ein internes Tool was alleinig auf einer VM läuft.

[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.

[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