Korzystanie z protokołu OAuth 2.0 w aplikacjach internetowych JavaScript

Ten dokument wyjaśnia, jak wdrożyć autoryzację OAuth 2.0, aby uzyskać dostęp do interfejsu YouTube Data API z aplikacji internetowej JavaScript. OAuth 2.0 umożliwia użytkownikom udostępnianie określonych danych aplikacji przy jednoczesnym zachowaniu prywatności nazw użytkowników, haseł i innych informacji. Aplikacja może na przykład korzystać z protokołu OAuth 2.0, aby uzyskać pozwolenie na przesyłanie filmów na kanał YouTube użytkownika.

Ten przepływ protokołu OAuth 2.0 jest nazywany przepływem niejawnym. Został on zaprojektowany dla aplikacji, które uzyskują dostęp do interfejsów API tylko wtedy, gdy użytkownik jest obecny w aplikacji. Te aplikacje nie mogą przechowywać informacji poufnych.

W tym procesie Twoja aplikacja otwiera adres URL Google, który identyfikuje aplikację i wymaga dostępu do interfejsu API na podstawie parametrów zapytania. Możesz otworzyć adres URL w bieżącym oknie przeglądarki lub w wyskakującym okienku. Użytkownik może uwierzytelnić się w Google i przyznać wymagane uprawnienia. Następnie Google przekierowuje użytkownika z powrotem do Twojej aplikacji. Przekierowanie zawiera token dostępu, który aplikacja weryfikuje, a następnie używa do wysyłania żądań do interfejsu API.

Biblioteka klienta interfejsów API Google i usługi tożsamości Google

Jeśli do wykonywania autoryzowanych wywołań do Google używasz biblioteki klienta interfejsów API Google dla JavaScriptu, do obsługi przepływu OAuth 2.0 używaj biblioteki JavaScript Google Identity Services. Zapoznaj się z modelem tokena usług tożsamości Google, który jest oparty na procesie uwierzytelniania niejawnego OAuth 2.0.

Wymagania wstępne

Włączanie interfejsów API w projekcie

Każda aplikacja, która wywołuje interfejsy API Google, musi je włączyć w API Console.

Aby włączyć interfejs API w projekcie:

  1. Open the API Library w Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Na stronie Biblioteka możesz znaleźć i włączyć interfejs YouTube Data API. Znajdź i włącz wszystkie inne interfejsy API, których będzie używać Twoja aplikacja.

Tworzenie danych uwierzytelniających

Każda aplikacja korzystająca z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google musi mieć dane uwierzytelniające, które identyfikują aplikację na serwerze Google OAuth 2.0. Poniżej znajdziesz instrukcje tworzenia danych logowania dla projektu. Aplikacje będą mogły używać tych danych logowania do uzyskiwania dostępu do interfejsów API włączonych w tym projekcie.

  1. Go to the Credentials page.
  2. Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
  3. Jako typ aplikacji wybierz Aplikacja internetowa.
  4. Wypełnij formularz. Aplikacje używające JavaScriptu do wysyłania autoryzowanych żądań do interfejsu Google API muszą określać autoryzowane źródła JavaScript. Źródła identyfikują domeny, z których aplikacja może wysyłać żądania do serwera OAuth 2.0. Te źródła muszą być zgodne z regułami weryfikacji Google.

Określanie zakresów dostępu

Zakresy pozwalają aplikacji prosić o dostęp tylko do zasobów, których potrzebuje, a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu, który przyznają aplikacji. Dlatego może występować odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Zanim zaczniesz wdrażać autoryzację OAuth 2.0, zalecamy określenie zakresów, do których aplikacja będzie potrzebować uprawnień dostępu.

Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:

Zakresy
https://www.googleapis.com/auth/youtubeZarządzanie kontem YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorWyświetlanie listy aktualnie aktywnych użytkowników wspierających kanał, ich obecnych poziomów i dat rozpoczęcia wsparcia
https://www.googleapis.com/auth/youtube.force-sslPrzeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube
https://www.googleapis.com/auth/youtube.readonlyWyświetlanie konta YouTube
https://www.googleapis.com/auth/youtube.uploadZarządzanie filmami w YouTube
https://www.googleapis.com/auth/youtubepartnerPrzeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditPrzeglądanie prywatnych danych kanału YouTube istotnych podczas rozmowy z partnerem YouTube

Dokument Zakresy interfejsu API OAuth 2.0 zawiera pełną listę zakresów, których możesz używać do uzyskiwania dostępu do interfejsów API Google.

Uzyskiwanie tokenów dostępu OAuth 2.0

Z podanych niżej instrukcji dowiesz się, jak Twoja aplikacja wchodzi w interakcję z serwerem Google OAuth 2.0, aby uzyskać zgodę użytkownika na wykonanie żądania do interfejsu API w jego imieniu. Twoja aplikacja musi uzyskać tę zgodę, zanim będzie mogła wykonać żądanie do interfejsu API Google wymagające autoryzacji użytkownika.

Krok 1. Przekieruj na serwer OAuth 2.0 Google

Aby poprosić o dostęp do danych użytkownika, przekieruj go na serwer Google OAuth 2.0.

OAuth 2.0 Endpoints

Wygeneruj URL, aby poprosić o dostęp z punktu końcowego OAuth 2.0 Google na stronie https://accounts.google.com/o/oauth2/v2/auth. Ten punkt końcowy jest dostępny przez HTTPS. Zwykłe połączenia HTTP są odrzucane.

Serwer autoryzacji Google obsługuje te parametry ciągu zapytania w aplikacjach serwera WWW:

Parametry
client_id Wymagane

Identyfikator klienta aplikacji. Tę wartość znajdziesz w API Console Credentials page.

redirect_uri Wymagane

Określa, dokąd serwer interfejsu API przekierowuje użytkownika po zakończeniu procesu autoryzacji przez użytkownika. Wartość musi dokładnie odpowiadać jednemu z autoryzowanych identyfikatorów URI przekierowania klienta OAuth 2.0 skonfigurowanych w: API Console Credentials pageklienta. Jeśli ta wartość nie pasuje do autoryzowanego identyfikatora URI przekierowania w podanej wartości client_id, wystąpi błąd redirect_uri_mismatch.

Pamiętaj, że schemat http lub https, wielkość liter i ukośnik końcowy („/”) muszą być zgodne.

response_type Wymagane

Aplikacje JavaScript muszą ustawić wartość parametru na token. Ta wartość instruuje serwer autoryzacji Google, aby zwracał token dostępu jako para name=value w identyfikatorze fragmentu identyfikatora URI (#), do którego użytkownik jest przekierowywany po ukończeniu procesu autoryzacji.

scope Wymagane

Rozdzielona spacjami lista zakresów identyfikujących zasoby, do których aplikacja może uzyskiwać dostęp w imieniu użytkownika. Wartości te informują o ekranie zgody, który Google wyświetla użytkownikowi.

Zakresy pozwalają aplikacji prosić o dostęp tylko do zasobów, których potrzebuje, a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu, jaki przyznają aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:

Zakresy
https://www.googleapis.com/auth/youtubeZarządzanie kontem YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorWyświetlanie listy aktualnie aktywnych użytkowników wspierających kanał, ich obecnych poziomów i dat rozpoczęcia wsparcia
https://www.googleapis.com/auth/youtube.force-sslPrzeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube
https://www.googleapis.com/auth/youtube.readonlyWyświetlanie konta YouTube
https://www.googleapis.com/auth/youtube.uploadZarządzanie filmami w YouTube
https://www.googleapis.com/auth/youtubepartnerPrzeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditPrzeglądanie prywatnych danych kanału YouTube istotnych podczas rozmowy z partnerem YouTube

Dokument Zakresy interfejsu API OAuth 2.0 zawiera pełną listę zakresów, których możesz używać do uzyskiwania dostępu do interfejsów API Google.

Zalecamy, aby aplikacja żądała dostępu do zakresów autoryzacji w kontekście, gdy tylko jest to możliwe. Prosząc o dostęp do danych użytkownika w kontekście za pomocą dodatkowej autoryzacji, pomagasz użytkownikom zrozumieć, dlaczego Twoja aplikacja potrzebuje dostępu, o który prosi.

state Zalecane

Określa dowolną wartość ciągu, której aplikacja używa do utrzymania stanu między żądaniem autoryzacji a odpowiedzią serwera autoryzacji. Gdy użytkownik wyrazi zgodę na dostęp aplikacji lub odmówi jej dostępu, serwer zwraca dokładną wartość, którą wysyłasz w postaci pary name=value w identyfikatorze fragmentu adresu URL (#) identyfikatora redirect_uri.

Tego parametru możesz używać do różnych celów, na przykład do kierowania użytkowników do odpowiedniego zasobu w aplikacji, wysyłania liczby jednorazowych i zapobiegania fałszowaniu żądań z innych witryn. Ponieważ redirect_uri można odgadnąć, użycie wartości state może zwiększyć pewność, że połączenie przychodzące jest wynikiem żądania uwierzytelnienia. Jeśli generujesz losowy ciąg lub kodujesz hasz pliku cookie bądź inną wartość przechwytującą stan klienta, możesz zweryfikować odpowiedź, aby dodatkowo upewnić się, że żądanie i odpowiedź pochodzą z tej samej przeglądarki. Zapewnia to ochronę przed atakami takimi jak oszustwa żądań z innych witryn. Przykład tworzenia i potwierdzania tokena state znajdziesz w dokumentacji OpenID Connect.

include_granted_scopes Opcjonalny

Umożliwia aplikacjom korzystanie z autoryzacji przyrostowej w celu proszenia o dostęp do dodatkowych zakresów w kontekście. Jeśli ustawisz wartość tego parametru na true i żądanie autoryzacji zostanie zatwierdzone, nowy token dostępu będzie też obejmować wszystkie zakresy, do których użytkownik przyznał wcześniej dostęp aplikacji. Przykłady znajdziesz w sekcji o dodatkowej autoryzacji.

login_hint Opcjonalny

Jeśli aplikacja wie, który użytkownik próbuje się uwierzytelnić, może użyć tego parametru, aby podać wskazówkę dla serwera uwierzytelniania Google. Serwer korzysta ze wskazówek, aby uprościć proces logowania. Aby to zrobić, wstępnie wypełnij pole adresu e-mail w formularzu logowania lub wybierz odpowiednią sesję wielokrotnego logowania.

Ustaw wartość parametru na adres e-mail lub identyfikator sub, który jest odpowiednikiem identyfikatora Google użytkownika.

prompt Opcjonalny

Rozdzielona spacjami lista promptów, które mają zostać zaprezentowane użytkownikowi. Wielkość liter ma znaczenie. Jeśli nie określisz tego parametru, użytkownik zostanie o to poproszony tylko przy pierwszej prośbie o dostęp z projektu. Więcej informacji znajdziesz w artykule na temat proszenia o ponowne wyrażenie zgody.

Możliwe wartości to:

none Nie wyświetlaj żadnych ekranów uwierzytelniania ani zgody użytkownika. Nie można go określać za pomocą innych wartości.
consent Wyświetl użytkownikowi prośbę o zgodę.
select_account Wyświetlaj użytkownikowi prośbę o wybranie konta.

Przykładowe przekierowanie na serwer autoryzacji Google

Przykładowy adres URL poniżej prosi o dostęp offline (access_type=offline) do zakresu, który umożliwia wyświetlanie konta YouTube użytkownika. Korzysta on z autoryzacji przyrostowej, aby zagwarantować, że nowy token dostępu obejmuje wszystkie zakresy, do których użytkownik przyznał wcześniej dostęp aplikacji. Adres URL określa też wartości wymaganych parametrów redirect_uri, response_type i client_id oraz parametru state. Aby zapewnić czytelność, adres URL zawiera podziały wierszy i spacje.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 include_granted_scopes=true&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 response_type=token&
 client_id=client_id

Po utworzeniu adresu URL żądania przekieruj na niego użytkownika.

Przykładowy kod JavaScript

Ten fragment kodu JavaScript pokazuje, jak rozpocząć proces autoryzacji w JavaScripcie bez użycia biblioteki klienta interfejsów API Google do JavaScriptu. Ten punkt końcowy OAuth 2.0 nie obsługuje współdzielenia zasobów między pochodzeniem (CORS), więc fragment kodu tworzy formularz, który otwiera żądanie kierujące do tego punktu końcowego.

/*
 * Create form to request access token from Google's OAuth 2.0 server.
 */
function oauthSignIn() {
  // Google's OAuth 2.0 endpoint for requesting an access token
  var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

  // Create <form> element to submit parameters to OAuth 2.0 endpoint.
  var form = document.createElement('form');
  form.setAttribute('method', 'GET'); // Send as a GET request.
  form.setAttribute('action', oauth2Endpoint);

  // Parameters to pass to OAuth 2.0 endpoint.
  var params = {'client_id': 'YOUR_CLIENT_ID',
                'redirect_uri': 'YOUR_REDIRECT_URI',
                'response_type': 'token',
                'scope': 'https://www.googleapis.com/auth/youtube.force-ssl',
                'include_granted_scopes': 'true',
                'state': 'pass-through value'};

  // Add form parameters as hidden input values.
  for (var p in params) {
    var input = document.createElement('input');
    input.setAttribute('type', 'hidden');
    input.setAttribute('name', p);
    input.setAttribute('value', params[p]);
    form.appendChild(input);
  }

  // Add form to page and submit it to open the OAuth 2.0 endpoint.
  document.body.appendChild(form);
  form.submit();
}

Krok 2. Google prosi użytkownika o zgodę

Na tym etapie użytkownik decyduje, czy przyznać aplikacji żądany dostęp. Na tym etapie Google wyświetla okno zgody, w którym widoczna jest nazwa Twojej aplikacji i usług interfejsów API Google, do których aplikacja prosi o dostęp (wraz z danymi uwierzytelniającymi użytkownika) oraz podsumowanie zakresów dostępu. Użytkownik może wtedy wyrazić zgodę na przyznanie dostępu do co najmniej 1 zakresu żądanego przez aplikację lub odrzucić żądanie.

Na tym etapie Twoja aplikacja nie musi nic robić, ponieważ czeka na odpowiedź z serwera OAuth 2.0 Google wskazującą, czy przyznano dostęp. Odpowiedź na to pytanie zostanie objaśniona w kolejnym kroku.

Błędy

Żądania wysyłane do punktu końcowego autoryzacji OAuth 2.0 Google mogą wyświetlać komunikaty o błędach widoczne dla użytkowników zamiast oczekiwanych przepływów uwierzytelniania i autoryzacji. Poniżej znajdziesz typowe kody błędów i sugerowane rozwiązania.

admin_policy_enforced

Konto Google nie może autoryzować co najmniej jednego żądanego zakresu ze względu na zasady administratora Google Workspace. Aby dowiedzieć się więcej o tym, jak administrator może ograniczać dostęp do wszystkich zakresów lub zakresów wrażliwych i zakresów z ograniczeniami, przeczytaj artykuł pomocy dla administratorów Google Workspace na temat określania, które aplikacje innych firm i aplikacje wewnętrzne mają dostęp do danych Google Workspace.

disallowed_useragent

Punkt końcowy autoryzacji jest wyświetlany w umieszczonym kliencie użytkownika niedozwolonym przez zasady Google dotyczące protokołu OAuth 2.0.

Android

Deweloperzy aplikacji na Androida mogą napotkać ten komunikat o błędzie podczas otwierania żądań autoryzacji w android.webkit.WebView. Deweloperzy powinni zamiast tego używać bibliotek Androida, takich jak Google Sign-In for Android czy AppAuth for Android organizacji OpenID Foundation.

Programiści stron internetowych mogą napotkać ten błąd, gdy aplikacja na Androida otwiera ogólny link internetowy w osadzonym kliencie użytkownika, a użytkownik przechodzi z Twojej witryny do punktu końcowego autoryzacji OAuth 2.0 Google. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków systemu operacyjnego, który zawiera zarówno linki aplikacji na Androida, jak i domyślną przeglądarkę. Obsługiwana jest też biblioteka kart niestandardowych Androida.

iOS

Deweloperzy systemów iOS i macOS mogą napotkać ten błąd podczas otwierania żądań autoryzacji w WKWebView. Deweloperzy powinni zamiast tego używać bibliotek iOS, takich jak Google Sign-In for iOS lub OpenID Foundation AppAuth for iOS.

Deweloperzy aplikacji internetowej mogą napotkać ten błąd, gdy aplikacja na iOS lub macOS otwiera ogólny link internetowy w osadzonym kliencie użytkownika, a użytkownik przechodzi z Twojej witryny do punktu końcowego autoryzacji OAuth 2.0 Google. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków w systemie operacyjnym, który zawiera zarówno uniwersalne linki, jak i domyślną aplikację przeglądarki. Obsługiwana jest też biblioteka SFSafariViewController.

org_internal

Identyfikator klienta OAuth w żądaniu jest częścią projektu ograniczającego dostęp do kont Google w określonej organizacji Google Cloud. Więcej informacji o tej opcji konfiguracji znajdziesz w sekcji Typ użytkownika artykułu pomocy „Konfigurowanie ekranu zgody OAuth”.

invalid_client

Źródło, z którego przesłano żądanie, nie jest autoryzowane w przypadku tego klienta. Zobacz: origin_mismatch.

invalid_grant

Podczas korzystania z autoryzacji przyrostowej token mógł wygasnąć lub został unieważniony. Uwierzytelnij użytkownika ponownie i poproś o zgodę na uzyskanie nowych tokenów. Jeśli ten błąd będzie się powtarzał, sprawdź, czy aplikacja została prawidłowo skonfigurowana i czy w żądaniu używasz prawidłowych tokenów i parametrów. W przeciwnym razie konto użytkownika mogło zostać usunięte lub wyłączone.

origin_mismatch

Schemat, domena lub port kodu JavaScript, z którego pochodzi żądanie autoryzacji, mogą nie być zgodne z autoryzowanym identyfikatorem URI źródła JavaScript zarejestrowanym dla identyfikatora klienta OAuth. Przejrzyj autoryzowane źródła JavaScriptu w Google API Console Credentials page.

redirect_uri_mismatch

redirect_uri przekazany w żądaniu autoryzacji nie pasuje do autoryzowanego identyfikatora URI przekierowania dla identyfikatora klienta OAuth. Przejrzyj autoryzowane identyfikatory URI przekierowania w Google API Console Credentials page.

Schemat, domena lub port kodu JavaScript, z którego pochodzi żądanie autoryzacji, mogą nie być zgodne z autoryzowanym identyfikatorem URI źródła JavaScript zarejestrowanym dla identyfikatora klienta OAuth. Sprawdź autoryzowane źródła JavaScript w Google API Console Credentials page.

Parametr redirect_uri może odnosić się do zewnętrznego procesu OAuth (OOB), który został wycofany i nie jest już obsługiwany. Informacje o tym, jak zaktualizować integrację, znajdziesz w przewodniku po migracji.

invalid_request

Coś poszło nie tak z Twoją prośbą. Możliwych jest kilka przyczyn tej sytuacji:

  • Żądanie było nieprawidłowo sformatowane
  • W żądaniu brakowało wymaganych parametrów
  • Żądanie używa metody autoryzacji, której Google nie obsługuje. Sprawdź, czy integracja OAuth korzysta z zalecanej metody integracji

Krok 3. Przetwórz odpowiedź serwera OAuth 2.0

OAuth 2.0 Endpoints

Serwer OAuth 2.0 wysyła odpowiedź do elementu redirect_uri określonego w żądaniu tokena dostępu.

Jeśli użytkownik zatwierdzi żądanie, odpowiedź będzie zawierać token dostępu. Jeśli użytkownik nie zatwierdzi żądania, odpowiedź będzie zawierać komunikat o błędzie. Token dostępu lub komunikat o błędzie jest zwracany we fragmencie z krzyżykiem identyfikatora URI przekierowania, jak pokazano poniżej:

  • Odpowiedź tokena dostępu:

    https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600

    Oprócz parametru access_token ciąg znaków z fragmentem zawiera też parametr token_type, który zawsze jest ustawiony na Bearer, oraz parametr expires_in, który określa czas trwania tokena (w sekundach). Jeśli w żądaniu tokena dostępu określono parametr state, jego wartość jest również uwzględniona w odpowiedzi.

  • Odpowiedź dotycząca błędu:
    https://oauth2.example.com/callback#error=access_denied

Przykładowa odpowiedź serwera OAuth 2.0

Możesz przetestować ten proces, klikając ten przykładowy adres URL, który prosi o dostęp tylko do odczytu z możliwością wyświetlania metadanych plików na Dysku Google:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 include_granted_scopes=true&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 response_type=token&
 client_id=client_id

Po zakończeniu procesu OAuth 2.0 przekierujemy Cię do http://localhost/oauth2callback. Ten adres URL zwróci błąd 404 NOT FOUND, chyba że komputer lokalny wyświetli plik pod tym adresem. W następnym kroku znajdziesz więcej informacji na temat informacji zwracanych w identyfikatorze URI, gdy użytkownik jest przekierowywany z powrotem do Twojej aplikacji.

Wywoływanie interfejsów API Google

OAuth 2.0 Endpoints

Gdy aplikacja uzyska token dostępu, możesz za jego pomocą wywoływać interfejs API Google w imieniu danego konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, uwzględnij token dostępu w żądaniu wysyłanym do interfejsu API, podając parametr zapytania access_token lub wartość nagłówka HTTP Bearer Authorization. W miarę możliwości preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w logach serwera. W większości przypadków możesz użyć biblioteki klienta, aby skonfigurować wywołania interfejsów API Google (na przykład wywołując YouTube Data API).

Pamiętaj, że interfejs YouTube Data API obsługuje konta usługi tylko w przypadku właścicieli treści YouTube, którzy są właścicielami wielu kanałów YouTube, takich jak wytwórnie płytowe i studia filmowe, i zarządzają nimi.

Możesz wypróbować wszystkie interfejsy API Google i wyświetlić ich zakresy w interfejsie OAuth 2.0 Playground.

Przykłady żądań HTTP GET

Wywołanie punktu końcowego youtube.channels (YouTube Data API) przy użyciu nagłówka HTTP Authorization: Bearer może wyglądać tak. Pamiętaj, że musisz podać własny token dostępu:

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Oto wywołanie tego samego interfejsu API dla uwierzytelnionego użytkownika za pomocą parametru ciągu zapytania access_token:

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

curl przykładu

Możesz je przetestować za pomocą aplikacji wiersza poleceń curl. Oto przykład z wykorzystaniem opcji nagłówka HTTP (preferowana):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

Możesz też użyć opcji parametru ciągu zapytania:

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Przykładowy kod JavaScript

Fragment kodu poniżej pokazuje, jak używać CORS (udostępniania zasobów między domenami) do wysłania żądania do interfejsu API Google. W tym przykładzie nie korzystamy z biblioteki klienta interfejsów API Google dla JavaScriptu. Jednak nawet wtedy, gdy nie korzystasz z biblioteki klienta, przewodnik pomocy CORS w dokumentacji tej biblioteki prawdopodobnie pomoże Ci lepiej zrozumieć te żądania.

W tym fragmencie kodu zmienna access_token reprezentuje token uzyskany, aby wysyłać żądania do interfejsu API w imieniu autoryzowanego użytkownika. Pełny przykład pokazuje, jak zapisać ten token w pamięci lokalnej przeglądarki i pobrać go podczas wysyłania żądania do interfejsu API.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

Pełny przykład

OAuth 2.0 Endpoints

Ten przykładowy kod pokazuje, jak wykonać przepływ OAuth 2.0 w JavaScripcie bez użycia biblioteki klienta interfejsów API Google do JavaScriptu. Kod jest przeznaczony dla strony HTML, która wyświetla przycisk umożliwiający wypróbowanie żądania do interfejsu API. Jeśli klikniesz ten przycisk, kod sprawdzi, czy strona zapisała token dostępu API w pamięci lokalnej przeglądarki. Jeśli tak, wykonuje żądanie do interfejsu API. W przeciwnym razie inicjuje przepływ OAuth 2.0.

W przypadku procesu OAuth 2.0 na stronie wykonaj te czynności:

  1. Kieruje użytkownika do serwera OAuth 2.0 Google, który żąda dostępu do zakresu https://www.googleapis.com/auth/youtube.force-ssl.
  2. Po przyznaniu (lub odmowie) dostępu do co najmniej 1 żądanego zakresu użytkownik jest przekierowywany na stronę oryginalną, która analizuje token dostępu z ciągu identyfikatora fragmentu.
  3. Strona używa tokena dostępu do przykładowego żądania do interfejsu API.

    To żądanie do interfejsu API wywołuje metodę channels.list interfejsu YouTube Data API, aby pobrać dane o kanale YouTube autoryzowanego użytkownika.

  4. Jeśli żądanie zostanie wykonane, odpowiedź interfejsu API zostanie zarejestrowana w konsoli debugowania przeglądarki.

Dostęp do aplikacji możesz anulować na stronie Uprawnienia na swoim koncie Google. Aplikacja będzie widoczna jako Wersja demonstracyjna OAuth 2.0 w Dokumentach interfejsu Google API.

Aby uruchomić ten kod lokalnie, musisz ustawić wartości zmiennych YOUR_CLIENT_ID i YOUR_REDIRECT_URI, które odpowiadają Twoim danym uwierzytelniającym. Zmienna YOUR_REDIRECT_URI powinna być ustawiona na ten sam adres URL, pod którym wyświetla się strona. Wartość musi dokładnie odpowiadać jednemu z autoryzowanych identyfikatorów URI przekierowania klienta OAuth 2.0 skonfigurowanych w API Console Credentials page. Jeśli ta wartość nie jest zgodna z autoryzowanym identyfikatorem URI, wystąpi błąd redirect_uri_mismatch. Twój projekt musi też mieć włączony odpowiedni interfejs API dla tego żądania.

<html><head></head><body>
<script>
  var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
  var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';

  // Parse query string to see if page request is coming from OAuth 2.0 server.
  var fragmentString = location.hash.substring(1);
  var params = {};
  var regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(fragmentString)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }
  if (Object.keys(params).length > 0 && params['state']) {
    if (params['state'] == localStorage.getItem('state')) {
      localStorage.setItem('oauth2-test-params', JSON.stringify(params) );

      trySampleRequest();
    } else {
      console.log('State mismatch. Possible CSRF attack');
    }
  }

  // Function to generate a random state value
  function generateCryptoRandomState() {
    const randomValues = new Uint32Array(2);
    window.crypto.getRandomValues(randomValues);

    // Encode as UTF-8
    const utf8Encoder = new TextEncoder();
    const utf8Array = utf8Encoder.encode(
      String.fromCharCode.apply(null, randomValues)
    );

    // Base64 encode the UTF-8 data
    return btoa(String.fromCharCode.apply(null, utf8Array))
      .replace(/\+/g, '-')
      .replace(/\//g, '_')
      .replace(/=+$/, '');
  }

  // If there's an access token, try an API request.
  // Otherwise, start OAuth 2.0 flow.
  function trySampleRequest() {
    var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
    if (params && params['access_token']) {
      var xhr = new XMLHttpRequest();
      xhr.open('GET',
          'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' +
          'access_token=' + params['access_token']);
      xhr.onreadystatechange = function (e) {
        if (xhr.readyState === 4 && xhr.status === 200) {
          console.log(xhr.response);
        } else if (xhr.readyState === 4 && xhr.status === 401) {
          // Token invalid, so prompt for user permission.
          oauth2SignIn();
        }
      };
      xhr.send(null);
    } else {
      oauth2SignIn();
    }
  }

  /*
   * Create form to request access token from Google's OAuth 2.0 server.
   */
  function oauth2SignIn() {
    // create random state value and store in local storage
    var state = generateCryptoRandomState();
    localStorage.setItem('state', state);

    // Google's OAuth 2.0 endpoint for requesting an access token
    var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

    // Create element to open OAuth 2.0 endpoint in new window.
    var form = document.createElement('form');
    form.setAttribute('method', 'GET'); // Send as a GET request.
    form.setAttribute('action', oauth2Endpoint);

    // Parameters to pass to OAuth 2.0 endpoint.
    var params = {'client_id': YOUR_CLIENT_ID,
                  'redirect_uri': YOUR_REDIRECT_URI,
                  'scope': 'https://www.googleapis.com/auth/youtube.force-ssl',
                  'state': state,
                  'include_granted_scopes': 'true',
                  'response_type': 'token'};

    // Add form parameters as hidden input values.
    for (var p in params) {
      var input = document.createElement('input');
      input.setAttribute('type', 'hidden');
      input.setAttribute('name', p);
      input.setAttribute('value', params[p]);
      form.appendChild(input);
    }

    // Add form to page and submit it to open the OAuth 2.0 endpoint.
    document.body.appendChild(form);
    form.submit();
  }
</script>

<button onclick="trySampleRequest();">Try sample request</button>
</body></html>

Reguły weryfikacji źródła JavaScript

Google stosuje poniższe reguły weryfikacji do źródeł JavaScript, aby ułatwić deweloperom zabezpieczanie aplikacji. Źródła JavaScript muszą być zgodne z tymi regułami. Definicję domeny, hosta i schematu wymienionych poniżej znajdziesz w sekcji 3 standardu RFC 3986.

Reguły weryfikacji
Schemat

Źródła JavaScript muszą używać schematu HTTPS, a nie zwykłego protokołu HTTP. Identyfikatory URI hosta lokalnego (w tym identyfikatory URI adresów IP hosta lokalnego) są wykluczone z tej reguły.

Osoba prowadząca

Hosty nie mogą być nieprzetworzonymi adresami IP. Adresy IP lokalnego hosta są wykluczone z tej reguły.

Domena
  • Domeny TLD hostów (domeny najwyższego poziomu) muszą należeć do listy publicznych sufiksów.
  • Domeny hosta nie mogą być “googleusercontent.com”.
  • Źródła JavaScript nie mogą zawierać domen skracania adresów URL (np. goo.gl), chyba że właścicielem domeny jest aplikacja.
  • Informacje o użytkowniku

    Źródła JavaScript nie mogą zawierać podkomponentu userinfo.

    Ścieżka

    Źródła JavaScript nie mogą zawierać komponentu ścieżki.

    Zapytanie

    Źródła JavaScript nie mogą zawierać komponentu zapytania.

    Fragment

    Źródła JavaScript nie mogą zawierać komponentu fragmentu.

    Znaki Źródło JavaScript nie może zawierać niektórych znaków, w tym:
    • Symbole wieloznaczne ('*')
    • Znaki ASCII niedrukowalne
    • Nieprawidłowe kodowanie procentowe (dowolne kodowanie procentowe, które nie jest kodowane w postaci znaku procentu, po którym występują dwie cyfry szesnastkowe)
    • Znaki null (zakodowany znak NULL, np. %00, %C0%80)

    Autoryzacja przyrostowa

    W ramach protokołu OAuth 2.0 Twoja aplikacja żąda autoryzacji dostępu do zasobów określonych przez zakresy. Zalecamy wysyłanie próśb o autoryzację zasobów w chwili, gdy są potrzebne. Aby to umożliwić, serwer autoryzacji Google obsługuje autoryzację przyrostową. Ta funkcja umożliwia żądanie zakresów, a jeśli użytkownik przyzna uprawnienia do nowego zakresu, zwraca kod autoryzacji, który można wymienić na token zawierający wszystkie zakresy, które użytkownik przyznał projektowi.

    Załóżmy na przykład, że aplikacja pomaga użytkownikom identyfikować interesujące wydarzenia lokalne. Aplikacja pozwala użytkownikom oglądać filmy na temat wydarzeń, oceniać je i dodawać do playlist. Za pomocą tej aplikacji użytkownicy mogą też dodawać wydarzenia do Kalendarza Google.

    W takim przypadku w momencie logowania aplikacja może nie potrzebować żadnych zakresów lub prosić o dostęp do nich. Jeśli jednak użytkownik spróbował ocenić film, dodać go do playlisty lub wykonać inne działanie w YouTube, aplikacja może poprosić o dostęp do zakresu https://www.googleapis.com/auth/youtube.force-ssl. Podobnie aplikacja może poprosić o dostęp do zakresu https://www.googleapis.com/auth/calendar, jeśli użytkownik spróbuje dodać wydarzenie w kalendarzu.

    Te reguły mają zastosowanie do tokena dostępu uzyskanego z autoryzacji przyrostowej:

    • Token może służyć do uzyskiwania dostępu do zasobów odpowiadających dowolnym zakresom uwzględnionym w nowej, połączonej autoryzacji.
    • Gdy użyjesz tokena odświeżania do autoryzacji połączonej, aby uzyskać token dostępu, token dostępu reprezentuje połączoną autoryzację i może być używany dla dowolnej z wartości scope uwzględnionych w odpowiedzi.
    • Połączona autoryzacja obejmuje wszystkie zakresy, które użytkownik przyznał projektowi API, nawet jeśli prośby o zezwolenia pochodziły od różnych klientów. Jeśli na przykład użytkownik przyznał dostęp do jednego zakresu za pomocą klienta komputerowego aplikacji, a następnie przypisał inny zakres tej samej aplikacji za pomocą klienta mobilnego, połączona autoryzacja będzie obejmować oba zakresy.
    • Jeśli unieważnisz token, który reprezentuje łączną autoryzację, dostęp do wszystkich zakresów tej autoryzacji w imieniu powiązanego użytkownika zostanie jednocześnie anulowany.

    Poniżej znajduje się przykładowy kod pokazujący, jak dodać zakresy do istniejącego tokena dostępu. Dzięki temu aplikacja nie będzie musiała zarządzać wieloma tokenami dostępu.

    OAuth 2.0 Endpoints

    W tym przykładzie aplikacja do wykonywania połączeń prosi o dostęp do danych Statystyk YouTube użytkownika, a także o dostęp, który użytkownik przyznał aplikacji.

    Aby dodać zakresy do istniejącego tokena dostępu, umieść parametr include_granted_scopes w żądaniu wysyłanym do serwera OAuth 2.0 Google.

    Fragment kodu poniżej pokazuje, jak to zrobić. W tym fragmencie założono, że zakresy, dla których Twój token dostępu jest zapisany, w pamięci lokalnej przeglądarki. (Pełny przykład zawiera listę zakresów, dla których token dostępu jest prawidłowy. W tym celu należy ustawić właściwość oauth2-test-params.scope w pamięci lokalnej przeglądarki).

    Fragment kodu porównuje zakresy, dla których token dostępu jest prawidłowy, z zakresem, którego chcesz użyć w przypadku konkretnego zapytania. Jeśli token dostępu nie obejmuje tego zakresu, rozpoczyna się przepływ OAuth 2.0. W tym przypadku funkcja oauth2SignIn jest taka sama jak funkcja z kroku 2 (została przedstawiona w dalszej części pełnego przykładu).

    var SCOPE = 'https://www.googleapis.com/auth/youtube.force-ssl';
    var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
    
    var current_scope_granted = false;
    if (params.hasOwnProperty('scope')) {
      var scopes = params['scope'].split(' ');
      for (var s = 0; s < scopes.length; s++) {
        if (SCOPE == scopes[s]) {
          current_scope_granted = true;
        }
      }
    }
    
    if (!current_scope_granted) {
      oauth2SignIn(); // This function is defined elsewhere in this document.
    } else {
      // Since you already have access, you can proceed with the API request.
    }

    Unieważnianie tokena

    W niektórych przypadkach użytkownik może cofnąć dostęp przyznany aplikacji. Użytkownik może anulować dostęp w Ustawieniach konta. Więcej informacji znajdziesz w artykule pomocy Usuwanie dostępu witryny lub aplikacji do Twojego konta.

    Aplikacja może też automatycznie anulować przyznany dostęp. Automatyczne anulowanie jest ważne w sytuacjach, gdy użytkownik anuluje subskrypcję, usuwa aplikację lub znacznie zmieniły się zasoby interfejsu API wymagane przez aplikację. Inaczej mówiąc, część procesu usuwania może obejmować żądanie do interfejsu API dające pewność, że uprawnienia przyznane wcześniej aplikacji zostaną usunięte.

    OAuth 2.0 Endpoints

    Aby automatycznie unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i uwzględnia token jako parametr:

    curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
            https://oauth2.googleapis.com/revoke?token={token}

    Tokenem może być token dostępu lub token odświeżania. Jeśli token jest tokenem dostępu i ma odpowiedni token odświeżania, token odświeżania również zostanie unieważniony.

    Jeśli odwołanie zostanie przetworzone, kod stanu HTTP odpowiedzi będzie miał postać 200. W przypadku wystąpienia błędu zwracany jest kod stanu HTTP 400 wraz z kodem błędu.

    Poniższy fragment kodu JavaScript pokazuje, jak unieważnić token w JavaScript bez użycia biblioteki klienta interfejsów API Google do JavaScriptu. Używany przez Google punkt końcowy OAuth 2.0 służący do unieważniania tokenów nie obsługuje udostępniania zasobów między domenami (CORS), dlatego kod tworzy formularz i przesyła go do punktu końcowego, zamiast korzystać z metody XMLHttpRequest() do opublikowania żądania.

    function revokeAccess(accessToken) {
      // Google's OAuth 2.0 endpoint for revoking access tokens.
      var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke';
    
      // Create <form> element to use to POST data to the OAuth 2.0 endpoint.
      var form = document.createElement('form');
      form.setAttribute('method', 'post');
      form.setAttribute('action', revokeTokenEndpoint);
    
      // Add access token to the form so it is set as value of 'token' parameter.
      // This corresponds to the sample curl request, where the URL is:
      //      https://oauth2.googleapis.com/revoke?token={token}
      var tokenField = document.createElement('input');
      tokenField.setAttribute('type', 'hidden');
      tokenField.setAttribute('name', 'token');
      tokenField.setAttribute('value', accessToken);
      form.appendChild(tokenField);
    
      // Add form to page and submit it to actually revoke the token.
      document.body.appendChild(form);
      form.submit();
    }