Je souhaiterais savoir si vous avez des solutions ou piste a me proposer pour pouvoir gérer l’authentification a des services « cloud » qui nécessite Oauth2 de type Authentification code.
J’ai je penses compris le principe :
Ouverture d’une url d’authentification (avec un paramètre redirect_uri) permettant a l’utilisateur de s’authentifier sur le service (et d’autoriser l’application a utiliser un certain périmètre de données)
Le service lance ensuite la page de redirect_uri avec en paramètre le code nécessaire a l’utilisation du service.
Mon problème est que le redirect_uri doit être déclaré au service et que dans ces conditions, je ne vois pas comment je pourrais avoir en redirect_uri une page « local » de jeedom qui me permettrait d’exécuter du javascript (ou autre) pour récupérer le code et avoir depuis le plugin accès au données.
J’ai vu que le protocole permet au application desktop d’utiliser ce genre de service et l’authentification Oauth2.0 en utilisant en redirect uri la valeur suivante : urn:ietf:wg:oauth:2.0:oob
J’arrive bien a exécuter l’authentification, une page d’ouvre bien avec le code d’authentification mais comment le récupérer automatiquement
J’ai essayer de façon interactive et je peux bien récupérer le code d’authentification mais je pense que celui ci expire rapidement et que si il n’est pas utiliser très vite alors il n’est plus valide (je n’ai pas réussi a aller plus loin même en me dépêchant)
Voila donc si quelqu’un a des pistes je suis preneur.
Nota :
je n’ai pas mis de tag plugin car il n’est pas encore fait mais ce serait pour integrer legrand with netatmo
je n’ai pas mis de langage car je m’en moque, quelque soit le langage proposé, j’arrive bien a m’en sortir. De plus c’est plutôt un principe que je cherche.
Merci d’avance au courageux qui se pencheront sur ce problème qui me semble un peu épineux.
A+
Malheureusement pour le moment nous n’avons pas de solution la dessus, la pluspart des services oauth font du cloud a cloud or jeedom n’étant pas cloud c’est compliqué. On a un projet de mettre un systeme cloud qui renvoi vers les Jeedoms mais c’est très très très complexe a faire si on veut le rendre indépendant du service derriere (amazon,google…)
J’avais un peu réfléchi à ce sujet et ce n’est effectivement pas simple.
Je suis arrivé à la conclusion qu’il faudrait initier à la fois un serveur local sur un autre port que l’ui jeedom et un transparent proxy pour gérer la partie qui demande le login et mot de passe (pour la première fois ou si le token n’est plus valable).
Cela pourrait être géré dans un plugin dont la configuration des ‹ équipements › se ferait par bloc php pour chaque étape (login/refreshtoken) pour coller aux besoins de l’application cible (google, spotify…).
En gros quand il y a besoin de récupérer un token, le serveur se lance en localhost sur jeedom, demande un token (ou le rafraichit) et le mets dans une commande info. Si il y a besoin d’une (re)authentification, l’ui de login/mdp est proxié à l’utilisateur afin que le redirect url puisse fonctionner de manière transparente.
Une fois que c’est fait, ce petit serveur peut s’éteindre jusqu’à la prochaine demande de token.
D’un point de vue implémentation, node js ou python semble le plus simple car plein d’exemples pas besoin de bricoler apache/nginx jeedom.
Tout à fait. Maintenant si on veut un hébergement de l’application en local je ne vois pas comment faire d’autre (à moins de diffuser les CLIENT_ID et CLIENT_SECRET de l’appli. Ce qui me semble une très mauvaise idée).
Bonjour,
Je suis dans la même intérrogative que @DavZero … j’ai repris le plugin alarme_IMA il y plus d’un an.
Celui-ci ne fait que simuler l’appli web.
Voulant consommer leur API directement, l’ancien développeur du plugin m’a mis en contact avec la société (Ima Protect).
Leurs APIs utilisent de l’oauth2 avec un grant « authorization code » ( offre la meilleur garantit au niveau de la sécurité) mais qui implique d’avoir une url de redirection définie au niveau de l’app chez eux.
J’ai vu que Jeedom sas l’a intégré dans le plugin Enedis …
Force-t-il d’avoir une seul redirection enregistrée chez eux?
Car oAuth n’impose pas ça, tu peux très bien passer l’url de redirection à utiliser lors de l’appel initiale.
Si oui, est-ce que dans le plugin chaque utilisateur doit créer son propre clientId / clientSecret? je suppose que oui car si c’est un clientId/secret pour le plugin alors il ne sera plus secret justement donc ca ne sert à rien…
sauf si tu as ton propre server backend pour gérer l’auth initiale et que ton clientId/secret n’est connu que par ce backend; justement ce qu’à fait Jeedom pour certains plugins
Pour le moment le plugin ne fait rien … enfin si quand même … il se débrouille avec le login / mdp … mais il consomme par leur API avec l’oauth2 … c’est la cible…
Pour moi il faut un serveur backend pour gérer l’auth comme ce qu’a fait Jeedom pour le plugin Enedis parexemple … c’est pour cela que je voulais savoir si on pouvait en bénéficier pour un plugin tiers …
Allez ce week-end je potasse l’oauth2 car je suis pas très calé …
J’ai des plugins qui gère de l’oauth.
Le plus simple sur un jeedom et niv secu c’est acceptable (si on considère que jeedom est safe) c’est le password grant flow.
Mais pour l’un d’eux j’ai du faire un Authentication code flow car c’était le seul accepté
par contre dans tous, chaque utilisateur doit créer son accès api et donc avoir un clientid et client secret personnel.
Avec ça pas besoin d’un autre backend.
Évidemment c’est plus de config que s’il n’y avait qu’un seul clientid/secret mais au moins c’est possible.
Pour l’auth code flow, après l’authentification ça redirige vers une page dédié du plug-in qui valide l’auth_code et récupère l’acces token et le refresh token.
pour le moment ils ne veulent que de l’authentication code flow … moi je leur proposait du credential code flow (avec la partie authentication code flow fait sur leur site … comme le plufin naenergie par exemple … on apres client id et client secret )
Pour quel plugin as tu fait du Authentication code flow ?
Je ne comprends pas ces problématiques d’authentification à tous les niveaux, c’est assez obscur pour moi… Pour prendre un exemple concret, sur le plugin LGThinq j’ai utilisé une API tierce (en python) qui elle-même interroge l’API LG (tel que je le comprends c’est donc un « cloud » LG qui discute avec tous les appareils connectés de la marque)
Bref, l’API tierce python contient en dur dans le code le client_id, oauth_secret_id et oauth_client_key, doit-on s’en inquiéter ?
Comme c’est cette même API qui est utilisé pour Home Assistant, Homebridge, Domotics… Je me suis pas inquiété outre mesure et j’ai fait pareil
Dans le process de configuration du plugin jeedom, l’utilisateur est redirigé vers le portail LG pour s’identifier et générer un « refresh_token » qui lui est unique et n’expire pas.
L’accès vers LG ici est probablement un retro-engeneering d’une app qui contenait le secret… mais cela ne devrait pas arriver en principe: a quoi bon avoir un secret s’il est publique…
Et je suppose que l’utilisateur doit faire rentrer son user et mot de passe et que l’app récupère l’access token via un password grant flow.
Mais donc ici oauth n’apporte rien… un http basic auth ferait pareil, ni moins sécur ni plus.
Après comme l’api est probablement pas publique/ouverte ca nous arrange bien de pouvoir passer au travers et cela pour plusieurs devices connectés
