Zugriff auf Google API neue OAuth 2.0

[sh17]

Hätte doch einen eigenen Thread machen sollen. Ich meinte, ob jemand eine der Komponenten generell empfehlen kann, oder ob es Probleme gibt. Die TMS ist ja wesentlich günstiger und hat noch andere Schnittstellen, obwohl im Google-Kalender-Bereich ist sie nicht ganz so komplex.

Wg dem Key. Also ich schätz mal das ist nur in der Demo so gemacht. Ich habe es in meiner Probeimplementierung so gelöst, das ich den Zugriff auf die API über eine TWebBrowser-Fenster durchführe. Den Key kann man sich von Google als HTML-Titel zurückgeben lassen und kann ihn damit aus dem Browser-Fenster einfach auslesen. Muss der Anwender nichts kopieren.

[mjustin]

Zitat von sh17:

Wg dem Key. Also ich schätz mal das ist nur in der Demo so gemacht. Ich habe es in meiner Probeimplementierung so gelöst, das ich den Zugriff auf die API über eine TWebBrowser-Fenster durchführe. Den Key kann man sich von Google als HTML-Titel zurückgeben lassen und kann ihn damit aus dem Browser-Fenster einfach auslesen. Muss der Anwender nichts kopieren.

Ok, aber einen Browser braucht das Delphi Programm also für diesen Trick auf jeden Fall (wenn auch intern und unsichtbar). Aber wie ich jetzt in meinem Google Account sehe, wird das Demo Programm als berechtigter Benutzer permanent gespeichert unter der ID "Aston ToDo" hat es fortan Rechte auf meinen Google Calendar. Bei jedem weiteren Start ist die Berechtigung also schon vorhanden. Nach KISS würde ich die Delphi Anwendung dann ohne Webbrowser bauen, der Trick mit dem internen TWebbrowser Fenster könnte ja mal versperrt werden, während der normale (externe) Browser weiter funktioniert.

[sh17]

Ja, die Rechte müsstest Du der Demo (der ID) wieder entziehen.

Generell müsste man den Dialog zur Eingabe des Passwortes ja nur nachbilden. Dann sollte es auch ohne Browser klappen. Wenn das schon jemand hat, wäre ich durchaus daran interessiert.

[mjustin]

Zitat von sh17:

Generell müsste man den Dialog zur Eingabe des Passwortes ja nur nachbilden. Dann sollte es auch ohne Browser klappen.

Damit werden natürlich alle Sicherheitsvorteile unterlaufen, die eine browserbasierte Anmeldung mit OpenID hat:

Zitat:

Für den Nutzer ist es jedoch durch die OpenID-Architektur einfacher, eine Login-Seite auf Echtheit zu überprüfen, da er sich die sicherheitsrelevanten Merkmale nur einer einzigen Login-Seite merken muss, statt von mehreren, wie es ohne Single Sign-on der Fall ist. Die OpenID-Provider sorgen ebenfalls für mehr Sicherheit, indem sie etwa Cookies setzen, ein individuelles Bild zeigen, den HTTP-Referer mit der IP des Requesters vergleichen oder indem sie ein clientseitiges TLS-Zertifikat zur Authentifizierung nutzen. Insbesondere letzteres wird von immer mehr Providern unterstützt.

Natürlich kann man durch eine Bildschirmmeldung darauf hinweisen dass die eingegebenen Anmeldedaten ausschliesslich dazu verwendet werden, die Anwendung gegenüber dem Zieldienst (zum Beispiel Google Calendar) zu authentifzieren.

Aber nachprüfen kann man das als Anwender nicht, wogegen die browserbasierte Anmeldung wie im Demo von sync-components viel weniger Möglichkeiten eines Passwortklaus bietet.

Nachtrag: eine schematische Darstellung wie eine OpenID anmeldung funktioniert ist hier


How Does OpenID Work?

Nachdem man sich einmal angemeldet hat, braucht man für andere Consumer keine Anmeldung mehr, auch nicht wenn man den Browser schliesst oder den Rechner neu startet.

Auch im Demo von sync-components wird man nicht mehr auf die Loginseite des OpenID-Providers weitergeleitet, wenn man sich zuvor im normalen Browser (!) per OpenID angemeldet hat - sondern nur auf das "trust form", und auch das nur einmalig bzw. bis man die RefreshToken.ini löscht.

(p.s. habe gerade bemerkt dass es in diesem Thema nicht um OpenID sondern OAuth 2.0 geht ... knapp vorbei ist auch daneben

[Mavarik]

Ich nehme jetzt die TMS Komponenten...

Version 1.5 funktioniert!

Noch ein paar kleine Bugs, aber die werden erfahrungsgemäß vom TMS ja schnell behoben!

Mavarik