Oauth2 zum Anfangen

Alle Fragen zur Netzwerkkommunikation
Antworten
Eliot
Beiträge: 2
Registriert: Mi 22. Feb 2023, 11:05
OS, Lazarus, FPC: Winux (L 2.2.0 FPC 3.2.0)
CPU-Target: 64Bit

Oauth2 zum Anfangen

Beitrag von Eliot »

Hallo, ich bin auf der Suche nach einem kleinen Oauth2.0 Beispiel, das einem den Einstieg erleichtert.
Sollte erst mal nur ein Form sein mit zwei Eingabefeldern (Edit1 + Edit2) und einem TButton.

Als Bestätigung des Vorgangs dann einen TRadioButton?

Kennt jemand hier so etwas?
Dateianhänge
Oauth2_Lazarus.png
Oauth2_Lazarus.png (24.61 KiB) 1239 mal betrachtet

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Oauth2 zum Anfangen

Beitrag von Warf »

Was genau willst du denn machen? OAuth spezifiziert die Kommunikation zwischen einem Dienst (Relying Party oder RP) und einem OAuth Provider (OP), über HTTP.

Im Grunde läuft das so ab: Die RP möchte gerne Zugang zu irgendwelchen Resourcen im Namen des Nutzers haben, also eine Authorisierung für den Nutzer beim OP bekommen (daher der Name OAuth). Darauf hin wird der Nutzer an eine HTTP URL weitergeleitet die die Anfrage der RP als Parameter eingebettet hat.
Dann interagiert der Nutzer mit dem OP. Dies ist außerhalb der OAuth spec und ist ganz von dem OP abbhängig sein. Es kann ein Weblogin sein, weiterleitung an eine App, auto login durch cookies, multifaktor, single faktor, wie auch immer. Das ist in OAuth nicht spezifiziert.
Wenn der OP dann den Nutzer Authentisiert hat, und seine Zustimmung für die Authorisierung bekommen hat, wird der Nutzer über an die so gennante Redirect URI weitergeleitet, ein HTTP Link, der die Antwort des OP mit einem entsprechenden Authorisierungstoken (oder Fehlermeldung falls was nicht geklappt hat) enthält.

So die Frage ist was möchtest du machen eine RP schreiben, also einen server der über OAuth eine Authorisierung anfordert, oder einen OP um den Nutzer solche Authorisierungen bereitstellen zu lassen? Es ist vor allem grundsätzlich ein Web verfahren, also bin ich nicht so sicher was du da mit einer Desktopanwendung machen willst (Wobei natürlich auch lokale Apps mit Deeplinks benutzt werden können, siehe SIOP)

Eliot
Beiträge: 2
Registriert: Mi 22. Feb 2023, 11:05
OS, Lazarus, FPC: Winux (L 2.2.0 FPC 3.2.0)
CPU-Target: 64Bit

Re: Oauth2 zum Anfangen

Beitrag von Eliot »

Hallo @warf, vielen Dank für deine Antwort.
Also ich dachte erst mal an einen Login mit Hilfe des "Consumer Key's" und des "Consumer Secret's", um einen "Token" (Bearer) zu bekommen. Mit diesem Token kann man dann die s.g. "Endpoints" abfragen. (REST)
Also wohl ersteres aus deiner Antwort. Einen RP schreiben...

Als weitere Ausbaustufe dachte ich Wetterdaten anzuzapfen und als Verzeichnißbaum darzustellen. Die URL zum z. B. Wetterdienst ist vorhanden.
Zuletzt geändert von Eliot am Mo 27. Feb 2023, 10:18, insgesamt 1-mal geändert.

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: Oauth2 zum Anfangen

Beitrag von theo »

Ich habe kaum Ahnung davon, aber nur falls das nicht klar sein sollte:
Es gibt durchaus Units zu dem Thema in den FPC-Sourcen:

https://gitlab.com/freepascal.org/fpc/s ... eb/src/jwt
https://gitlab.com/freepascal.org/fpc/s ... /googleapi

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Oauth2 zum Anfangen

Beitrag von Warf »

Ok, das macht das relativ einfach. Das ding ist, OAuth ist nich dafür gedacht das man sich in Desktopanwendungen anmeldet, sondern in einem Browser. Der Flow ist wie folgt: Du rufst den Browser des Nutzers auf mit der Addresse des OAuth Providers, indem du deine anfrage kodierst (Linebreaks nur zur besseren lesbarkeit, im request ist das alles eine Zeile, # sind kommentare):

Code: Alles auswählen

https://outh.provider.com/authorize?
    response_type=token # Oder code
    &scope=scopes # Falls von OP benötigt hier die scopes mit leerzeichen getrennt
    &client_id=cl_id # Die vorher registrierte ClientID
    &state=af0ifjsldkj # Beliebiger wert um Response wieder zu erkennen, nicht notwendig
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb # deine client redirect URI
Dann macht der Nutzer auf der Website was auch immer nötig ist um sich anzumelden, und danach wird der Browser an die Redirect URI weitergeleitet, mit den entsprechenden Infos in der URI.

Kurz zu den parametern oben: response_type ist für die art des Flows wichtig. "code" ist der Code Flow, da bekommst du kein Token direkt sondern einen Code den du für ein Token einlösen kannst. Im gegensatz dazu wenn der "token" flow verwendet wird, bekommst du das token direkt und hast nicht den extra Schritt. Der Grund warum normalerweise "code" verwendet wird ist, damit nicht irgendwelche malware auf dem Rechner oder unsichere Browserplugins oder ähnliches das Token abgreifen können, denn nur der Server der RP die ein bestimmtes Passwort hat kann den code einlösen. Da du das aber in einer lokalen Anwendung haben willst ist das herzlichst egal, da du dann immer von Lokaler Malware angreifbar bist, von daher kannst du da "token" verwenden, um das ganze einfacher zu machen.

Das nächste sind die scopes, darüber gibst du an worauf du gerne Zugriff hast. Welche scopes erlaubt sind und was beinhalten kommt auf den OP an und musst du dort entsprechend nachschauen.

client_id ist ein string mit dem der OP deine Anwendung wieder erkennt. Normalerweise ist OAuth dafür gedacht das du deine Anwendung vorher registrierst, dann bekommst du eine client_id, die du jedes mal mitsenden musst damit der OP weis für wen er die Daten bereitstellt.

state ist einfach beliebige daten die du senden kannst die in der Antwort wieder zurückgesendet werden. Ähnlich zu cookies um eine bestimmte Session wieder zu finden. Da du allerdings lokal läufst, und nur ein Request gleichzeitig haben kannst, ist dir das relativ egal und kannst du weglassen.

Zum schluss noch die redirect_uri, die ist das wichtigste, die gibt an wo der OP den Browser mit der Antwort hinschicken soll. Das muss eine URI sein die du in deinem Programm abfangen kannst. Eine möglichkeit hierfür wäre ein so genannter Deeplink, dabei registrierst du eine URL, sodass dein Programm aufgerufen wird statt der einer website. Eventuell hast du das schonmal gesehen, z.B. eMail clients registrieren "mailto" sodass links zu "mailto:addresse" dann keine website öffnen, sondern das eMail program mit einer neuen Mail an die addresse.
Das gleiche kannst du auch für deine anwendung machen, z.B. "myapp" registrieren, und als redirect uri dann "myapp:resp" angeben, dann wird beim redirect dein Programm aufgerufen und die OAuth Daten (als URI der form myapp:resp?OAUTHQuery) übergeben.

Alternativ kannst du natürlich auch einfach einen lokalen webserver aufsetzen und als redirect uri "http://localhost:port" übergeben, und dann darüber das HTTP request handlen und die daten auslesen

Antworten