NEWS
OAuth für Adapter
-
@codierknecht sagte in OAuth für Adapter:
Gibt es für Adapter ein allgemeingültiges Verfahren zur Verwendung von OAuth?
Ja und Nein. Es ergibt sich ja aus der Spezifikation von OAuth wie man das Handhaben muss. Für Adapter könnte man lediglich einen Standard Rückmeldekanal festlegen der dafür verwendet werden soll.
Der Netatmo Adapter verwendet OAuth. Dort wurde ein Kostenloses Hosting verwendet, von dem aber niemand wusste und der Entwickler hatte sich zurück gezogen. Nachdem das Hosting abgeschalten wurde funktionierte der Adapter nicht mehr. In dem Zuge hat @apollon77 den Adapter Übernommen und es wurde dafür ein Dienst von der ioBroker GmbH dafür eingerichtet.
Melde dich doch bei ihm und kläre ob man das nicht so ändern kann das jeder Adapter das Nutzen kann.In diesem Zuge haben wir auch besprochen das die Nutzung eines zusätzlichen/externen Dienstes im Adapter (Readme) Kommuniziert werden muss. Es hatten sich nämlich Benutzer gewundert warum der Adapter Daten an eine Unbekannte URL gesendet hat.
-
@jey-cee
Danke Dir!Dann frage ich gleich mal hier, da das vermutlich zukünftig auch andere Adapterentwickler betreffen könnte.
@apollon77
Lässt sich das Verfahren über einen Dienst der ioBroker GmbH künftig vielleicht allgemeingültig verwenden?
Ich selbst entwickle beruflich nur In-House und hatte deshalb noch keine Berührungspunkte mit OAuth.
Wenn ich das Konzept richtig verstanden habe, stellt die ioBroker GmbH auf ihrer Webseite in diesem Fall Funktionen zur Verfügung, mit denen initial die Authorisierung gegenüber Netatmo durchgeführt wird und liefert dem Adapter ein Zugriffstoken zurück. Das muss der Adapter dann in Eigenregie regelmäßig aktualisieren.
Ich vermute mal, dass das nicht generisch gelöst ist, sondern für jeden weiteren Adapter auf eurer Seite erweitert werden muss?
Das würde dann natürlich bedeuten, dass jeder Entwickler eines Adapters sich künftig mit euch abstimmen müsste, wenn OAuth zu implementieren wäre.Natürlich könnte jeder Adapter dazu auch seine eigene Webseite verwenden - so denn eine existiert.
Aber wie @Jey-Cee schon schreibt: Der eine oder andere Anwender dürfte sich wundern, wohin da Daten hin und her gesendet werdenIch sag's ja: Security sucks
-
oauth beschreibt ja nur eine generelle methode, wie das authentifizierungsverfahren abläuft.
nämlich über verschiedene web requests. ich kenne da 2 versionen davonA)
- man hat ein application token vom anbieter bzw in einer weboberfläche vom anbieter generierbar
- mit diesem token und einem bestimmten web request erhält man ein session token, welches eine gewisse zeit lang gültig ist
- mit dem session token (meist als Header mit dem titel BEARER übertragen) kann man dann bei der webapplikation daten abfragen.
B)
- man hat ein application token vom anbieter bzw in einer weboberfläche vom anbieter generierbar
- mit dem application token (meist als Header mit dem titel BEARER übertragen) kann man dann bei der webapplikation daten abfragen.
manche wandeln das verfahren auch nochmal entsprechend ab.
mit welchen endpunkten man kommunizieren muss, steht meist in der api-dokuzuvor würde ich auch noch auf npm und github schauen ob ich nicht schon was entsprechendes finden kann, was man sogar kopieren kann oder als paket einfach einbinden kann.
https://www.npmjs.com/search?q=bosch indego
https://github.com/search?q=bosch indego&type=repositoriesfalls es da nix passendes gibt, kann man schauen ob es für andere programmiersprachen schon skripte gibt. meist ist das umwandeln nicht so schwer (oder chatgpt hilft dabei) oder ob es einen passenden oauth clienten für die kommunkiationsbibliothek seiner wahl findet
https://www.npmjs.com/search?q=axios oauth
https://www.npmjs.com/search?q=request oauthalle aufgeführten links sind nur ein vorschlag. ggfs. findet man anderswo noch vertiefende informationen
-
@codierknecht sagte in OAuth für Adapter:
Ich sag's ja: Security sucks
Auch Inhouse könnte so etwas zur Anwendung kommen, da auch interne Services bei euch sicherlich mit einer Authentifizierung läuft. Ein BI-Dienst holt sich die Informationen aus eurem Personal-Applikation ja hoffentlich auch nicht ohne Berechtigung, so das dann später ein management-Report darüber erstellt werden kann.
Das was du Beschreibst ist eher das, wenn du selbst Server sein willst. Dann musst du die Möglichkeit anbieten, ein Application-Token oder irgendetwas zu generieren.
In 99% der Fälle bist du aber Client und rufst woanders Daten ab. d.h. das Gerät oder der Anbieter in der Cloud (hier Bosch) stellt dir das Token zur Verfügung.
Hast du mal einen Link auf die API-Doku, dann kann man genauer schauen.
Hab auf die Schnelle nix von Bosch direkt gefunden. -
@oliverio sagte in OAuth für Adapter:
Auch Inhouse könnte so etwas zur Anwendung kommen, da auch interne Services bei euch sicherlich mit einer Authentifizierung läuft
Da bin ich fein raus, da das bei uns übers AD läuft
Wir verwenden DCOM. Damit wird die lokale Identität an den Application-Server übertragen.
Wer da gerade etwas will, kriege ich auf dem Server per GetOriginalCaller raus.oauth beschreibt ja nur eine generelle methode, wie das authentifizierungsverfahren abläuft.
nämlich über verschiedene web requests. ich kenne da 2 versionen davonIch habe das noch etwas anders verstanden, nämlich dann, wenn man noch kein Token hat bzw. kennt.
C)
- Der Client ruft bei Bosch an und liefert eine Callback-Adresse mit
- Bosch selbst verarbeitet die Authentifizierung und liefert ein Token an die Callback-Adresse
- Mit diesem Token ist der Zugriff möglich, ohne dass der Adapter selbst jemals Benutzername/Kennwort erhält.
- Das Token läuft irgendwann ab, darum muss das in regelmäßigen Zyklen aktualisiert werden.
Der Knoten in meinem Kopf ist das Callback.
Das muss ja eine Adresse sein, die Bosch erreichen kann, um das Token zurückzuliefern. -
ah ja hast recht, das ist eine weitere variante, wenn du eine applikation entwickelst, die das autorisierungssystem eines anderen verwendet.
das selbe verwendet bspw unser forum mit github authorisierung.
mein anmelden des forums drückst du auf den github knopf,
der leitet dich zur anmeldemaske von github.
dort darfst dich dann einloggen
github ruft dann die callback seite auf zusammen mit einem session token
das dann das iobroker forum als authentifizierungsbestätigung nehmen kann.
solange das nicht abläuft (wird bei jeder abfrage des forums erneut mit github abgeglichen)
bist du sozusagen angemeldet.das selbe bietet auch google an.
aber für die adapter authentifizierung ist das nicht so optimal, da das ggfs ja auch offline ohne internet ablaufen soll.
hast du den eine dokumentation zur api? da steht das doch drin, was es für möglichkeiten gibt
ich liebe offizielle dokumente.https://auth0.com/de/intro-to-iam/what-is-oauth-2
hier sind die verschiedenen granttypen beschrieben
aber nicht jeder muss alle anbieten -
hab mal home assistang nachgelesen.
die haben das wie folgt gelöst
https://github.com/jm-73/Indego/issues/171tatsächlich verwendet der dienst eine clientid mit einer callback url.
allerdings gibt es wohl keine möglichkeit eine neue clientid mit einer anderen callback_url
einzurichten. das wäre eine voraussetzzungha hat nun eine chome extention geschrieben, die einfach den request abfängt und selbst umleitet. das ist eine etwas ungewöhnliche vorgehensweise. die extention ist wohl nur zur einrichtung notwendig. der rest wird dann schon von der lokalen komponente erledigt.
was sich hiter der url https://my.home-assistant.io/redirect/oauth verbirgt weiß ich nicht.
ob das auch die adresse der lokalen ha instanz ist oder ein öffentlicher webserver
evtl kennen andere den ha da mehr
aber alles nur erkenntnisse aus einer relativ oberflächlichen analysedas ist dann auch der grund warum es keine offiziellen api dokumente gibt.
bosch sieht es aktuell nicht vor, das hinz und kunz da zugriff hat -
@oliverio
Es gibt wohl einen Umweg, um an ein Access-Token zu kommen.
Wenn man sich im Browser bei Bosch über SingleKey anmeldet und dann wieder einen Schritt zurück geht, soll angeblich der URL das Token enthalten. Wäre noch zu testen.
https://next.openhab.org/addons/bindings/boschindego/
Stellt sich zum einen die Frage, wie lange Bosch das so belässt und zum anderen, ob dieser Umweg einem Anwender bei der Einrichtung des Adapters zumutbar ist.Ich habe mal diese Quelle aufgetan:
https://docs.bosch-iot-suite.com/device-management/Set-up-OAuth2-client-for-third-party-applications.html -
irgendwo in der ecke war ich auch mal. da war sogar eine swagger beschreibung für eine api
leider stand drüber, das die 2024 eingestellt wird.ah hier ist es
https://apidocs.bosch-iot-suite.com/?urls.primaryName=Bosch IoT Suite - Account Management
die einzige api die nicht deprectated ist account management und die wird 2024 eingestellt
wer da ein account hat kann es auch oben rechts mit autorize mal probieren.
da kann man die apis direkt ausprobieren.
wie gesagt ist swagger, so eine art standard beschreibung die direkt aus den apis heraus generiert werden kann und über die man dann probieren kann -
@oliverio
Habe noch das hier gefunden:
https://bosch-iot-suite.com/This offer is only addressed to commercial customers including freelancers and entrepreneurs. All prices are exclusive of value added tax (VAT).
Ich fühle mich da durchaus angesprochen
Swagger nutzen wir selbst für die Dokumentation von API's.
Funktionieren tut's jedenfalls schon mal:
-
Sieht gut aus
Ist der single key I’d jetzt schon ein Access Token
Oder kommt da noch ein Schritt? -
@oliverio sagte in OAuth für Adapter:
Ist der single key I’d jetzt schon ein Access Token
Oder kommt da noch ein Schritt?Ich habe mir ja bei Bosch IoT einen Account erstellt. Da kann man sein Access Token im Profil rauskopieren.
Ob das so überhaupt zur Steuerung des Indego taugt, weiß ich nichtmal.
Ich muss da mal mit etwas mehr Sinn und Verstand ran.Wie lässt sich sowas eigentlich am besten ausprobieren?
Ich habe eine ioBroker-Testkiste laufen.
Lässt sich der Code innode-modules
direkt ändern um da Änderungen am Code mal auf die Schnelle auszuprobieren?Oder gibt's da was um mit VSCode on-the-fly Änderungen zu testen?
-
also ich würde das in einem node project erst mal nur in vs code testen.
da hast du viel besser debugging möglichkeiten.
du musst ja nicht gleich irgendwelche datenpunkte beschreiben, da reicht ja erst mal das bekannte console.logdu willst ja erst mal die grundlegende kommunikation testen und was dann da von bosch wieder zurückkommt,
du hast jetzt einen single ke id, das wurde in dem einen issue auch irgendwo mal erwähnt.
interessant wäre jetzt der nächste schritt. das müsste das sein, wo jetzt diese chrome extenstion zum einsatz kommt. da ist mir die funktionsweise noch nicht ganz klar.
besonders viel code ist da nicht drin, 2 relevante dateienbackground.js
hier wird wohl der netzverkehr gescannt und dann, wenn es um eine bestimmte url geht, wird einfach der header "Location" entfernt. der enthält ein redirect, so das die Anmeldung zu einer bestimmten Seite geht. also hier wird entferntconst CUSTOM_RULE_ID = 1 chrome.declarativeNetRequest.updateDynamicRules({ removeRuleIds: [CUSTOM_RULE_ID], addRules: [ { id: CUSTOM_RULE_ID, priority: 1, action: { type: "modifyHeaders", responseHeaders: [ { operation: "remove", header: "Location" } ] }, condition: { "urlFilter": "|https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/oauth2/authresp|", "resourceTypes": ["main_frame"] }, } ], });
und
constent-script.js
Im contentscript wird dagegen der seiten inhalt nach der regex gescannt und wenn es ein treffer gibt, dann wird die seite https://my.home-assistant.io/redirect/oauth aufgerufen, so kommt das token dann dort an. wie zuvor schon mal geschrieben weiß ich nicht was das für eine seite ist, lokal oder bei home-assistant in der cloud, keine ahnung. ich vermute es ist lokal und so kommt dann der token im "adapter" an und kann dort weiterverwendet werden.const urlRegex = /"com\.bosch\.indegoconnect%3a%2f%2flogin(.*)"/; let result = document.body.innerHTML.match(urlRegex); if (result) { redirectUrl = "https://my.home-assistant.io/redirect/oauth" + decodeURIComponent(result[1]); console.log("Redirecting to HA", redirectUrl); window.location.href = redirectUrl; }
und ein manifest.json
{ "name": "HomeAssistant Indego authentication helper", "version": "1.0", "description": "Handles the Bosch SingleKey ID OAuth response when adding the Indego component to HomeAssistant.", "manifest_version": 3, "action": { "default_popup": "popup.html" }, "permissions": [ "declarativeNetRequest" ], "host_permissions": [ "https://prodindego.b2clogin.com/*" ], "background": { "service_worker": "background.js" }, "content_scripts": [ { "matches": ["https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/oauth2/authresp"], "js": ["content-script.js"] } ] }
-
@oliverio
Klingt alles ein bisschen nach "von hinten durch die Brust ins Auge" -
genau
mit node kannst du ja ebenso browser spielen
und den redirect abfangen und das übermittelte token dann entsprechend weiter verwenden -
@codierknecht Ja, nein vllt
Am Ende gibt es zwei verschiedene Varianten bezüglich OAuth. Bei Netatmo ist es so das jeer User einen eigenen Account hat und damit nen eigenen Client Secret und so. Hier ist es generisch gelöst und keine Dienste der ioBroker GmbH aktuell dabei.
Bei OAuth springst Du zu einer Seite des Anbieters zum Login und dann zurück auf einen eigenen Server. Das Problem ist dieser "eigene server" den jeder Adapter auf machen müsste. Um das zu vermeiden haben wir etwas generisches in Admin eingebaut das man einen Link bekommen kann und wenn diese Seite aufgerufen wird dann wird der inhalt per Message an den Adapter gesendet der dann die Daten prüft. Am Ende funktioniert das weil das Redirect Ziel nicht aus dem Internet erreichbar sein muss, sondern nur dein Browser es können muss.Bei den meisten anderen - ich bin ehrlich ich habe nicht alles hier gelesen - ist es aber so as es EINEN zentralen client-id/secret gibt und nicht pro user. Der Fall ist komplexer und benötigt - um nicht die sicherheit komplett zu torpedieren - einen server der das managed. Je nach Adapter kann man sicher mit Bluefox reden ob er soetwas zentral aufsetzen kann, aber das sind immer Detailfragen.
-
@apollon77 sagte in OAuth für Adapter:
Ja, nein vllt
Ich hab hier so das Gefühl, das es auch ohne Server geht.
Aber codierknecht hat ein Account und kann das nur ausprobieren.Die erste Stufe ist schon geschafft und aus den Login-Daten wurde ein Single Key ID gemacht.
Wenn ich es recht sehe muss in der nächsten Stufe aus dem Single Key ID ein Authorisierungstoken gemacht werden, was man dann speichern kann und dann im Anschluss für Abruf/Zugriff als verwendet werden kann. -
@oliverio
Offenbar regelt Bosch das alles über Azure AD.
Ich habe mich mal an den Kommentaren zum Issue #171 orientiert.-
Klappt noch soweit.
Rufe ich das auf, komme ich zum Login für SingleKey ID. Dort melde ich mich mit meinem Account aus der Indego-App an.
Zurück erhalte ich eine augenscheinlich leere Seite, die erst im Quelltext einiges offenbart.
-
An Schritt 2) komme ich dann bereits nicht mehr weiter.
Wenn ich - wie beschrieben - den "code" aus der Login-Antwort einsetze, erhalte ich
{ "error": "invalid_grant", "error_description": "AADB2C90090: The provided JWE is not a valid 5 segment token.\r\nCorrelation ID: 5799103e-f219-4d2d-a06f-f2e2177ecd0c\r\nTimestamp: 2023-10-31 14:08:37Z\r\n" }
Der "code" hat offenbar nicht das erwartete Format.
Was bei der Antwort in "state" zurückkommt ist Base64 codiert und hat schon eher das gewünschte Format.{ "SID": "x-ms-cpim-rc:1d213be5-7a8a-4689-b67b-9c2478254443", "TID": "9028d52d-a722-4a1e-a508-6881ddfd0e5e", "TOID": "b8113681-aef4-474b-9ba2-25294caa48fc" }
Funzt aber genau so wenig
Ich persönlich wäre durchaus bereit, einmalig bei der Inbetriebnahme des Adapters den "code" aus dem Quelltext der Login-Antwort auszulesen und im Adapter zu hinterlegen.
Wenn der dann läuft, kann er sich ja regelmäßig ein neues Token besorgen (sobald man herausbekommen hat wie).Mühsam ernährt sich das Eichhörnchen ...
-
-
was passiert wenn du den loginprozess im browser normal fortsetzt?
also, erst die developer tools des browser mit f12 öffnen- diesen link im browser wählen
https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/b2c_1a_signup_signin/oauth2/v2.0/authorize?redirect_uri=com.bosch.indegoconnect://login&client_id=65bb8c9d-1070-4fb4-aa95-853618acc876&response_type=code&scope=openid offline_access https://prodindego.onmicrosoft.com/indego-mobile-api/Indego.Mower.User - dann auf single key klicken
- auf der folgeseite deine login daten eingeben
-> theoretisch müssten dann eine antwort kommen(im networktab der developer tools schauen), aber der browser macht nix mehr weiter,
weil in der antwort im response header sich eine Anweisung befindet, die sichLocation com.bosch.indegoconnect://login/?code=ABCDEFG
nennt. Der browser stoppt deswegen, weil er die Adressierung com.bosch.indegoconnect://login/?code=ABCDEFG
nicht versteht. normalerweise steht da eine http-adresse drin und der browser versucht dann die seite aufzurufen.
wenn aber der rasenmäher diese antwort erhält, dann weiß er, das er seine Mäher-Software aufrufen muss und übergibt dann den code.
ABCDEFG müsste dann das token für die Datenabfrage des Rasenmähers sein.kannst du das nachstellen?
Wenn das so funktioniert, dann bauen wir den Kommunikationsablauf in node nach und brauchen dann kein chrome-extension - diesen link im browser wählen
-
@oliverio
Wenn man diesen Code Bas64-dekodiert, scheint es sich um etwas gepacktes zu handeln:
Ich könnte mal die Redirect-Uri auf ein Script auf meinem Webserver legen.
Wenn ich das Konzept richtig verstanden habe, sollte die Antwort ja dann dahin gesendet werden.
Nur um zu sehen, ob da etwas sinnvolleres ankommt.Das wäre ja dann auch die Stelle, an der ggf. Bluefox ins Spiel kommt. Natürlich könnte ich das für den Adapter auch auf meinem Server belassen - so denn etwas sinnvolles zurückkommt. Aber dann gibt's ja wieder das Problem, dass Daten an dem Anwender unbekannte Stellen gesendet werden. Der eine oder andere wird sich möglicherweise wundern.
Und ich befürchte, dass über kurz oder lang auch andere Hersteller nachziehen.