OAuth2 erste Schritte

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

[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