Ikai Lan, YouTube Developer Relations – June 2013
Interfejsy API YouTube autoryzują żądania użytkowników za pomocą protokołu OAuth 2.0. Często zadawane jest pytanie, czy w przyszłości dodamy obsługę uwierzytelniania ClientLogin lub czegoś podobnego w interfejsach API YouTube. Jednak oficjalnie wycofaliśmy ClientLogin 20 kwietnia 2012 roku i nie planujemy dodawać tego mechanizmu.
Istnieje wiele powodów, dla których uważamy, że obsługa różnych procesów autoryzacji OAuth 2.0 jest lepszym rozwiązaniem dla użytkowników YouTube niż ClientLogin. Te procesy obsługują przypadki użycia aplikacji na komputery, aplikacji internetowych, natywnych aplikacji mobilnych, a nawet aplikacji działających na urządzeniach takich jak telewizory, które nie mają zaawansowanych mechanizmów wprowadzania danych. Jest to trudne do wykonania za pomocą ClientLogin. Ponadto stwierdziliśmy, że ClientLogin powoduje więcej problemów po premierze dla wielu deweloperów. Niektóre z nich opisaliśmy w poście na blogu ClientLogin #FAIL.
Używanie protokołu OAuth 2.0 w samodzielnych skryptach po stronie serwera
Wielu deweloperów używa ClientLogin do autoryzowania skryptów wiersza poleceń, które działają na serwerach bez przeglądarki. W przypadku OAuth 2.0 prawie zawsze wymagana jest przeglądarka – wyjątkiem sytuacji, gdy pracujesz nad aplikacją na Androida, która używa Google Play Services do pobierania tokenów za pomocą GoogleAuthUtil..
W procesie tylko w internecie witryna, która chce wykonywać wywołania interfejsu API w imieniu użytkownika, musi przekierowywać użytkownika na stronę uwierzytelniania google.com, na której jest wyjaśnione, do czego aplikacja próbuje uzyskać dostęp. Następnie aplikacja internetowa otrzymuje token, którego używa do wywoływania interfejsu API. Użytkownik może w dowolnym momencie cofnąć dostęp aplikacji na stronie connected apps and sites.
Nasze przykłady kodu w Pythonie pokazują, jak skrypty w linii poleceń mogą uruchamiać przeglądarkę i wywoływać interfejs API z okna terminala, tworzyć lokalny serwer, który będzie nasłuchiwać kodu po przekierowaniu autoryzacji, oraz automatycznie zapisywać token na potrzeby kolejnych wywołań interfejsu API. Poniżej znajdziesz film pokazujący, jak to działa:
Używany token to ciąg znaków ASCII. Jeśli jest to token offline, można go przenosić. Za pomocą pobranego tokena możesz uruchomić skrypt na komputerze, a potem skopiować kod i użyć go na serwerze zdalnym bez interfejsu GUI, pod warunkiem że kod instancjuje klienta OAuth 2.0 z tym samym identyfikatorem klienta i kluczem tajnym. Oprócz Pythona biblioteki klienta interfejsu API Google dla innych języków programowania również udostępniają metody pomocnicze do zarządzania tokenami, które można udostępniać klientom, a nawet używać w bibliotekach HTTP niskiego poziomu bezpośrednio w nagłówku klienta lub jako parametr URL-a.
Oto kilka przykładów skryptów po stronie serwera, które używają tokenów offline:
- demon, który monitoruje katalog pod kątem nowych filmów, aby automatycznie przesyłać je do YouTube.
- zadanie cron, które codziennie aktualizuje playlisty o nowe treści;
- Skrypt, który monitoruje dane dotyczące filmów za pomocą YouTube Analytics API i powiadamia menedżerów kanału, gdy wystąpią określone zdarzenia, np. przekroczenie limitu łącznego czasu oglądania. Pamiętaj, że w tym przypadku jedyną obsługiwaną metodą autoryzacji jest OAuth 2.0, ponieważ interfejs Analytics API nie obsługuje metody ClientLogin.
Więcej informacji o generowaniu tokenów offline, które można używać w procesach po stronie serwera, znajdziesz w sekcji dotyczącej tokenów dostępu o długim czasie ważności.
Sprawdzone metody dotyczące identyfikatora i tajnego klucza klienta
Każdy kod, który ma ten sam identyfikator klienta i parę kluczy tajnych, może używać tych samych tokenów dostępu. Najlepiej ograniczyć dostęp do identyfikatora i klucza tajnego klienta do kodu, który działa na maszynach i urządzeniach w Twojej organizacji.
Nie umieszczaj identyfikatora i tajemnego klucza klienta w kodzie natywnych aplikacji mobilnych. Wszyscy deweloperzy, którzy uwierzytelniają się przy użyciu OAuth 2.0 na urządzeniu mobilnym, powinni używać identyfikatora klienta „Zainstalowana aplikacja”, który prosi o dodatkowe informacje potrzebne do potwierdzenia, że żądanie pochodzi tylko z aplikacji wydanej przez Twój zespół.
Na urządzeniach z Androidem aplikacja jest identyfikowana za pomocą kombinacji nazwy pakietu i hasza certyfikatu podpisywania zamiast identyfikatora klienta i jego tajnego klucza. W przypadku urządzeń z iOS używany jest identyfikator pakietu i identyfikator sklepu z aplikacjami. Oficjalną dokumentację dotyczącą pobierania tych informacji znajdziesz na stronie pomocy Google API Console.
Konta usługi nie działają z interfejsem YouTube API
Konta usług nie działają w przypadku wywołań interfejsu YouTube Data API, ponieważ wymagają powiązania z kanałem w YouTube, a nowych ani istniejących kanałów nie można z nimi powiązać. Jeśli do wywołania interfejsu YouTube Data API użyjesz konta usługi, serwer interfejsu API zwróci błąd z typem błędu unauthorized i powodem youtubeSignupRequired.
Dostęp offline lub długotrwały do interfejsu YouTube API
OAuth 2.0 ma tokeny krótkotrwałe i długotrwałe. W przypadku operacji jednorazowych najlepszym rozwiązaniem są krótkotrwałe tokeny dostępu. Tokeny te wygasają wkrótce po przyznaniu. W przypadku długotrwałych zadań warto zastosować token odświeżania, który służy do pobierania krótkoterminowych tokenów dostępu.
Aby mieć pewność, że Twoja aplikacja otrzyma długotrwały token odświeżania, a nie krótkotrwały token dostępu, podczas tworzenia identyfikatora klienta użyj przepływu „Zainstalowana aplikacja” i w polu „Zainstalowany typ aplikacji” wybierz Other:
W tym przypadku zalecamy użycie procesu „Zainstalowana aplikacja”. Jeśli w aplikacji internetowej potrzebujesz długotrwałego dostępu do interfejsu YouTube API, możesz go uzyskać, ustawiając w pierwotnym żądaniu autoryzacji lub w konfiguracji klienta parametr access_type na offline, a parametr approval_prompt na force. Niektóre biblioteki klienta będą zarządzać pobieraniem i odświeżaniem tokenów dostępu. Jeśli chcesz napisać własny niestandardowy kod autoryzacji, możesz skorzystać z tego wpisu na blogu Google Code.
Korzystanie z OAuth 2.0 na telefonach, tabletach i innych urządzeniach
Podczas tworzenia aplikacji na Androida deweloperzy mogą korzystać z interfejsu Google Play services do obsługi szczegółów autoryzacji. Usługi Google Play oferują standardowy proces autoryzacji dla wszystkich interfejsów API Google, w tym interfejsów API na platformie YouTube. Dzięki temu użytkownicy aplikacji na Androida będą mogli korzystać z usługi w znacznie wygodniejszy sposób niż w przypadku uwierzytelniania niestandardowego za pomocą ClientLogin.
Na urządzeniach z iOS Google oferuje 2 opcje:
- Google+ Platform for iOS, który integruje logowanie w usługach Google i umożliwia korzystanie z funkcji społecznościowych.
- gtm-oauth2 toolkit, który zapewnia autoryzację UIWebView i zarządza tokenami.
W przypadku urządzeń, które mają pełnić funkcję „drugiego ekranu” lub urządzeń takich jak telewizory bez łatwych w użyciu mechanizmów wprowadzania danych, zalecane jest OAuth 2.0 na urządzenia. OAuth 2.0 na urządzeniach działa w ten sposób, że gdy wymagane jest żądanie autoryzacji, użytkownikowi wyświetla się unikalny kod. W tym momencie użytkownicy są proszeni o przejście na stronę http://google.com/device na innym urządzeniu, takim jak laptop lub telefon, i wpisanie unikalnego kodu. Aplikacja wyświetla ekran podobny do tego:
Gdy użytkownik wpisze kod na innym urządzeniu, aplikacja będzie okresowo sprawdzać, czy kod został wpisany. Gdy to zrobi, pobiera token do wywoływania interfejsu API. Aby zobaczyć, jak to działa, obejrzyj prezentację demonstracyjną, którą można uruchomić na dowolnym urządzeniu z dostępem do internetu. Interfejs API jest niezależny od platformy, dzięki czemu jest przydatny na urządzeniach, które nie mają możliwości renderowania stron internetowych. W celu ułatwienia demonstracji zamieściliśmy przykładowy kod w Pythonie.
Podsumowanie
Autoryzacja OAuth 2.0 zapewnia elastyczność deweloperom, którzy potrzebują autoryzacji YouTube. Deweloperzy, którzy znają ClientLogin, mogą zauważyć, że konfigurowanie aplikacji do korzystania z OAuth 2.0 wymaga nieco więcej pracy na początku, ale po przeniesieniu aplikacje OAuth 2.0 zapewniają większą elastyczność, bezpieczeństwo i użyteczność na wielu platformach dla użytkowników.
Jeśli masz więcej pytań na temat OAuth 2.0 lub któregokolwiek z przykładów w tym artykule, zadaj je, używając tagu youtube-api na StackOverflow.