Migração de ClientLogin para OAuth 2.0

Ikai Lan, YouTube Developer Relations – June 2013

A partir da versão 3 da API de dados, todos os métodos de autenticação com suporte para a API de dados do YouTube e para a API do Analytics usam o OAuth 2.0. Frequentemente nos perguntam se iremos incluir suporte para a autenticação do ClientLogin ou algo semelhante em APIs do YouTube daqui para frente. Porém, nós desaprovamos oficialmente o ClientLogin a partir de 20 de abril de 2012, e não temos planos de adicionar um mecanismo desse tipo.

Há inúmeras razões pelas quais acreditamos que apoiar vários fluxos de autorização do OAuth 2.0 é melhor para os usuários do YouTube que o ClientLogin. Esses fluxos suportam casos de uso para aplicativos de desktop, aplicativos somente para Web, aplicativos móveis nativos e até mesmo aplicativos executados em dispositivos como TVs que não possuem mecanismos sofisticados de entrada, algo difícil de fazer usando o ClientLogin. Além disso, descobrimos que o ClientLogin provoca mais dores de cabeça após o lançamento para muitos desenvolvedores, alguns dos quais descrevemos em nosso blog, ClientLogin #FAIL.

Uso de scripts autônomos do OAuth 2.0 para servidor

Muitos desenvolvedores usam o ClientLogin para autorizar scripts de linha de comando que são executados em servidores sem um navegador. Com o OAuth 2.0, sempre há um navegador envolvido, exceto quando você está trabalhando em um aplicativo Android que usa o Google Play Services para buscar tokens via GoogleAuthUtil.

Em um fluxo somente para Web, um site que deseja fazer chamadas de API autenticadas em nome de um usuário deve redirecionar o usuário para uma página de autenticação do google.com, que explica o que o aplicativo está tentando acessar. Em seguida, o aplicativo Web recebe um token, usado para fazer chamadas de API. O usuário pode revogar o acesso do aplicativo a qualquer momento usando a página de connected apps and sites.

Nossos exemplos de códigos Python demonstram como os scripts de linha de comando podem iniciar um navegador e fazer chamadas de API com o console, criar um servidor local para ouvir o código após o redirecionamento da autorização e salvar automaticamente um token para chamadas de API futuras. Você encontra um vídeo disso em ação abaixo:

O token usado é uma string ASCII. Se for um token offline, ele é portátil. Usando o token recuperado, você poderá executar o script em seu desktop e, em seguida, copiar e usar o código em um servidor remoto sem uma GUI, desde que o código instancie um cliente OAuth 2.0 com a mesma ID e o mesmo segredo do cliente. Além do Python, as bibliotecas de cliente API do Google para outras linguagens de programação também fornecem métodos auxiliares para o gerenciamento de tokens, que podem ser compartilhados entre clientes e até mesmo usados em bibliotecas HTTP de nível inferior diretamente em um cabeçalho do cliente ou como um parâmetro de URL.

Alguns exemplos de scripts do lado do servidor que usam tokens off-line:

  • Um daemon que monitora um diretório para novos vídeos para fazer upload automaticamente para o YouTube
  • Uma tarefa cron que atualiza listas de reprodução diariamente com novos conteúdos
  • Um script que monitora dados de vídeo através da API do YouTube Analytics e notifica os gerentes de canal quando determinados eventos ocorrem, como o tempo de exibição agregado superior a um limite. Observe que, neste caso, OAuth 2.0 é o único método de autorização suportado porque a API do Analytics não suporta o ClientLogin.

A seção sobre tokens de acesso de longa duração fornece mais detalhes sobre como gerar os tokens off-line que podem ser usados para os processos do lado do servidor.

ID do cliente e práticas secretas recomendadas ao cliente

Qualquer código que compartilha o mesmo ID do cliente e par secreto pode usar os mesmos tokens de acesso. É melhor restringir o acesso ao ID do cliente e aos segredos do cliente para o código que é executado em máquinas e dispositivos em sua organização.

Não inclua seu ID de cliente e segredo do cliente como parte de seu código de aplicativo móvel nativo. Todos os desenvolvedores que fazem a autenticação com o OAuth 2.0 a partir de um dispositivo móvel devem fazer uso do ID do cliente do "Aplicativo instalado", que solicita informações adicionais para verificar se a solicitação está vindo apenas de um aplicativo lançado por sua equipe.

Em dispositivos Android, em vez de usar um ID do cliente e o segredo do cliente, o aplicativo é identificado com uma combinação do nome do pacote e um hash de certificado de assinatura. Em dispositivos iOS, são usados o ID pacote e o ID da loja do aplicativo. A documentação oficial sobre como recuperar essas informações pode ser encontrada na página de ajuda do Google API console.

Contas de serviços não funcionam com a API do YouTube

As contas de serviço não funcionam para chamadas de API do YouTube porque elas exigem um canal do YouTube associado, e você não pode associar canais novos ou já existentes com contas de serviço. Usar uma conta de serviço para fazer chamadas de API do YouTube causará um erro do tipo unauthorized, e o motivo definido como youtubeSignupRequired.

Acesso off-line/longa duração para a API do YouTube

O OAuth 2.0 possui tokens de curta e longa duração. Para operações pontuais, os tokens de acesso de curta duração são a melhor opção. Esses tokens expiram logo depois de serem concedidos. Para trabalhos de longa execução, convém observar a aquisição de um token de atualização, usado para buscar tokens de acesso de curta duração.

Para garantir que seu aplicativo receberá um token de atualização de longa duração e não um token de acesso de curta duração, use o fluxo "Aplicativo instalado" ao criar um ID do cliente e selecione Outro para o valor de "Tipo de aplicativo instalado":

É recomendado que você use o fluxo "Aplicativo instalado" para este caso de uso. Se precisar de acesso de longa duração para a API do YouTube em um aplicativo da Web, você pode recuperar um definindo o parâmetro access_type para offline e o parâmetro approval_prompt para force na solicitação de autorização inicial ou na configuração de seu cliente. Algumas bibliotecas de cliente irão gerenciar a busca e atualização de tokens de acesso de atualização. Caso esteja interessado em escrever seu próprio código de autorização personalizado, publicamos um post no blog Google Code que você pode usar como base para seu código.

Uso do OAuth 2.0 com telefones, tablets e outros dispositivos

Ao escrever aplicativos do Android, os desenvolvedores podem aproveitar os Google Play services para lidar com os detalhes da autorização. Os serviços do Google Play oferecem um fluxo de autorização padrão para todas as APIs do Google, incluindo APIs para a plataforma do YouTube. Esta abordagem irá proporcionar uma experiência de usuário muito superior aos usuários de seu aplicativo Android que uma autenticação personalizada que utiliza o ClientLogin.

Em dispositivos iOS, o Google oferece duas opções:

Para dispositivos que atuam como dispositivos de "segunda tela" ou dispositivos como TVs sem mecanismos de entrada fáceis de usar, o OAuth 2.0 para dispositivos é a abordagem preferida. O OAuth 2.0 para dispositivos funciona através da apresentação de um código exclusivo para um usuário quando uma solicitação de autorização é necessária. Neste momento, os usuários devem navegar até http://google.com/device em outro dispositivo, como um computador portátil ou telefone, e digitar o código exclusivo O aplicativo exibe uma tela parecida com esta:

Enquanto o usuário está digitando o código em outro dispositivo, o aplicativo monitora periodicamente para ver se o código foi inserido. Depois de inserido, ele recupera um token para fazer chamadas de API. Para ver isso em ação, confira o demo, que pode ser executado em qualquer dispositivo habilitado para Web. A API em si é independente de plataforma, o que a torna útil para dispositivos que não possuem recursos de renderização na Web. Publicamos o código de exemplo em Python para a demo a ser usada como uma referência.

Resumo

A autorização com o OAuth 2.0 fornece flexibilidade para desenvolvedores que requerem autorização do YouTube. Desenvolvedores familiarizados com o ClientLogin podem achar que configurar seus aplicativos para usar o OAuth 2.0 requer um pouco mais de trabalho no início, mas depois de portados, os aplicativos do OAuth 2.0 oferecem mais flexibilidade, segurança e facilidade de uso em múltiplas plataformas para usuários finais.

Caso tenha mais alguma dúvida sobre o OAuth 2.0 ou qualquer um dos exemplos deste artigo, fique à vontade para perguntar com a tag youtube-api no StackOverflow ou em nossos horários comerciais do YouTube Developers Live.