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. On nous demande fréquemment si nous allons assurer la compatibilité avec l'authentification ClientLogin ou quelque chose de similaire dans les API YouTube à l'avenir. Toutefois, nous avons officiellement abandonné le système ClientLogin à compter du 20 avril 2012, et nous ne prévoyons pas d'ajouter ce type de mécanisme.

Pour de nombreuses raisons, nous pensons qu'il est préférable d'accepter différents flux d'autorisation OAuth 2.0 pour les utilisateurs YouTube que ClientLogin. Ces flux sont compatibles avec les applications de bureau, les applications Web uniquement, les applications mobiles natives et même les applications exécutées sur des appareils comme les téléviseurs sans mécanisme de saisie complexe, ce qui est difficile à réaliser avec ClientLogin. En outre, nous avons constaté que ClientLogin entraînait plus de problèmes après le lancement pour de nombreux développeurs. Nous en avons décrit certains dans notre article de blog ClientLogin #FAIL.

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, le navigateur sera 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, un site Web qui souhaite effectuer des appels d'API authentifiés pour le compte d'un utilisateur doit le rediriger vers une page d'authentification google.com qui explique à 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 depuis 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 bureau, puis copier et utiliser le code sur un serveur distant sans IUG, à condition que le code instancie un client OAuth 2.0 avec le même ID client et le même code secret. En plus de Python, les bibliothèques clientes des API Google pour d'autres langages de programmation fournissent des méthodes d'assistance pour la gestion des jetons. Ces bibliothèques peuvent être partagées entre les clients et même utilisées dans des bibliothèques HTTP de niveau inférieur, directement dans un en-tête client ou en tant que paramètre d'URL.

Exemples de scripts côté serveur utilisant des jetons hors connexion:

  • Un daemon surveillant un répertoire pour rechercher de nouvelles vidéos à mettre en ligne automatiquement sur YouTube
  • Tâche Cron qui met à jour les playlists quotidiennement avec de nouveaux contenus
  • Script permettant de surveiller les données vidéo via l'API YouTube Analytics et d'informer les administrateurs de la chaîne que certains événements se produisent (par exemple, durée de visionnage cumulée dépassant une limite). Notez que, dans ce cas, OAuth 2.0 est la seule méthode d'autorisation compatible, 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 génération de jetons hors connexion pouvant être utilisés pour les processus côté serveur.

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

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

N'incluez pas votre ID et votre code secret client dans le code de votre application mobile native. Tous les développeurs qui procèdent à 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 votre équipe.

Sur les appareils Android, au lieu d'utiliser un ID client et un code secret, votre application est identifiée à l'aide d'une combinaison du nom du package et du hachage du certificat de signature. Sur les appareils iOS, l'ID de bundle et l'ID App Store sont utilisés. La documentation officielle sur la récupération de ces informations est disponible sur la page d'aide Google API Console.

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

Les comptes de service ne fonctionnent pas pour les appels à l'API YouTube Data, car ils nécessitent une chaîne YouTube associée. Vous ne pouvez pas associer de nouvelles chaînes ou de chaînes existantes à des comptes de service. Si vous appelez l'API YouTube Data à l'aide d'un compte de service, le serveur d'API affiche une erreur en définissant le type d'erreur sur unauthorized et le motif sur youtubeSignupRequired.

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

OAuth 2.0 dispose de jetons à court terme et à long terme. Pour les opérations ponctuelles, les jetons d'accès de courte durée constituent la meilleure option. Ces jetons expirent peu de temps après avoir été accordés. Pour les tâches de longue durée, vous souhaiterez peut-être acquérir un jeton d'actualisation, qui sera utilisé pour récupérer les jetons d'accès de courte durée.

Pour vous assurer que votre application reçoit un jeton d'actualisation de longue durée et non un jeton d'accès de courte durée, utilisez le flux "Application installée" lors de la création d'un ID client, et sélectionnez Other comme valeur de "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 permanent à 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 dans 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 rédiger votre propre code d'autorisation personnalisé, nous avons publié un article 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

Lors de l'écriture d'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 les API de la plate-forme YouTube. Cette approche offre aux utilisateurs de votre application Android une bien meilleure expérience qu'une authentification personnalisée avec ClientLogin.

Sur les appareils iOS, Google propose deux options:

OAuth 2.0 pour les appareils est l'approche à privilégier pour les appareils conçus pour fonctionner en tant que "second écran" ou pour les appareils tels que les téléviseurs sans mécanisme de saisie simple à utiliser. OAuth 2.0 pour les appareils fonctionne en présentant un code unique à un utilisateur lorsqu'une demande d'autorisation est requise. À ce stade, il est invité à accéder à http://google.com/device sur un autre appareil (par exemple, un ordinateur portable ou un téléphone) et de saisir le code unique. L'application présente un écran semblable à celui-ci:

Pendant que l'utilisateur saisit le code sur un autre appareil, l'application interroge régulièrement l'appareil pour déterminer si celui-ci a été saisi. Une fois que c'est le cas, il récupère un jeton pour les appels d'API. Pour voir un exemple concret, regardez la démonstration, qui peut être exécutée sur n'importe quel appareil connecté à Internet. 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 fonctionnalités de rendu Web. Nous avons publié un exemple de code en Python pour que la démonstration soit utilisée comme référence.

Résumé

L'autorisation OAuth 2.0 est flexible pour les développeurs qui nécessitent une autorisation YouTube. Les développeurs qui connaissent ClientLogin peuvent se rendre compte que la configuration de leurs applications pour utiliser OAuth 2.0 nécessite un peu plus de travail au démarrage, mais une fois qu'ils ont été transférés, les applications OAuth 2.0 offrent plus de flexibilité, de sécurité et de facilité d'utilisation sur plusieurs plates-formes aux utilisateurs finaux.

Si vous avez d'autres questions sur OAuth 2.0 ou des exemples dans cet article, n'hésitez pas à ajouter le tag youtube-api sur StackOverflow.