Ikai Lan, YouTube Developer Relations – June 2013
YouTube APIs verwenden OAuth 2.0, um Nutzeranfragen zu autorisieren. Wir werden häufig gefragt, ob wir in Zukunft die ClientLogin-Authentifizierung oder eine ähnliche Funktion in YouTube APIs unterstützen werden. Wir haben ClientLogin jedoch am 20. April 2012 offiziell eingestellt und es ist nicht geplant, einen solchen Mechanismus hinzuzufügen.
Es gibt zahlreiche Gründe, warum wir der Meinung sind, dass die Unterstützung verschiedener OAuth 2.0-Autorisierungsabläufe für YouTube-Nutzer besser ist als ClientLogin. Diese Abläufe unterstützen Anwendungsfälle für Desktopanwendungen, reine Webanwendungen, native mobile Anwendungen und sogar Anwendungen, die auf Geräten wie Fernsehern ausgeführt werden, die keine ausgefeilten Eingabemechanismen haben. Das ist mit ClientLogin schwierig. Außerdem haben wir festgestellt, dass ClientLogin nach der Markteinführung für viele Entwickler mehr Probleme verursacht. Einige davon beschreiben wir in unserem Blogpost ClientLogin #FAIL.
OAuth 2.0 für serverseitige, eigenständige Scripts verwenden
Viele Entwickler verwenden ClientLogin, um Befehlszeilenscripts zu autorisieren, die auf Servern ohne Browser ausgeführt werden. Bei OAuth 2.0 ist fast immer ein Browser beteiligt. Eine Ausnahme ist, wenn Sie an einer Android-Anwendung arbeiten, die Google Play Services verwendet, um Tokens über GoogleAuthUtil. abzurufen.
Bei einem Web-only-Vorgang muss eine Website, die im Namen eines Nutzers authentifizierte API-Aufrufe ausführen möchte, den Nutzer zu einer google.com-Authentifizierungsseite weiterleiten, auf der erläutert wird, auf was die Anwendung zugreifen möchte. Die Webanwendung erhält dann ein Token, mit dem sie API-Aufrufe ausführen kann. Der Nutzer kann den Zugriff der Anwendung dann jederzeit über die Seite connected apps and sites widerrufen.
In unseren Python-Codebeispielen wird gezeigt, wie mit Befehlszeilenscripts ein Browser gestartet und API-Aufrufe über ein Terminalfenster ausgeführt werden, ein lokaler Server erstellt wird, der nach dem Autorisierungsweiterleitungscode wartet, und ein Token automatisch für zukünftige API-Aufrufe gespeichert wird. Unten sehen Sie ein Video, das dies veranschaulicht:
Das verwendete Token ist ein ASCII-String. Wenn es sich um ein offline-Token handelt, ist es tragbar. Mit dem abgerufenen Token können Sie das Script auf Ihrem Computer ausführen und den Code dann auf einem Remote-Server ohne Benutzeroberfläche kopieren und verwenden, sofern der Code einen OAuth 2.0-Client mit derselben Client-ID und demselben Geheimschlüssel instanziiert. Neben Python bieten die Google API-Clientbibliotheken für andere Programmiersprachen auch Hilfsmethoden zum Verwalten von Tokens, die zwischen Clients freigegeben und sogar in HTTP-Bibliotheken der unteren Ebene direkt in einem Clientheader oder als URL-Parameter verwendet werden können.
Beispiele für serverseitige Scripts, die Offline-Tokens verwenden:
- Ein Daemon, der ein Verzeichnis auf neue Videos überwacht, die automatisch auf YouTube hochgeladen werden sollen
- Ein Cronjob, mit dem Playlists täglich mit neuen Inhalten aktualisiert werden
- Ein Script, das Videodaten über die YouTube Analytics API überwacht und Kanalmanager benachrichtigt, wenn bestimmte Ereignisse auftreten, z. B. wenn die Gesamtwiedergabezeit ein bestimmtes Limit überschreitet. In diesem Fall ist OAuth 2.0 die einzige unterstützte Autorisierungsmethode, da die Analytics API ClientLogin nicht unterstützt.
Im Abschnitt zu langlebigen Zugriffstokens finden Sie weitere Informationen zum Generieren der Offline-Tokens, die für serverseitige Prozesse verwendet werden können.
Best Practices für Client-IDs und Clientschlüssel
Für alle Codes mit derselben Client-ID und demselben geheimen Schlüssel können dieselben Zugriffstokens verwendet werden. Beschränken Sie den Zugriff auf die Client-ID und Clientschlüssel am besten auf Code, der auf Computern und Geräten in Ihrer Organisation ausgeführt wird.
Fügen Sie Ihre Client-ID und Ihren Clientschlüssel nicht in den Code Ihrer nativen mobilen Anwendung ein. Alle Entwickler, die die OAuth 2.0-Authentifizierung von einem Mobilgerät aus durchführen, sollten die Client-ID „Installed application“ verwenden. Dabei werden zusätzliche Informationen abgefragt, um zu bestätigen, dass die Anfrage nur von einer von Ihrem Team veröffentlichten Anwendung stammt.
Auf Android-Geräten wird Ihre Anwendung anhand einer Kombination aus Paketnamen und Hash-Wert des Signaturzertifikats identifiziert, anstatt einer Client-ID und eines Clientschlüssels. Auf iOS-Geräten werden die Bundle-ID und die App-Shop-ID verwendet. Die offizielle Dokumentation zum Abrufen dieser Informationen finden Sie auf der Google API Console Hilfeseite.
Dienstkonten funktionieren nicht mit der YouTube API
Dienstkonten funktionieren nicht für YouTube Data API-Aufrufe, da Dienstkonten mit einem YouTube-Kanal verknüpft sein müssen. Du kannst neue oder vorhandene Kanäle nicht mit Dienstkonten verknüpfen. Wenn du die YouTube Data API über ein Dienstkonto aufrufst, gibt der API-Server einen Fehler zurück. Der Fehlertyp ist dabei auf unauthorized und der Grund auf youtubeSignupRequired festgelegt.
Offlinezugriff/langlebiger Zugriff auf die YouTube API
OAuth 2.0 bietet kurzlebige und langlebige Tokens. Für einmalige Vorgänge sind kurzlebige Zugriffstokens die beste Option. Diese Tokens laufen kurz nach der Gewährung ab. Für langlaufende Jobs sollten Sie ein Aktualisierungstoken abrufen, mit dem kurzlebige Zugriffstokens abgerufen werden.
Damit Ihre Anwendung ein langlebiges Aktualisierungstoken und kein kurzlebiges Zugriffstoken erhält, verwenden Sie beim Erstellen einer Client-ID den Ablauf „Installierte Anwendung“ und wählen Sie Other für den Wert „Typ der installierten Anwendung“ aus:
Für diesen Anwendungsfall empfehlen wir den Ablauf „Installierte Anwendung“. Wenn du in einer Webanwendung einen lang anhaltenden Zugriff auf die YouTube API benötigst, kannst du ihn abrufen, indem du in der ersten Autorisierungsanfrage oder in deiner Clientkonfiguration den Parameter access_type auf offline und den Parameter approval_prompt auf force festlegst. Einige Clientbibliotheken verwalten das Abrufen und Aktualisieren von Zugriffstokens. Wenn Sie Ihren eigenen benutzerdefinierten Autorisierungscode schreiben möchten, haben wir einen Blogpost im Google Code-Blog veröffentlicht, den Sie als Grundlage für Ihren Code verwenden können.
OAuth 2.0 mit Smartphones, Tablets und anderen Geräten verwenden
Beim Erstellen von Android-Anwendungen können Entwickler Google Play services verwenden, um die Autorisierungsdetails zu verarbeiten. Die Google Play-Dienste bieten einen Standardautorisierungsablauf für alle Google APIs, einschließlich APIs für die YouTube-Plattform. Dieser Ansatz bietet Nutzern Ihrer Android-Anwendung eine weitaus bessere Nutzererfahrung als eine benutzerdefinierte Authentifizierung mit ClientLogin.
Auf iOS-Geräten bietet Google zwei Optionen:
- die Google+ Platform for iOS, über die die Anmeldung für Google-Produkte integriert und auch soziale Funktionen aktiviert werden
- die gtm-oauth2 toolkit, die eine Autorisierungs-UIWebView bereitstellt und Tokens verwaltet
Für Geräte, die als „Second Screen“ dienen sollen, oder Geräte wie Fernseher ohne nutzerfreundliche Eingabemechanismen ist OAuth 2.0 für Geräte der bevorzugte Ansatz. Bei OAuth 2.0 für Geräte wird einem Nutzer ein eindeutiger Code angezeigt, wenn eine Autorisierungsanfrage erforderlich ist. Auf diesem Bildschirm werden Nutzer aufgefordert, http://google.com/device auf einem anderen Gerät wie einem Laptop oder Smartphone aufzurufen und den eindeutigen Code einzugeben. Die Anwendung zeigt einen Bildschirm an, der in etwa so aussieht:
Während der Nutzer den Code auf einem anderen Gerät eingibt, prüft die Anwendung regelmäßig, ob der Code eingegeben wurde. Anschließend wird ein Token für API-Aufrufe abgerufen. In der Demo, die auf jedem webfähigen Gerät ausgeführt werden kann, sehen Sie, wie das funktioniert. Die API selbst ist plattformunabhängig und daher auch für Geräte geeignet, die keine Web-Rendering-Funktionen haben. Wir haben Beispielcode in Python für die Demo als Referenz veröffentlicht.
Zusammenfassung
Die OAuth 2.0-Autorisierung bietet Entwicklern, die eine YouTube-Autorisierung benötigen, Flexibilität. Entwickler, die mit ClientLogin vertraut sind, stellen möglicherweise fest, dass die Einrichtung ihrer Anwendungen für die Verwendung von OAuth 2.0 etwas mehr Aufwand erfordert. Nach der Portierung bieten OAuth 2.0-Anwendungen jedoch mehr Flexibilität, Sicherheit und Nutzerfreundlichkeit auf mehreren Plattformen.
Wenn Sie weitere Fragen zu OAuth 2.0 oder zu den Beispielen in diesem Artikel haben, können Sie sie mit dem Tag youtube-api auf StackOverflow stellen.