Leka Ikai, YouTube Developer Relations – June 2013
Do autoryzacji żądań użytkowników interfejsy API YouTube wykorzystują OAuth 2.0. Często słyszymy pytania, czy w przyszłości dodamy obsługę uwierzytelniania ClientLogin czy podobną. 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 uwierzytelniania OAuth 2.0 jest inna niż użytkownicy ClientLogin. Te schematy obsługują przypadki użycia w przypadku aplikacji komputerowych, 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, co jest trudne do wykonania przy użyciu ClientLogin. Zauważyliśmy też, że w przypadku wielu deweloperów uruchomienie aplikacji ClientLogin powoduje więcej problemów. Niektóre z nich opisujemy w poście na blogu ClientLogin #FAIL.
Używanie protokołu OAuth 2.0 w przypadku samodzielnych skryptów po stronie serwera
Wielu programistów korzysta z ClientLogin do autoryzowania skryptów wiersza poleceń uruchamianych na serwerach bez przeglądarki. W przypadku protokołu OAuth 2.0 niemal zawsze będzie używana przeglądarka, z wyjątkiem sytuacji, gdy pracujesz w aplikacji na Androida, która pobiera tokeny przez GoogleAuthUtil.
W procesie internetowym witryna, która chce nawiązywać uwierzytelnione wywołania interfejsu API w imieniu użytkownika, musi przekierowywać go na stronę uwierzytelniania google.com, na której wyjaśnia, do czego aplikacja chce uzyskać dostęp. Następnie aplikacja internetowa odbiera token, którego używa do wywoływania interfejsu API. Użytkownik może w każdej chwili anulować dostęp aplikacji na stronie connected apps and sites.
Nasze przykłady kodu w języku Python pokazują, jak skrypty wiersza poleceń mogą uruchamiać przeglądarkę i wykonywać wywołania interfejsu API w terminalu, tworzyć serwer lokalny, aby nasłuchiwać kodu po przekierowaniu autoryzacji, oraz automatycznie zapisywać token do przyszłych wywołań interfejsu API. Film pokazujący to rozwiązanie w praktyce:
Użyty token jest ciągiem ASCII. Jeśli jest to token offline, jest przenośny. Korzystając z pobranego tokena, możesz uruchomić skrypt na komputerze, a potem skopiować go i użyć go na zdalnym serwerze bez graficznego interfejsu użytkownika, o ile kod ten tworzy wystąpienie klienta OAuth 2.0 z tym samym identyfikatorem klienta i tym samym obiektem tajnym. Oprócz Pythona biblioteki klienta interfejsu API Google API dla innych języków programowania udostępniają też metody pomocnicze w zarządzaniu tokenami, które można udostępniać między klientami, a nawet w bibliotekach HTTP niższego poziomu bezpośrednio w nagłówku klienta lub jako parametr adresu URL.
Oto przykłady skryptów po stronie serwera, które korzystają z tokenów offline:
- demon, który monitoruje katalog nowych filmów automatycznie przesyłanych do YouTube;
- Zadanie cron, które codziennie aktualizuje playlisty o nowe treści
- Skrypt, który monitoruje dane wideo za pomocą interfejsu YouTube Analytics API, i powiadamia menedżerów kanału o wystąpieniu określonych zdarzeń, takich jak łączny czas oglądania przekraczający limit. Pamiętaj, że w tym przypadku jedyna obsługiwana metoda autoryzacji to OAuth 2.0, ponieważ interfejs Analytics API nie obsługuje ClientLogin.
Sekcja na temat tokenów dostępu długoterminowego zawiera więcej informacji o generowaniu tokenów offline, których można używać w przypadku procesów po stronie serwera.
Sprawdzone metody dotyczące identyfikatora klienta i tajnego klucza klienta
Każdy kod, który korzysta z tego samego identyfikatora klienta i tajnego klucza, może używać tych samych tokenów dostępu. Najlepiej jest ograniczyć dostęp do identyfikatora klienta i tajnych kluczy klienta do kodu, który działa na komputerach i urządzeniach w organizacji.
Nie podawaj identyfikatora klienta ani tajnego klucza klienta w kodzie natywnych aplikacji mobilnych. Wszyscy deweloperzy stosujący uwierzytelnianie OAuth 2.0 na urządzeniu mobilnym powinni korzystać z identyfikatora klienta „Zainstalowana aplikacja”, który wymaga podania dodatkowych informacji, aby upewnić się, że żądanie pochodzi tylko z aplikacji udostępnionej przez Twój zespół.
Na urządzeniach z Androidem zamiast identyfikatora klienta i tajnego klucza klienta aplikacja jest identyfikowana na podstawie połączenia nazwy pakietu z haszem certyfikatu podpisywania. Na urządzeniach z iOS używany jest identyfikator pakietu oraz identyfikator w sklepie z aplikacjami. Oficjalne dokumenty dotyczące pobierania tych informacji znajdziesz na stronie pomocy Google API Console.
Konta usługi nie działają z interfejsem YouTube API
Konta usługi nie działają w przypadku wywołań interfejsu API danych YouTube, ponieważ konta usługi wymagają powiązanego kanału YouTube, a nie można powiązać nowych ani istniejących kanałów z kontami usługi. Jeśli używasz konta usługi do wywoływania interfejsu YouTube Data API, serwer API zwraca błąd, którego typ jest ustawiony na unauthorized, a jego przyczyną jest youtubeSignupRequired.
Dostęp offline do YouTube w trybie offline lub długoterminowy
Protokół OAuth 2.0 ma tokeny o ograniczonym czasie ważności i długoterminowe. W przypadku jednorazowych operacji najlepszym rozwiązaniem są krótkotrwałe tokeny dostępu. Tokeny wygasają wkrótce po ich przyznaniu. W przypadku długotrwałych zadań możesz rozważyć pozyskanie tokenu odświeżania, który służy do pobierania tokenów dostępu o ograniczonym czasie ważności.
Aby mieć pewność, że aplikacja otrzyma długotrwały token odświeżania, a nie token dostępu o ograniczonym czasie ważności, podczas tworzenia identyfikatora klienta wykonaj procedurę „Zainstalowana aplikacja”, a jako wartość „Typ zainstalowanej aplikacji” wybierz Other:
W tym przypadku zalecamy korzystanie z przepływu „Zainstalowana aplikacja”. Jeśli potrzebujesz długoterminowego dostępu do interfejsu YouTube API w aplikacji internetowej, możesz go pobrać, ustawiając parametr access_type na offline, a parametr approval_prompt na force w wstępnym żądaniu autoryzacji lub konfiguracji klienta. 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, opublikuj posta na blogu Google Code, który możesz wykorzystać jako podstawę.
Korzystanie z OAuth 2.0 na telefonach, tabletach i innych urządzeniach
Podczas pisania aplikacji na Androida deweloperzy mogą obsługiwać szczegóły autoryzacji w Google Play services. Usługi Google Play oferują standardowy proces autoryzacji wszystkich interfejsów API Google, w tym interfejsów API platformy YouTube. Ta metoda zapewni użytkownikom aplikacji o znacznie wyższej jakości niż niestandardowe uwierzytelnianie w ClientLogin.
Na urządzeniach z iOS Google udostępnia 2 opcje:
- Google+ Platform for iOS, który integruje logowanie się do usług Google i udostępnia funkcje społecznościowe
- gtm-oauth2 toolkit, który zawiera autoryzację UIWebView i zarządza tokenami.
W przypadku urządzeń, które mają pełnić funkcję „drugich ekranów” lub takich jak telewizory bez łatwych w użyciu mechanizmów przesyłania, zalecamy korzystanie z protokołu OAuth 2.0 dla urządzeń. Protokół OAuth 2.0 na urządzenia umożliwia wyświetlanie unikalnego kodu użytkownikowi, gdy wymagane jest upoważnienie. W tym momencie użytkownicy są proszeni o otwarcie strony http://google.com/device na innym urządzeniu, np. laptopie lub telefonie, i wpisanie unikalnego kodu. Aplikacja wyświetla ekran podobny do tego:
Gdy użytkownik wpisuje kod na innym urządzeniu, aplikacja okresowo wysyła ankiety, aby sprawdzić, czy kod został wpisany. Po otrzymaniu pobiera token do wywoływania interfejsu API. Aby zobaczyć, jak to działa, obejrzyj wersję demonstracyjną, którą możesz uruchomić na dowolnym urządzeniu z dostępem do internetu. Sam interfejs API jest niezależny od platformy, co ułatwia korzystanie z urządzeń, które nie mają funkcji renderowania internetowego. Opublikowaliśmy przykładowy kod w Pythonie, który może służyć jako plik referencyjny.
Podsumowanie
Autoryzacja OAuth 2.0 zapewnia elastyczność dla programistów, którzy wymagają autoryzacji YouTube. Deweloperzy, którzy znają ClientLogin, mogą zauważyć, że konfiguracja aplikacji pod kątem protokołu OAuth 2.0 wymaga trochę więcej wysiłku, ale po przeniesieniu aplikacje OAuth 2.0 zapewniają większą elastyczność, bezpieczeństwo i użyteczność na wielu platformach dla użytkowników końcowych.
Jeśli masz więcej pytań o OAuth 2.0 lub przykłady z tego artykułu, zadaj je, używając tagu youtube-api w StackOverflow.