OAuth2 über Symcon Connect

Server-Variante

  1. Gewünschte ServerID (Nur kleingeschriebene Buchstaben) + Name (Sprechender Name) + Redirect URLs mir per PN schicken.
  2. Ich sende euch das benötigte Client Secret
  3. Ihr richtet alles bei eurem Dienst ein
  4. Sofern sich ein Kunde authentifizieren will, wird er nach seiner Lizenz-Email gefragt und an diese ein Code gesendet
  5. Wir leiten den Kunden auf den Dienst (Redirect URL) weiter und übermitteln den geheimen Schlüssel
  6. Der Dienst muss seine Daten an die Daten URL per POST senden und wir leiten diese an den Endkunden per Symcon Connect an das OAuth Modul weiter

Dokumentation:
Authorize URL: h t t p s ://oauth.ipmagic.de/authorize
AccessToken URL: h t t p s ://oauth.ipmagic.de/access_token
Grant Type: Auth Code Grant
Scope: none
Daten URL: h t t p s ://oauth.ipmagic.de/forward

Sicherheit:
Das ganze Ping Pong verfahren ist laut OAuth2 Protokoll und somit entsprechend den RFCs sicher. Die Anfrage an die /connect Adresse wird anhand des Authorization Tokens im Header verifiziert. Anhand dieses Tokens ist auch der Kunde eindeutig identifizierbar, sodass die Daten an die korrekte Symcon Connect Adresse weitergeleitet werden. IP-Symcon 4.2 lässt über das OAuth Control nur Daten direkt vom Connect Server durch. Sollte also jemand von extern (ipmagic.de) versuchen die /oauth/clientID Adresse aufzurufen, wird dies verweigert. Die oauth Subdomain hat ein gültiges Zertifikat und kann nur über SSL genutzt werden!

Vergebene ServerIDs:
amazon_smarthome | Amazon Alexa | Symcon GmbH
google_smarthome | Google Assistant | Symcon GmbH

Client-Variante

Redirect-URL: https://oauth.ipmagic.de/forward/{deine_client_id}

Ihr findet die Referenz Implementation (welche ihr natürlich anpassen müsst) hier:

Vergebene ClientIDs:
bose_switchboard | Bose Switchboard | ubittner
cloudrain | Cloud Rain | Symcon GmbH
home_connect | BSH Home Connect | Symcon GmbH
honeywell | Honeywell Home | Symcon GmbH
husqvarna | Husqvarna Group | Symcon GmbH
google_nest | Google Nest | Symcon GmbH
locative | Locative | Nicht mehr vorhanden!
logitech | Logitech MyHarmony | Fonzo
meetup | Meetup | Fonzo
nello | Nello | ubittner
netatmo | IP-Symcon Netatmo Connector | Symcon GmbH
nibe_uplink | NIBE | Symcon GmbH
ondilo | Ondilo | Fonzo
osram_lightify | Osram Lightify | Whitesheep
somfy | Somfy | ?
sonos | Sonos | Symcon GmbH
spotify | Spotify | Symcon GmbH
sync_dropbox | DropBox Sync | paresy
test | OAuth Test Client | Symcon GmbH
withings | Withings | 1007

Standalone Variante (Client)
Bei der Standalone Variante wird der Client für jeden Nutzer konfiguriert und somit muss ClientID/ClientSecret im Modul eingegeben werden. Außerdem muss die im Modul angezeigt RedirectUri beim API-Provider hinterlegt werden. Dadurch wird auch klar, dass der Client an genau eure Connect-Adresse gebunden wird und ihr jeder beim Standalone Modul sich für die API beim API Provider selber registrieren muss. Bei der normalen Variante (welche präferiert werden sollte) halten wir ClientID/ClientSecret vor und können die RedirectUri generisch halten, da wir das Routing zu euch über den Connect-Dienst vornehmen. Für Prototyping und Sonderfälle (z.B. Mercedes Benz, welche für die API viel Geld wollen) kann die Standalone Variante aber eine gute Wahl sein.

Ihr findet die Referenz Implementation (welche ihr natürlich anpassen müsst) hier:

Oft wird beim OAuth auch eine Privacy Policy verlangt. Bei Amazon ist das z.B. Vorraussetzung. Nur auf das Impressum zu verweisen ist da wohl zu wenig.

Gibt es von IP-Symcon eine Privacy Policy auf die man Verlinken kann?

Bei Hue sieht das z.B. so aus
Philips Hue

Da bräuchte man also so was in der Art was am besten von einem Rechtsanwalt aufgesetzt wurde. Da müsste drinnen stehen das IP-Symcon die Email Adresse erfasst um damit die Lizenz zu prüfen und die zugehörige IP-Symcon Connect IP zu ermitteln an die die Daten des Dienstes gesendet werden. Das sich IP-Symcon an den Deutschen Datenschutz hält und mit dem OAuth Endpunkt die Daten zwischen dem Dienst und dem Kunden mit seiner IP-Symcon Installation über IP-Symcon Connect weitervermittelt. Wie auch immer das dann eben im geltenden Rechtsgebrauch formuliert sein muss.

Ist das ganze jetzt stable?
Eventuell Mal im Public Bereich verschieben?
Michael

Ich möchte über die neue Google Nest API eine Verbindung von Symcon zur Google API aufbauen. Goggle hätte gerne die OAuthClientID

Wie heist den jetzt die Client ID für : google_nest | Google Nest | Symcon GmbH ?

Ich müsste den Zugang doch über einen Webhook anlegen oder ?

Das ist google_nest. Wenn das aber nicht „deine“ ClientID ist, dann solltest du dich lieber melden, damit du eine eigene bekommst. Ansonsten könnte dein Problem mit dem aktuellen Google Nest Modul bekommen, wenn beide gleichzeitig in Verwendung sind.

Ich habe soeben im ersten Beitrag eine neue Variante hinzugefügt, womit ihr zum Testen/Prototyping einen vollständigen OAuth2 Client direkt in IP-Symcon über den Connect Dienst abbilden könnt. Ihr seid dann nicht darauf angewiesen, dass ich einen Client-Endpunkt erstelle, sondern könnt direkt loslegen. Oder für APIs bei denen wir rechtlich keinen Client-Endpunkt anbieten können, kann damit jeder User selbst seinen eigenen OAuth2 Endpunkt haben.

Sofern ihr ein Modul im Store veröffentlichen wollt, und alle User es „einfach“ bei der Einrichtung haben sollen, empfiehlt sich weiterhin die normale Client Variante bei der wir die ClientID/ClientSecret serverseitig pflegen :slight_smile:

paresy

@paresy
Ich teste gerade die Variante mit Mercedes. Komme da aber gerade nicht weiter.
Wir haben einen Smart der auch über die app und das Mercedes Portal abrufbar ist.
Projekt ist auf der Developer Seite eingerichtet. Die Redirect-Uri ist bei Mercedes eingetragen.
Wenn ich im Modul „REGISTER“ anklicke kommt im Browser auch die Meldung " Success! You can now close this window. und bei Token steht Yes.
Wenn ich als Test-Uri z.B. diese URL verwende
https://api.mercedes-benz.com/vehicledata/v2/vehicles/WXAX533911KXXXXX/resources/soc/ (mit korrekter Vehicle ID natürlich)
bekomme ich nur folgende Meldung „{„errorMessage“: „Internal Server Error“, „statusCode“: „500“}“

Hast du zufällig eine Idee was hier falsch läuft?

Viele Grüße
Stephan

Leider nein. Du müsstest ggf. im Quellcode vom Modul schauen was genau wir machen und ob evtl. noch etwas laut API von Mercedes fehlt.

paresy

Habt ihr das denn jemals erfolgreich mit Mercedes getestet? Ich frage nur weil du in dem Screenshot ja beispielhaft die Mercedes Daten drin hast…

Ist jemand weiter gekommen, ich stehe vor derselben Fehlermeldung wie da8ter {„errorMessage“: „Internal Server Error“, „statusCode“: „500“} mit dem Standalone-Modul von parsey?
Den Quellcode editieren übersteigt meine Fähigkeiten :grinning:
Es geht auch um die Mercedes Me Abfrage…

Habe mich nun auch einmal an dem OAuth System versucht. Ich möchte mit der „Client-Variante“ die sonos API verwenden. Das anfordern des Token funktioniert soweit, allerdings bringe ich es nicht fertig Daten abzufragen.
Hier mein angepasster Code:

	public function Testing()
	{
		/*
		GET /control/api/v1/households HTTP/1.1
		Content-Type: application/json
		Authorization: Bearer <Access-Token>
		Host: api.ws.sonos.com
		*/
		$opts = array(
			"http" => array(
				"method" => "GET",
				"header" => "Authorization: Bearer " . $this->FetchAccessToken() . "\r\n" . "Content-Type: application/json" . "\r\n"
			)
		);
		$context = stream_context_create($opts);
		$data_url = "https://" . $this->oauthServer . "/forward";
		$api_endpoint = "/households";
		$result = file_get_contents($data_url . $api_endpoint, false, $context);
		var_dump($result);
	}

Dieser gibt einen HTTP-Error 400 aus:

Warning: file_get_contents(https://oauth.ipmagic.de/forward/households): failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request

Was mache ich falsch?

Schau dir das mal an: GitHub - symcon/Sonos: Sonos for IP-Symcon Da haben wir damals schon was angefangen - vielleicht hilft es dir. Das Problem wird langfristig aber sein, dass du die Events nicht eingesammelt bekommst - da ist Sonos sehr eigen, wie Sie das implementiert haben.

paresy

Danke! Werde mir das Repo mal genau anschauen und auch was es mit den Events auf sich hat.

Dee22

Moin Miachael,

ich frage mit der Standalone Variante meine Nibe Wärmepumpe ab. Funktioniert gut, das Token ist jedoch nur eine Stunde gültig. Ich würde mit refresh_token gerne ein neues Token abfordern.
Gibt es im Modul dafür eine fertige Funktion?

vg
Dieter