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