Ikai Lan, YouTube Developer Relations – June 2013
Interfejsy API YouTube używają protokołu OAuth 2.0 do autoryzowania żądań użytkowników. Często pytacie, czy w przyszłości dodamy do interfejsów API YouTube obsługę ClientLogin lub podobnych metod uwierzytelniania. 20 kwietnia 2012 roku oficjalnie wycofaliśmy ClientLogin i nie planujemy dodania takiego mechanizmu.
Istnieje wiele powodów, dla których uważamy, że obsługa różnych procesów autoryzacji OAuth 2.0 jest lepsza dla użytkowników YouTube niż ClientLogin. Te procesy obsługują przypadki użycia aplikacji na komputery, aplikacji działających tylko w internecie, 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 osiągnięcia przy użyciu ClientLogin. Odkryliśmy też, że ClientLogin sprawia wielu deweloperom więcej problemów po wprowadzeniu aplikacji na rynek.
Używanie 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 jest używana przeglądarka. Wyjątkiem jest sytuacja, gdy pracujesz nad aplikacją na Androida, która używa Google Play Services do pobierania tokenów za pomocą GoogleAuthUtil..
W przepływie tylko w internecie witryna, która chce wykonywać uwierzytelnione wywołania interfejsu API w imieniu użytkownika, musi przekierować go na google.com stronę uwierzytelniania, na której wyjaśniono, do czego aplikacja próbuje uzyskać dostęp. Aplikacja internetowa otrzymuje token, którego używa do wykonywania wywołań interfejsu API. Użytkownik może w każdej chwili cofnąć dostęp aplikacji na stronie connected apps and sites.
Nasze przykłady kodu w Pythonie pokazują, jak skrypty wiersza poleceń mogą uruchamiać przeglądarkę i wykonywać wywołania interfejsu API z okna terminala, tworzyć serwer lokalny, który będzie nasłuchiwać kodu po przekierowaniu autoryzacji, oraz automatycznie zapisywać token na potrzeby przyszłych wywołań interfejsu API. Film przedstawiający to w praktyce znajdziesz poniżej:
Użyty token to ciąg znaków ASCII. Jeśli jest to token offline, jest on przenośny. Za pomocą pobranego tokena możesz uruchomić skrypt na komputerze, a następnie skopiować i użyć kodu na serwerze zdalnym bez interfejsu GUI, pod warunkiem że kod tworzy instancję 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 udostępniają też metody pomocnicze do zarządzania tokenami, które można udostępniać klientom, a nawet używać bezpośrednio w bibliotekach HTTP niższego poziomu w nagłówku klienta lub jako parametr adresu URL.
Przykłady skryptów po stronie serwera, które używają tokenów offline:
- Usługa monitorująca katalog pod kątem nowych filmów, które mają być automatycznie przesyłane do YouTube.
- zadanie cron, które codziennie aktualizuje playlisty o nowe treści;
- Skrypt, który monitoruje dane filmów za pomocą YouTube Analytics API i powiadamia menedżerów kanału o wystąpieniu określonych zdarzeń, np. gdy łączny czas oglądania przekroczy limit. Pamiętaj, że w tym przypadku jedyną obsługiwaną metodą autoryzacji jest OAuth 2.0, ponieważ interfejs Analytics API nie obsługuje ClientLogin.
W sekcji Długotrwałe tokeny dostępu znajdziesz więcej informacji o tym, jak generować tokeny offline, które można wykorzystywać w procesach po stronie serwera.
Sprawdzone metody dotyczące identyfikatora i tajnego klucza klienta
Każdy kod, który ma taką samą parę identyfikatora klienta i klucza tajnego, może używać tych samych tokenów dostępu. Najlepiej ograniczyć dostęp do identyfikatora klienta i tajnego klucza klienta do kodu, który jest uruchamiany na komputerach i urządzeniach w Twojej organizacji.
Nie umieszczaj identyfikatora i klucza klienta w kodzie natywnych aplikacji mobilnych. Wszyscy deweloperzy, którzy przeprowadzają uwierzytelnianie OAuth 2.0 na urządzeniu mobilnym, powinni używać identyfikatora klienta „Zainstalowana aplikacja”, który wymaga podania dodatkowych informacji w celu sprawdzenia, czy żądanie pochodzi tylko z aplikacji wydanej przez Twój zespół.
Na urządzeniach z Androidem zamiast identyfikatora klienta i tajnego klucza klienta aplikacja jest identyfikowana za pomocą kombinacji nazwy pakietu i skrótu certyfikatu podpisywania. Na urządzeniach z iOS używane są identyfikator pakietu i identyfikator sklepu z aplikacjami. Oficjalną dokumentację dotyczącą pobierania tych informacji znajdziesz na Google Cloud consolestronie pomocy.
Konta usługi nie działają z interfejsem YouTube API
Konta usługi nie działają w przypadku wywołań interfejsu YouTube Data API, ponieważ wymagają powiązanego kanału w YouTube, a nie można powiązać nowych ani obecnych kanałów z kontami usługi. Jeśli do wywoływania interfejsu YouTube Data API używasz konta usługi, serwer API zwraca błąd z typem błędu ustawionym na unauthorized, a przyczyną ustawioną na youtubeSignupRequired.
Dostęp offline lub długotrwały do interfejsu YouTube API
OAuth 2.0 ma tokeny o krótkim i długim okresie ważności. W przypadku jednorazowych operacji najlepszym rozwiązaniem są krótkotrwałe tokeny dostępu. Te tokeny wygasają wkrótce po ich przyznaniu. W przypadku długotrwałych zadań warto rozważyć uzyskanie tokena odświeżania, który służy do pobierania krótkotrwałych 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 jako wartość „Typ zainstalowanej aplikacji” wybierz Other:
W tym przypadku zalecamy użycie procesu „Zainstalowana aplikacja”. Jeśli potrzebujesz długotrwałego dostępu do interfejsu YouTube API w aplikacji internetowej, możesz go uzyskać, ustawiając w początkowym żą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 kod autoryzacji, na blogu Google Code opublikowaliśmy post, który może posłużyć Ci jako podstawa.
Korzystanie z OAuth 2.0 na telefonach, tabletach i innych urządzeniach
Podczas pisania aplikacji na Androida deweloperzy mogą korzystać z metody 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 platformy YouTube. Takie podejście zapewni użytkownikom aplikacji na Androida znacznie większy komfort niż niestandardowe uwierzytelnianie za pomocą ClientLogin.
Na urządzeniach z iOS Google udostępnia 2 opcje:
- Google+ Platform for iOS, która 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 obsłudze mechanizmów wprowadzania danych preferowanym rozwiązaniem jest OAuth 2.0 dla urządzeń. OAuth 2.0 na urządzeniach działa w ten sposób, że gdy wymagane jest żądanie autoryzacji, użytkownikowi wyświetlany jest unikalny kod. 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świetli ekran podobny do tego:
Gdy użytkownik wpisuje kod na innym urządzeniu, aplikacja okresowo sprawdza, czy kod został wpisany. Po tym procesie pobiera token do wywoływania interfejsu API. Aby zobaczyć to w praktyce, wypróbuj wersję demonstracyjną, którą można uruchomić na dowolnym urządzeniu z dostępem do internetu. Sam interfejs API jest niezależny od platformy, dzięki czemu jest przydatny w przypadku urządzeń, które nie mają możliwości renderowania stron internetowych. Na potrzeby demonstracji opublikowaliśmy przykładowy kod w Pythonie, który możesz wykorzystać jako materiał referencyjny.
Podsumowanie
Autoryzacja OAuth 2.0 zapewnia deweloperom, którzy potrzebują autoryzacji YouTube, większą elastyczność. Deweloperzy znający ClientLogin mogą uznać, że skonfigurowanie 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ń dotyczących OAuth 2.0 lub któregokolwiek z przykładów w tym artykule, możesz je zadać na youtube-api StackOverflow.