Ikai Lan, YouTube Developer Relations – June 2013
Le API di YouTube utilizzano OAuth 2.0 per autorizzare le richieste degli utenti. Ci viene spesso chiesto se in futuro aggiungeremo il supporto per l'autenticazione ClientLogin o qualcosa di simile nelle API di YouTube. Tuttavia, abbiamo ritirato ufficialmente ClientLogin dal 20 aprile 2012 e non prevediamo di aggiungere un simile meccanismo.
Esistono numerosi motivi per cui riteniamo che supportare vari flussi di autorizzazione OAuth 2.0 sia meglio per gli utenti di YouTube rispetto a ClientLogin. Questi flussi supportano casi d'uso per applicazioni desktop, applicazioni solo web, applicazioni mobile native e persino applicazioni che funzionano su dispositivi come le televisioni che non dispongono di meccanismi di input sofisticati, cosa difficile da fare utilizzando ClientLogin. Inoltre, abbiamo riscontrato che ClientLogin causa più problemi dopo il lancio per molti sviluppatori, alcuni dei quali descritti nel nostro post del blog ClientLogin #FAIL.
Utilizzo di OAuth 2.0 per script autonomi lato server
Molti sviluppatori utilizzano ClientLogin per autorizzare gli script a riga di comando che vengono eseguiti su server senza un browser. Con OAuth 2.0, sarà quasi sempre coinvolto un browser, ad eccezione del caso in cui tu stia lavorando a un'applicazione per Android che utilizza Google Play Services per recuperare i token tramite GoogleAuthUtil.
In un flusso solo web, un sito web che vuole effettuare chiamate API autenticate per conto di un utente deve reindirizzare l'utente a una pagina di autenticazione google.com che spiega a cosa sta tentando di accedere l'applicazione. L'applicazione web riceve quindi un token, che utilizza per effettuare chiamate API. L'utente può quindi revocare l'accesso dell'applicazione in qualsiasi momento utilizzando la pagina connected apps and sites.
I nostri esempi di codice Python mostrano come gli script a riga di comando possono avviare un browser ed effettuare chiamate API da una finestra del terminale, creare un server locale per ascoltare il codice dopo il reindirizzamento di autorizzazione e salvare automaticamente un token per le chiamate API future. Di seguito è riportato un video che mostra come funziona:
Il token utilizzato è una stringa ASCII. Se si tratta di un token offline
, è portabile. Utilizzando il token recuperato, potrai eseguire lo script sul computer, quindi copiare e utilizzare il codice su un server remoto senza interfaccia utente grafica, a condizione che il codice instantizi un client OAuth 2.0 con lo stesso ID client e lo stesso segreto. Oltre a Python, le librerie client delle API di Google per altri linguaggi di programmazione forniscono anche metodi di assistenza per la gestione dei token, che possono essere condivisi tra i client e persino utilizzati nelle librerie HTTP di livello inferiore direttamente in un'intestazione client o come parametro URL.
Ecco alcuni esempi di script lato server che utilizzano token offline:
- Un daemon che monitora una directory alla ricerca di nuovi video da caricare automaticamente su YouTube
- Un cron job che aggiorna quotidianamente le playlist con nuovi contenuti
- Uno script che monitora i dati dei video tramite l'API di YouTube Analytics e invia una notifica ai gestori del canale quando si verificano determinati eventi, ad esempio quando il tempo di visualizzazione aggregato supera un limite. Tieni presente che in questo caso OAuth 2.0 è l'unico metodo di autorizzazione supportato perché l'API Analytics non supporta ClientLogin.
La sezione sui token di accesso a lungo termine fornisce ulteriori dettagli su come generare i token offline che possono essere utilizzati per le procedure lato server.
Best practice per ID client e client secret
Qualsiasi codice che condivide la stessa coppia di ID cliente e segreto può utilizzare gli stessi token di accesso. È meglio limitare l'accesso all'ID client e ai client secret al codice in esecuzione su macchine e dispositivi all'interno della tua organizzazione.
Non includere l'ID client e il client secret nel codice delle tue applicazioni mobile native. Tutti gli sviluppatori che eseguono l'autenticazione OAuth 2.0 da un dispositivo mobile devono utilizzare l'ID client "App installata", che richiede informazioni aggiuntive per verificare che la richiesta provenga solo da un'applicazione rilasciata dal tuo team.
Sui dispositivi Android, anziché utilizzare un ID client e un client secret, l'applicazione viene identificata utilizzando una combinazione del nome del pacchetto e dell'hash del certificato di firma. Sui dispositivi iOS vengono utilizzati l'ID bundle e l'ID store. La documentazione ufficiale sul recupero di queste informazioni è disponibile nella pagina di assistenza di Google API Console.
Gli account di servizio non funzionano con l'API YouTube
I service account non funzionano per le chiamate all'API YouTube Data perché richiedono un canale YouTube associato e non puoi associare canali nuovi o esistenti ai service account. Se utilizzi un account di servizio per chiamare l'API YouTube Data, il server API restituisce un errore con il tipo di errore impostato su unauthorized
e il motivo impostato su youtubeSignupRequired
.
Accesso offline/a lungo termine all'API YouTube
OAuth 2.0 ha token a durata breve e token a durata lunga. Per le operazioni una tantum, i token di accesso a breve durata sono l'opzione migliore. Questi token scadono poco dopo la loro concessione. Per i job che richiedono molto tempo, ti consigliamo di acquisire un token di aggiornamento, che viene utilizzato per recuperare token di accesso a breve durata.
Per assicurarti che la tua applicazione riceva un token di aggiornamento a lungo termine e non un token di accesso a breve termine, utilizza il flusso "Applicazione installata" quando crei un ID client e seleziona Other
per il valore "Tipo di applicazione installata":
Per questo caso d'uso, ti consigliamo di utilizzare il flusso "Applicazione installata". Se hai bisogno di un accesso permanente all'API YouTube in un'applicazione web, puoi recuperarne uno impostando il parametro access_type
su offline
e il parametro approval_prompt
su force
nella richiesta di autorizzazione iniziale o nella configurazione del client. Alcune librerie client gestiscono il recupero e l'aggiornamento dei token di accesso. Se vuoi scrivere il tuo codice di autorizzazione personalizzato, abbiamo pubblicato un post del blog Google Code che puoi utilizzare come base per il tuo codice.
Utilizzare OAuth 2.0 con smartphone, tablet e altri dispositivi
Quando scrivono applicazioni per Android, gli sviluppatori possono utilizzare Google Play services per gestire i dettagli dell'autorizzazione. Google Play Services offre un flusso di autorizzazione standard per tutte le API di Google, incluse le API per la piattaforma YouTube. Questo approccio offrirà agli utenti della tua applicazione per Android un'esperienza utente molto migliore rispetto a un'autenticazione personalizzata che utilizza ClientLogin.
Sui dispositivi iOS, Google offre due opzioni:
- Google+ Platform for iOS, che integra l'accesso ai prodotti Google e attiva anche le funzionalità social
- gtm-oauth2 toolkit, che fornisce un'autorizzazione UIWebView e gestisce i token
Per i dispositivi che devono fungere da "secondo schermo" o per dispositivi come le TV senza meccanismi di input facili da usare, l'approccio preferito è OAuth 2.0 per i dispositivi. OAuth 2.0 per i dispositivi funziona presentando un codice univoco per un utente quando è richiesta una richiesta di autorizzazione. A questo punto, agli utenti viene chiesto di visitare http://google.com/device su un altro dispositivo, ad esempio un laptop o uno smartphone, e di inserire il codice univoco. L'applicazione presenta una schermata simile alla seguente:
Mentre l'utente inserisce il codice su un altro dispositivo, l'applicazione esegue periodicamente dei controlli per verificare se il codice è stato inserito. Una volta ottenuto il token, recupera un token per effettuare chiamate API. Per vedere come funziona, dai un'occhiata alla demo, che può essere eseguita su qualsiasi dispositivo con accesso a internet. L'API stessa è indipendente dalla piattaforma, il che la rende utile per i dispositivi che non dispongono di funzionalità di rendering web. Abbiamo pubblicato codice di esempio in Python per la demo da utilizzare come riferimento.
Riepilogo
L'autorizzazione OAuth 2.0 offre flessibilità agli sviluppatori che richiedono l'autorizzazione di YouTube. Gli sviluppatori che hanno dimestichezza con ClientLogin potrebbero scoprire che la configurazione delle applicazioni per l'utilizzo di OAuth 2.0 richiede un po' più di lavoro per iniziare, ma una volta eseguita la portabilità, le applicazioni OAuth 2.0 offrono agli utenti finali maggiore flessibilità, sicurezza e usabilità su più piattaforme.
Se hai altre domande su OAuth 2.0 o su uno degli esempi di questo articolo, non esitare a chiedere utilizzando il tag youtube-api su StackOverflow.