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 la possibilité d'ajouter l'authentification ClientLogin ou un système similaire dans les API YouTube. Toutefois, nous avons officiellement abandonné ClientLogin le 20 avril 2012, et nous ne prévoyons pas d'ajouter un tel mécanisme.
Pour diverses raisons, nous pensons que la prise en charge de différents flux d'autorisation OAuth 2.0 est plus adaptée aux utilisateurs de YouTube que ClientLogin. Ces flux prennent en charge les cas d'utilisation des applications de bureau, des applications Web uniquement, des applications mobiles natives et même des applications exécutées sur des appareils tels que des téléviseurs qui ne disposent pas de mécanismes d'entrée sophistiqués, ce qui est difficile à faire avec ClientLogin. De plus, nous avons constaté que ClientLogin posait plus de problèmes après le lancement pour de nombreux développeurs, dont certains sont décrits 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 exécutés 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 extraire 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 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 à l'aide de 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 illustrant cette procédure:
Le jeton utilisé est une chaîne ASCII. S'il s'agit d'un jeton offline, il est portatif. Grâce au jeton récupéré, vous pourrez exécuter le script sur votre ordinateur, 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 secret. 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 gérer les jetons, qui peuvent être partagés entre les clients et même utilisés dans des bibliothèques HTTP de bas niveau directement 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 à mettre en ligne automatiquement sur YouTube
- Une 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 envoie des notifications aux gestionnaires de chaîne 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 à long terme explique plus en détail comment générer les jetons hors connexion pouvant être utilisés pour les processus côté serveur.
Bonnes pratiques concernant l'ID client et le secret client
Tout code qui partage le même ID client et la même paire de secrets peut utiliser les mêmes jetons d'accès. Il est préférable de limiter l'accès à l'ID client et aux secrets client au code exécuté sur les machines et les appareils de votre organisation.
N'incluez pas votre ID client et votre code secret dans le code de vos applications mobiles natives. Tous les développeurs effectuant 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 ne provient que d'une application publiée par votre équipe.
Sur les appareils Android, au lieu d'utiliser un ID client et un secret client, votre application est identifiée à l'aide d'une combinaison du nom du package et d'un hachage de certificat de signature. Sur les appareils iOS, l'ID de 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 API Console.
Les comptes de service ne fonctionnent pas avec l'API YouTube
Les comptes de service ne fonctionnent pas pour les appels d'API YouTube Data, car ils nécessitent une chaîne YouTube associée, et vous ne pouvez pas associer de chaînes nouvelles ou existantes à des comptes de service. Si vous utilisez un compte de service pour appeler l'API YouTube Data, le serveur de l'API renvoie une erreur avec le type d'erreur défini sur unauthorized et le motif sur youtubeSignupRequired.
Accès hors connexion/à long terme à l'API YouTube
OAuth 2.0 utilise des jetons de courte durée 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 de temps après leur octroi. Pour les tâches de longue durée, vous pouvez envisager d'acquérir un jeton d'actualisation, qui permet d'extraire des jetons d'accès de courte durée.
Pour vous assurer que votre application reçoit un jeton d'actualisation à durée de vie longue et non un jeton d'accès à durée de vie courte, utilisez le flux "Application installée" lorsque vous créez un ID client, puis 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 à long terme à 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 votre configuration client. Certaines bibliothèques clientes gèrent l'extraction et l'actualisation des jetons d'accès. Si vous souhaitez écrire votre propre code d'autorisation personnalisé, vous pouvez vous appuyer sur un article de blog sur le blog Google Code.
Utiliser OAuth 2.0 avec des téléphones, des tablettes et d'autres appareils
Lorsque vous écrivez des applications Android, vous pouvez utiliser 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 une expérience utilisateur bien meilleure aux utilisateurs de votre application Android qu'une authentification personnalisée à l'aide de ClientLogin.
Sur les appareils iOS, Google propose deux options:
- Google+ Platform for iOS, qui intègre la connexion pour les produits Google et active également les fonctionnalités de réseau social
- gtm-oauth2 toolkit, qui fournit une UIWebView d'autorisation et gère les jetons
Pour les appareils destinés à servir de "deuxième écran" ou les appareils tels que les téléviseurs sans mécanismes d'entrée faciles à utiliser, OAuth 2.0 pour les appareils est l'approche à privilégier. OAuth 2.0 pour les appareils présente 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 présente un écran semblable à celui-ci:
Pendant que l'utilisateur saisit le code sur un autre appareil, l'application effectue des sondages périodiques pour vérifier si le code a été saisi. Une fois l'authentification effectuée, le client récupère un jeton pour effectuer des appels d'API. Pour voir comment cela fonctionne, regardez la démonstration, qui peut être exécutée sur n'importe quel appareil compatible avec le 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 fonctionnalité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 une 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 qu'elles utilisent OAuth 2.0 nécessite un peu plus d'efforts au départ. Toutefois, une fois le portage effectué, les applications OAuth 2.0 offrent aux utilisateurs finaux plus de flexibilité, de sécurité et d'usabilité sur plusieurs plates-formes.
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 en ajoutant la balise youtube-api sur StackOverflow.