Passer de ClientLogin à OAuth 2.0

Ikai Lan, YouTube Developer Relations – June 2013

Les API YouTube utilisent OAuth 2.0 pour autoriser les requêtes des utilisateurs. Nous sommes souvent interrogés sur l'ajout de l'authentification ClientLogin ou d'une méthode similaire dans les API YouTube à l'avenir. Toutefois, nous avons officiellement abandonné ClientLogin le 20 avril 2012 et nous ne prévoyons pas d'ajouter un tel mécanisme.

Nous pensons que la prise en charge de différents flux d'autorisation OAuth 2.0 est plus avantageuse pour les utilisateurs YouTube que ClientLogin. Ces flux sont compatibles avec les cas d'utilisation pour les applications de bureau, les applications Web uniquement, les applications mobiles et même les applications qui s'exécutent sur des appareils tels que les téléviseurs qui ne disposent pas de mécanismes d'entrée sophistiqués, ce qui est difficile à faire avec ClientLogin. Nous avons également constaté que ClientLogin cause plus de problèmes après le lancement pour de nombreux développeurs.

Utiliser OAuth 2.0 pour les scripts autonomes côté serveur

De nombreux développeurs utilisent ClientLogin pour autoriser les scripts de ligne de commande qui s'exécutent sur des serveurs sans navigateur. Avec OAuth 2.0, un navigateur est presque toujours impliqué, sauf lorsque vous travaillez sur une application Android qui utilise Google Play Services pour récupérer des jetons via GoogleAuthUtil..

Dans un flux Web uniquement, un site Web qui souhaite effectuer des appels d'API authentifiés au nom d'un utilisateur doit rediriger l'utilisateur vers une page d'authentification google.com qui explique ce à quoi l'application tente d'accéder. L'application Web reçoit ensuite un jeton qu'elle utilise pour effectuer des appels d'API. L'utilisateur peut ensuite révoquer l'accès de l'application à tout moment sur la page connected apps and sites.

Nos exemples de code Python montrent comment les scripts de ligne de commande peuvent lancer un navigateur et effectuer des appels d'API à partir d'une fenêtre de terminal, créer un serveur local pour écouter le code après la redirection d'autorisation et enregistrer automatiquement un jeton pour les futurs appels d'API. Vous trouverez ci-dessous une vidéo de démonstration :

Le jeton utilisé est une chaîne ASCII. S'il s'agit d'un jeton offline, il est portable. À l'aide du jeton récupéré, vous pourrez exécuter le script sur votre ordinateur, puis copier et utiliser le code sur un serveur distant sans interface graphique, à condition que le code instancie un client OAuth 2.0 avec le même ID et secret client. En plus de Python, les bibliothèques clientes des API Google pour d'autres langages de programmation fournissent également des méthodes d'assistance pour la gestion des jetons, qui peuvent être partagés entre les clients et même utilisés directement dans des bibliothèques HTTP de niveau inférieur dans un en-tête client ou en tant que paramètre d'URL.

Voici quelques exemples de scripts côté serveur qui utilisent des jetons hors connexion :

  • Un daemon qui surveille un répertoire pour détecter les nouvelles vidéos à importer automatiquement sur YouTube
  • Tâche cron qui met à jour les playlists quotidiennement avec de nouveaux contenus
  • Script qui surveille les données vidéo via l'API YouTube Analytics et avertit les gestionnaires de chaînes lorsque certains événements se produisent, par exemple lorsque la durée de visionnage globale dépasse une limite. Notez que dans ce cas, OAuth 2.0 est la seule méthode d'autorisation acceptée, car l'API Analytics n'est pas compatible avec ClientLogin.

La section sur les jetons d'accès de longue durée fournit plus de détails sur la façon de générer les jetons hors connexion qui peuvent être utilisés pour les processus côté serveur.

Bonnes pratiques concernant l'ID client et le code secret client

Tout code partageant la même paire d'ID client et de code secret peut utiliser les mêmes jetons d'accès. Il est préférable de limiter l'accès à l'ID client et au code secret du client au code qui s'exécute sur les machines et les appareils de votre organisation.

N'incluez pas votre ID client ni votre code secret du client dans le code de vos applications mobiles natives. Tous les développeurs qui effectuent une authentification OAuth 2.0 à partir d'un appareil mobile doivent utiliser l'ID client "Application installée", qui demande des informations supplémentaires pour vérifier que la requête provient uniquement d'une application publiée par leur équipe.

Sur les appareils Android, au lieu d'utiliser un ID et un code secret client, votre application est identifiée à l'aide d'une combinaison du nom du package et du hachage d'un certificat de signature. Sur les appareils iOS, l'ID du bundle et l'ID de l'App Store sont utilisés. Pour savoir comment récupérer ces informations, consultez la page d'aide Google Cloud console.

Les comptes de service ne fonctionnent pas avec l'API YouTube

Les comptes de service ne fonctionnent pas pour les appels de l'API YouTube Data, car ils nécessitent une chaîne YouTube associée. Or, vous ne pouvez pas associer de chaîne nouvelle ou existante à des comptes de service. Si vous utilisez un compte de service pour appeler l'API YouTube Data, le serveur d'API renvoie une erreur avec le type d'erreur défini sur unauthorized et la raison définie sur youtubeSignupRequired.

Accès hors connexion/de longue durée à l'API YouTube

OAuth 2.0 utilise des jetons de courte et de longue durée. Pour les opérations ponctuelles, les jetons d'accès de courte durée sont la meilleure option. Ces jetons expirent peu après leur attribution. Pour les tâches de longue durée, vous pouvez envisager d'acquérir un jeton d'actualisation, qui permet de récupérer des jetons d'accès de courte durée.

Pour vous assurer que votre application reçoit un jeton d'actualisation à longue durée de vie et non un jeton d'accès à courte durée de vie, utilisez le flux "Application installée" lorsque vous créez un ID client, et sélectionnez Other pour la valeur "Type d'application installée" :

Nous vous recommandons d'utiliser le flux "Application installée" pour ce cas d'utilisation. Si vous avez besoin d'un accès de longue durée à l'API YouTube dans une application Web, vous pouvez en récupérer un en définissant le paramètre access_type sur offline et le paramètre approval_prompt sur force dans la requête d'autorisation initiale ou la configuration de votre client. Certaines bibliothèques clientes gèrent la récupération et l'actualisation des jetons d'accès. Si vous souhaitez écrire votre propre code d'autorisation personnalisé, nous avons publié un article de blog sur le blog Google Code que vous pouvez utiliser comme base pour votre code.

Utiliser OAuth 2.0 avec des téléphones, des tablettes et d'autres appareils

Lorsqu'ils écrivent des applications Android, les développeurs peuvent tirer parti de Google Play services pour gérer les détails de l'autorisation. Les services Google Play proposent un flux d'autorisation standard pour toutes les API Google, y compris celles de la plate-forme YouTube. Cette approche offrira une expérience utilisateur bien supérieure aux utilisateurs de votre application Android par rapport à une authentification personnalisée à l'aide de ClientLogin.

Sur les appareils iOS, Google propose deux options :

Pour les appareils conçus pour servir de "second écran" ou les appareils tels que les téléviseurs sans mécanisme de saisie facile à utiliser, l'approche OAuth 2.0 pour les appareils est préférable. OAuth 2.0 pour les appareils fonctionne en présentant un code unique à un utilisateur lorsqu'une demande d'autorisation est requise. À ce stade, les utilisateurs sont invités à accéder à http://google.com/device sur un autre appareil, tel qu'un ordinateur portable ou un téléphone, et à saisir le code unique. L'application affiche un écran qui ressemble à ceci :

Pendant que l'utilisateur saisit le code sur un autre appareil, l'application interroge périodiquement le serveur pour vérifier si le code a été saisi. Une fois que c'est fait, il récupère un jeton pour effectuer des appels d'API. Pour voir une démonstration, consultez la démo, qui peut être exécutée sur n'importe quel appareil connecté au Web. L'API elle-même est indépendante de la plate-forme, ce qui la rend utile pour les appareils qui ne disposent pas de capacités de rendu Web. Nous avons publié un exemple de code en Python pour la démonstration, à utiliser comme référence.

Résumé

L'autorisation OAuth 2.0 offre de la flexibilité aux développeurs qui ont besoin d'une autorisation YouTube. Les développeurs qui connaissent ClientLogin peuvent constater que la configuration de leurs applications pour utiliser OAuth 2.0 nécessite un peu plus de travail pour commencer. Toutefois, une fois portées, les applications OAuth 2.0 offrent plus de flexibilité, de sécurité et de facilité d'utilisation sur plusieurs plates-formes pour les utilisateurs finaux.

Si vous avez d'autres questions sur OAuth 2.0 ou sur l'un des exemples de cet article, n'hésitez pas à les poser sur Stack Overflow avec le tag youtube-api.