OAuth2 erste Schritte

[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

[himitsu]

Wenn ich es richtig verstanden hab, dann
* bekommt man vom OAuth-Provider eine URL für's "externe" Einloggen
* * die wird/kann z.B. im Browser geöffnet werden (müsste auch im TWebBrowser möglich sein) ... sollte/darf halt nicht "direkt" in deinem Programm gemacht werden, damit die Anmeldung von dir unabhängig ist
* * da wiederrum könnte über den Provider z.B. auch 2FA über anderes Gerät eingeholt werden
* als Rückgabe gibt man dem auch wieder eine URL mit (offiziell hast du ja keinen direkten Zugriff auf die aufgerufene Webseite und was sie zurück bekommt)
* * das kann z.B. eine öffentliche Webseite/Server von dir sein, oder auch auf localhost, an die dann das Token übergeben wird, nach erfolgreicher Anmeldung
* und mit dem Token kannst du dann eine Weile lang was machen

[Phoenix]

So, jetzt hab ich da nochmal drüber nachgedacht.

Es gibt für solche Fälle, also die initiale Auth für Hintergrund-Dienste, aber auch um Geräte einzuloggen die keine gute/direkte Eingabemöglichkeit für die Benutzer-Credentials anbieten, noch weitere Grant-Types (flows) die man verwenden kann.

Das eine ist der Device-Code Flow. Das benutzt z.B. die Amazon Prime Video App auf Samsung TVs oder auch die Youtube-App auf Samsung TVs. Die Anwendung kommuniziert zuerst mit dem IdP und generiert einen Device Code. Meist 5-Stellig Alphanumerisch. Den und die Url zum IdP zeit die Anwendung dann dem User an. Meist gibts noch einen QR-Code der den Code schon direkt drin hat dazu.

Der Benutzer geht dann - auf einem anderen Gerät, z.B. auf seinem Smartphone - auf diese Login-Seite bei Amazon bzw. Youtube oder öffnet den QR-Code (dahinter steckt die URL meist schon mit dem Code). Er meldet sich dort an, gibt den Device-Code ein wenn er nicht schon über den QR-Code reingekommen ist, und währenddessen pollt die Anwendung immer mal wieder den IdP und fragt: Hat er sich schon angemeldet? Hat er sich schon angemeldet? Wenn ja, bekommt sie dann die Tokens zurück.

Das kann man freilich auch direkt auf dem Server/der VM so machen. Die Anwendung startet den Device Code flow und öffnet die URL mit dem Code gleich im lokalen Browser. Der Rück-Kanal ist dann aber eben nicht das aufmachen eines lokalen Webservers oder das registrieren eines eigenen Protokolls, sondern eben das pollen beim IdP.

Die zweite Methode ist CIBA (Client initiated backchannel authentication), aber damit habe ich mich ehrlich gesagt noch nicht weiter beschäftigt. https://openid.net/specs/openid-clie...1_0-final.html