Comptes Google : l'identification aux applications via une web-view bientôt « obsolète »

Comptes Google : l’identification aux applications via une web-view bientôt « obsolète »

No-Google zone

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

24/08/2016 3 minutes
23

Comptes Google : l'identification aux applications via une web-view bientôt « obsolète »

Pour connecter une application à un compte, une pratique habituelle est d'ouvrir la page de connexion du service dans une page web embarquée, une web-view. Google compte interdire cette méthode dans les prochains mois, pour privilégier une identification directement dans le navigateur, jugée plus simple.

Google veut en finir avec la connexion via les web-views. Dans un billet de blog, le groupe explique qu'il compte bloquer les identifications aux comptes de ses clients via cette méthode dans les prochains mois. Actuellement, une grande part des applications qui proposent de se connecter à un compte en ligne, comme Google, passent par une web-view, c'est-à-dire l'ouverture d'une page web directement dans son interface.

S'identifier une seule fois par appareil

Seulement, cette méthode a un inconvénient important : puisque la page est ouverte une fois et oubliée, l'utilisateur doit rentrer ses identifiants pour chaque nouvelle application. Une tanée, estime le groupe de Mountain View, qui compte obliger les développeurs à adopter une alternative : l'intégration du navigateur par défaut dans l'application.

Avec Chrome sur Android et Safari sur iOS, il est possible d'ouvrir un « nouvel onglet » directement dans l'interface d'une application. Sur Android, les Chrome Custom Tabs remplissent par exemple cette fonction, quand il s'agit de la classe SFSafariViewController sur iOS.

En utilisant un onglet intégré, ce sont les données du navigateur qui sont utilisées, avec les cookies qui vont avec. Si l'internaute s'est déjà identifié via ce navigateur, les informations sont ainsi retenues. « Les utilisateurs ont seulement besoin de s'identifier une fois à Google par appareil, améliorant du coup les taux de transformation et le flux d'autorisation de vos applications » explique la société dans son billet. C'est tout l'intérêt du single sign-on mis en place par l'entreprise, via le protocole OAuth.

D'Android à Windows, les web-views mises au rebut 

Google n'hésite pas à qualifier l'identification par web-view d'« obsolète » et va bientôt s'assurer qu'elle ne soit plus utilisée. Le changement ne concerne pas seulement les applications mobiles, mais aussi celles sous macOS et Windows. Les versions de Google Sign-In antérieures à la 3.0 sont « dépréciées », car elles ne supportent pas l'intégration d'un onglet dans une application.

Dans son billet, l'entreprise fournit par ailleurs des SDK, bibliothèques et exemples pour faire la transition des web-views vers les navigateurs. Les développeurs ont encore quelques mois pour s'adapter. À partir du 20 octobre, les nouveaux clients OAuth ne pourront plus utiliser les web-views. Le 20 avril 2017, l'ensemble des requêtes OAuth via une web-view seront purement et simplement bloquées sur les systèmes où une alternative viable existe, laissant les applications non-maintenues sans moyen de connecter un compte Google. Le support de l'identification par web-view sur iOS 8 ne sera pas supprimé dans l'immédiat, même si Google explique que des avertissements pourront apparaître.

23

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

S'identifier une seule fois par appareil

D'Android à Windows, les web-views mises au rebut 

Commentaires (23)


Bonne initiative, rien de plus chiant que de retaper à chaque fois ses infos de connexion.

Certaines applications permettent directement de se connecter via le compte enregistré sur Android, c’est tellement plus simple.


Oui et surtout je trouve ça dangereux les pages web in app

Rien ne me dit que l’URL est vraiment celle de google, et que c’est pas une page exprès pour te voler tes identifiants…


Cela force à être loggué sur son navigateur pour mieux traquer le client lors de la navigation… Est-ce vraiment pour le bien du client?…

J’uriliserai un navigateur pour l’authentification et un autre pour naviguer. Ils commencent à pousser fort le tracking.


Rien ne t’oblige à rester connecté si tu ne veux pas.


Je pense la même chose, mais du coup je me demande si ces “Chrome Custom Tabs” vont vraiment permettre d’éviter ce problème. Ça s’intègre bien dans l’application, mais du coup ça parait aussi plus facile à imiter non ?


+1 avec ElJulio, encore une fois sous-couvert d’un “nouveau service” ça permet avant tout à Google d’améliorer son tracking…

En tant que journaliste ça pourrait être intéressant que vous preniez ce recul pour au moins l’évoquer, en ne pas s’appuyant pas uniquement sur les dires de Google. Se poser la question est légitime.








Flyman81 a écrit :



+1 avec ElJulio, encore une fois sous-couvert d’un “nouveau service” ça permet avant tout à Google d’améliorer son tracking…

En tant que journaliste ça pourrait être intéressant que vous preniez ce recul pour au moins l’évoquer, en ne pas s’appuyant pas uniquement sur les dires de Google. Se poser la question est légitime.







Quel tracking ? Déjà ca ouvre le navigateur par défaut (Firefox chez moi), de plus le login se limitera surement à renvoyer un token à l’app et c’est terminé… l’avantage de passer par le navigateur c’est qu’il est possible de stocker ses identifiants (+sync) ou d’avoir sa session “pré-ouverte” par cookie.



Il n’y a pas de tracking ici…









Flyman81 a écrit :



+1 avec ElJulio, encore une fois sous-couvert d’un “nouveau service” ça permet avant tout à Google d’améliorer son tracking…

En tant que journaliste ça pourrait être intéressant que vous preniez ce recul pour au moins l’évoquer, en ne pas s’appuyant pas uniquement sur les dires de Google. Se poser la question est légitime.





du coup vraie question : en tant que journaliste (par opposition à éditorialiste ou blogueur), Guénaël a-t-il le droit de faire une accusation sans fondement ? (y compris sous une forme JAQ)



Je comprends ton interrogation, bien évidemment (on connait google… du coup je la partage très largement), en revanche, je ne suis pas convaincu qu’un procès d’intention ait sa place dans un article <img data-src=" />







CryoGen a écrit :



Quel tracking ? Déjà ca ouvre le navigateur par défaut (Firefox chez moi), de plus le login se limitera surement à renvoyer un token à l’app et c’est terminé… l’avantage de passer par le navigateur c’est qu’il est possible de stocker ses identifiants (+sync) ou d’avoir sa session “pré-ouverte” par cookie.



Il n’y a pas de tracking ici…





même sachant que ça s’appuie sur les Chrome Custom Tabs ?



J’ai pas tout compris. Par exemple la connexion sur pcinpact, c’est une web-view ?








WereWindle a écrit :



même sachant que ça s’appuie sur les Chrome Custom Tabs ?







Parce que tu es certain que le web-view est safe aussi ?



Et je sors la doc Google

When a Custom Tabs implementation is provided by a browser on the device (for example by Chrome), Custom Tabs are used for authorization requests. Otherwise, the default browser is used as a fallback.





Donc il suffit d’implémenter la fonctionnalité dans le navigateur (si ce n’est pas déjà fait) et voilà. Et si on a pas Chrome, ni le support Custom Tabs dans le navigateur, on tombe tout de même sur le navigateur par défaut.



L’article de blog de Google parle des Chrome Custom Tabs en parlant “par exemple” de Chrome (c’est dans le texte), mais en réalité l’API s’appuie sur Custom Tabs que n’importe quel navigateur peut implémenter.



Firefox est en train de l’implémenter : ici

Custom Tabs Et non “Chrome” Custom Tabs ;)









CryoGen a écrit :









Je n’avais pas été voir la doc <img data-src=" />

(et comme l’article ne précisait que Chrome et Safari, je me disais que c’était spécifique ;) )



Quant au côté safe de la chose, il ne me parait pas génial (je précise : pure intuition/préjugé car je n’ai pas assez de connaissances sur le sujet pour avoir un début d’avis valable)



Une web-view est comme un navigateur hyper-limité. Il s’agit pour une application d’afficher une page web et de pouvoir interagir avec elle. Dans le cadre de l’authentification, il s’agit de récupérer le “token” de session.



Soucis majeur : on ne voit pas l’url de la page: si une app surnoise ouvre un web-view vers une page qui ressemble à Google mais qui est une contrefaçon (phising), tu ne le vois pas et te fait avoir. Au moins avec le navigateur tu ajoutes une sécurité “visuelle” (check de l’url, certificat).



J’allais demandé comment faire si on utilise Firefox ou Edge par défaut. Tu viens d’y répondre en partie. C’est pour les smartphones et Mozilla bosse dessus.



Merci








spidermoon a écrit :



J’ai pas tout compris. Par exemple la connexion sur pcinpact, c’est une web-view ?





Non l’application t’ouvre une fenêtre avec la page de login de Google tout simplement.

Comme Thunderbird, enfin je suppose. On parle bien du support de OAuth?

&nbsp;



” l’intégration du navigateur par défaut dans l’application.” Ca change quoi avec Thunderbird?

Non parce que techniquement le moteur web de Thunderbird c’est surement celui de Firefox.<img data-src=" />



Ca veut dire que thunderbird va devoir permettre l’intégration d’Internet Explorer aussi (si il est par défaut)? Ou Edge? Ou ce spyware de Chrome? Ou s’adapter a n’importe quel navigateur? Ils pousseraient pas le bouchon trop loin chez Gougoule?



C’est du grand n’importe quoi .



Quand à la “complexité” actuelle… c’est aussi du vent.

Tu veut ajouter un compte gmail dans Thunderbird? Tu rentres tes identifiants deux fois au lieu d’une ca prend une minute et voila c’est réglé. Meme un neuneu, il voit sa page de login Google, il sait quoi faire <img data-src=" />



Non ce qu’ils veulent c’est pouvoir fourrer du Chrome et des onglets Chromes partout dans les applications.

Et en “facilitant” la vie , faire passer les autres appli pour des bouses. Tout ca c’est pour promouvoir Chrome.



Je ne nie pas l’aspect sécurité, mais quand même, ya des applications sures et reconnues , cela fonctionne.

Pourquoi les punir?

Cette manie de déresponsabiliser les gens…








RaoulC a écrit :



Je ne nie pas l’aspect sécurité, mais quand même, ya des applications sures et reconnues , cela fonctionne.&nbsp;

Pourquoi les punir?&nbsp;

Cette manie de déresponsabiliser les gens…





Avant il y avait pas d’électricité et le pétrole ne s’appelais pas or noir.

J’entend par la “EVOLUTION”







RaoulC a écrit :



Meme un neuneu, il voit sa page de login Google, il sait quoi faire <img data-src=" />





&nbsp;Moi je pari pas la dessus… loin de la

&nbsp;



RaoulC a écrit :



Non ce qu’ils veulent c’est pouvoir fourrer du Chrome et des onglets Chromes partout dans les applications.

Et en “facilitant” la vie , faire passer les autres appli pour des bouses. Tout ca c’est pour promouvoir Chrome.&nbsp;





Bah non vu qu’ils appuient sur un “nouveau processus” pour le faire devenir un “nouveau standard”. Pour preuve cela fonctionne avec Chrome et Safari et le dev est en cours sur Firefox comme cela à était dit par CryoGen



Le point ou je te rejoins c’est sur la “déresponsabilisation”. Combien de personnes clic sans savoir ce qu’elles font/autorise réellement&nbsp;<img data-src=" />?

Je suis mort une première fois le jour ou j’ai entendu. “Je peux pas aller sur Facebook car j’ai pas google quand j’appuie la” - Mélanie 13 ans&nbsp;<img data-src=" />



De quoi tu parles ? Ici il s’agit d’Android et les web-view. Pas de Windows ou Linux <img data-src=" />



Et Google ne fout pas Chrome partout, vu que tu bascules sur le navigateur par défaut… et surtout ce n’est pas DANS les applications, ca reste externe.









RaoulC a écrit :



Je ne nie pas l’aspect sécurité, mais quand même, ya des applications sures et reconnues , cela fonctionne.

Pourquoi les punir?

Cette manie de déresponsabiliser les gens…





Justement en évitant le web-view qui ne t’indique aucun renseignement, au moins tu verras l’url de la page et les certificats… aucune déresponsabilisation au contraire…



Bref, tu es passé à coté de la news <img data-src=" />









CryoGen a écrit :



De quoi tu parles ? Ici il s’agit d’Android et les web-view. Pas de Windows ou Linux <img data-src=" />







<img data-src=" />





In the coming months, we will no longer allow OAuth requests to Google in embedded browsers known as “web-views”, such as the WebView UI element on Android and UIWebView/WKWebView on iOS, and equivalents on Windows and OS X.



To help you migrate, we offer libraries and samples that follow modern best practices which you can use:

* Google Sign-in and OAuth Examples for Windows, examples demonstrating how to use the browser to authenticate Google users in various Windows environments such as Universal Windows Platform (UWP), console and desktop apps.







  1. Google (en tant que service web) n’autorisera plus les requetes OAuth provenant de navigateur embarqué.

  2. Google (en tant qu’ami des développeurs) propose des exemples de code pour envoyer correctement les requetes OAuth depuis Android, IOS, Windows et OSX.







    CryoGen a écrit :



    Bref, tu es passé à coté de la news <img data-src=" />







    paille œil voisin poutre



C’est bien gentil leur histoire, mais on fait quoi sur les plateformes où il n’y a pas ces “Chrome Custom Tabs” ? Pour autant que je sache, pour les applis desktop, une webview est le seul moyen de s’authentifier auprès d’un fournisseur OAuth ou OpenId…



EDIT: ah si, pardon :https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03








127.0.0.1 a écrit :



<img data-src=" />









  1. Google (en tant que service web) n’autorisera plus les requetes OAuth provenant de navigateur embarqué.

  2. Google (en tant qu’ami des développeurs) propose des exemples de code pour envoyer correctement les requetes OAuth depuis Android, IOS, Windows et OSX.







    paille œil voisin poutre







    Damned <img data-src=" />

    Comme je me suis focalisé sur le coté “chrome obligatoire” des premiers commentaires je suis resté bloqué sur android par la suite <img data-src=" />







    RaoulC a écrit :



    (…)







    Sorry <img data-src=" />



    Mais je reste tout de même sur ma position pour le coté “déresponsabilisation” <img data-src=" />









CryoGen a écrit :



De quoi tu parles ? Ici il s’agit d’Android et les web-view. Pas de Windows ou Linux <img data-src=" />



Et Google ne fout pas Chrome partout, vu que tu bascules sur le navigateur par défaut… et surtout ce n’est pas DANS les applications, ca reste externe.





Justement en évitant le web-view qui ne t’indique aucun renseignement, au moins tu verras l’url de la page et les certificats… aucune déresponsabilisation au contraire…



Bref, tu es passé à coté de la news <img data-src=" />&nbsp;



Je suis peut etre passé a coté de la news, mais pour une fois je l’ai relue, et re-relue avant de répondre , histoire d’éviter de me planter :p



&nbsp;&nbsp;“Le changement ne concerne pas seulement les applications mobiles, mais aussi celles sous&nbsp;macOS et Windows.”



Mais bon ;) Ca arrive à tout le monde <img data-src=" /> Bisous :)



Et pour le côté “aucun renseignement”. …. C’est vrai, mais dans ce cas il suffit de les donner.

Je n’ouvre pas de compte gmail tout les jours mais peut-être que la webview de thunderbird le fait (le certif , tout ca)



Si tu veut , sur le principe, si on emploie un client mail c’est justement pour éviter de devoir mettre en branle le navigateur, bouffeur de ressource et touti quanti. Et quid si les données de navigations sont purgées quand tu ferme le navigateur?



La ca va faire du dev en plus, pour intégrer des onglets de navigateurs , ce qui de toute facon revient au même que les webviews. On réinvente la roue o_o



Parce que le logiciel malveillant ne va pas s’arrêter à cause de ca, il va juste évoluer : il va détecter le navigateur par défaut et te montrer un faux onglet au lieu d’une fausse webview, avec les “informations” bidonnées qui disent que tout va bien….L’argument sécuritaire prend donc un coup dans l’aile.



Le problème avec ses “nouveau processus” c’est que l’on réduit l’intéraction de l’utilisateur.

Si tout est automatisé, il suffit au logiciel malveillant de ne PAS informer l’utilisateur , il ouvre un “nouveau processus chrome” et il lit le token , et le vole. Et meme si chrome affiche une fenetre d’autorisation (ce qui détruit la simplification) le logiciel malveillant la masque (ou clique sur oui)



Cela deviendra juste une variante plus élaborée des bons vieux “stealers” qui vont fouiller dans les cookies et les mots de passes enregistrés dans les navigateurs. Tout est automatisé, le pigeon ne voit rien..

La contrainte de l’intervention humaine est peut-être necessaire. Meme si la majorité ne fais pas gaffe, si juste une personne se pose la question c’est déjà mieux.





&nbsp;









CryoGen a écrit :



Quel tracking ? Déjà ca ouvre le navigateur par défaut (Firefox chez moi), de plus le login se limitera surement à renvoyer un token à l’app et c’est terminé… l’avantage de passer par le navigateur c’est qu’il est possible de stocker ses identifiants (+sync) ou d’avoir sa session “pré-ouverte” par cookie.

Il n’y a pas de tracking ici…





Le fait est que ça va inciter les gens à se connecter à leur compte google dans leur navigateur, et à le laisser connecter. Ça devrait donc favoriser le tracking de google sur leur navigation web (et non pas au sein de l’appli qui utilise oauth).

Ce n’est peut-être pas leur objectif principal, mais c’est sans aucun doute un point qui les arrangent bien.