Ce qui signifie que, si par exemple, le navigateur intégré dans Android pourra toujours traiter les requêtes d’authentification OAuth, les boutons de login d’applications tierces ne seront plus en mesure d’utiliser les WebViews pour les connexions via OAuth.
Par définition, Android WebView est un composant de système proposé par Chrome qui permet d'afficher les contenus Web dans les applications Android. Ce composant est préinstallé sur votre appareil Android.
Mais, c’est quoi l’authentification OAuth ?
OAuth est un protocole libre qui permet d’autoriser une application client à utiliser l’API sécurisée d’une autre application pour le compte d’un utilisateur.
En d’autres termes, l’OAuth n'est pas un protocole d'authentification, mais de "délégation d'autorisation".
L’intérêt majeur d’OAuth vient du fait que l’utilisateur n’a plus besoin de fournir ses informations d’identification à une application tierce car la connexion se passe sur l’application de l’API. Cela suppose que l’utilisateur lui a à priori fait confiance.
Actuellement, OAuth est à la version 2.0. En ce qui concerne les notions de base, sachez que l’OAuth propose 4 rôles :
- Ressource Owner (Le détenteur des données) : Il s’agit d’une entité capable d’accorder l’accès à une ressource protégée. Lorsque le propriétaire de la ressource est une personne, il est désigné en tant qu’utilisateur final.
- Ressource Server (Le serveur de ressources) : Il s’agit d’un serveur qui héberge les ressources protégées, qui est capable d’accepter et de répondre aux demandes de ressources protégées en utilisant des jetons d’accès (Access Token).
- Client (Le client) : Il s’agit d’une application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Cela peut-être une application PHP côté serveur, une application JavaScript côté client, une application mobile.
- Authorization Server (Le serveur d’autorisation) : Il s’agit d’un serveur qui délivre des jetons d’accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part.
Flux d'authentification d'un serveur Web OAuth 2.0
Le flux d'authentification de serveur Web est utilisé par des applications hébergées sur un serveur sécurisé. Un aspect critique du flux d'un serveur Web est la capacité du serveur à protéger le secret consommateur.
Vous pouvez également utiliser la vérification du code pour contrôler les valeurs du flux afin d'empêcher l'interception de code d'autorisation.
Les étapes individuelles sont présentées ci-dessous :
- Le serveur Web redirige l'utilisateur vers le site Web pour l'authentifier et autoriser le serveur à accéder aux données en son nom.
- Une fois l'accès approuvé par l'utilisateur, le serveur Web reçoit un rappel avec un code d'autorisation.
- Lorsqu'il obtient le code d'autorisation, le serveur Web renvoie le code d'autorisation pour obtenir une réponse de jeton.
- Après avoir validé le code d'autorisation, l’application renvoie une réponse de jeton. En l'absence d'erreur, la réponse de jeton inclut un code d'accès et des informations supplémentaires.
- Une fois le jeton accordé, le serveur Web accède à ses données.
Le serveur Web peut utiliser le jeton d'accès obtenu pour accéder aux données du site Web au nom de l'utilisateur et utiliser un jeton d'actualisation pour obtenir un nouveau jeton d'accès si le premier n'est plus valide, quelle qu'en soit la raison.
Alors, que va réellement faire Google ?
La WebView est un composant d’Android présent dans toutes les versions de l’OS mobile. Il s’agit d’un module permettant d’afficher du HTML, du CSS ou d’exécuter du Javascript, bref d’afficher une page web, sans avoir à développer cet affichage soi-même.
Ce qui a pour objectif de simplifier la tâche des développeurs en leur permettant d’accéder directement aux APIs natives plutôt que de passer par différents systèmes d’exploitation.
Mais, Google décide mettre fin à l’utilisation de son système d’authentification via OAuth.
Il justifie cette décision par le fait qu’il s’agit à nouveau de faciliter les choses du côté des utilisateurs.
En effet, selon Google, accepter le support d’OAuth dans n’importe quel navigateur présent sur l’appareil signifie que la connexion ou l’authentification peut persister sur cet appareil (une WebView ne peut conserver l’authentification à travers plusieurs sessions).
En d’autres termes, une seule connexion à Google devrait suffire pour utiliser toutes les applications installées.
Le post de Google précise ceci :
Les utilisateurs ont juste besoin de s’authentifier ou se connecter une seule fois par appareil à Google, ce qui va améliorer les taux de conversion des Flux d'authentification et des autorisations dans votre application.
…
Alors que la méthode obsolète de l’utilisation de navigateurs embarqués pour OAuth signifiait que l’utilisateur devait “Se connecter” à Google à chaque fois, au lieu d’utiliser la session existante de l’utilisateur en cours dans l’appareil.
Le navigateur de l’appareil fournit également une sécurité améliorée que les applications sont en mesure d’inspecter et de modifier le contenu dans une WebView, mais pas le contenu affiché dans l’Explorateur.
Calendrier du blocage progressif des Web-Views
Voici le calendrier du déploiement de la suppression des WebViews pour les requêtes d’OAuth à Google :
- À partir de 20 octobre 2016, Google empêchera les nouveaux clients OAuth d’utiliser les Web-Views sur les plateformes avec une alternative viable et les utilisateurs seront avertis par une notification pour les clients OAuth existants.
- A compter du 20 avril 2017, Google commencera à bloquer les requêtes OAuth d’utiliser les WebViews pour tous les OAuth clients sur les plateformes sur lesquelles des alternatives viables existent.
