OAuth 2.0 na potrzeby aplikacji internetowych po stronie klienta

Ten dokument wyjaśnia, jak wdrożyć autoryzację dostępu OAuth 2.0 Interfejsy API Google z aplikacji internetowej w języku JavaScript. OAuth 2.0 pozwala użytkownikom udostępniać aplikacji określone dane, zachowując nazwy użytkowników, hasła i inne do prywatności danych. Na przykład aplikacja może używać protokołu OAuth 2.0, aby uzyskiwać uprawnienia na przechowywanie plików na Dysku Google przez użytkowników.

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

W ramach tego procesu aplikacja otwiera adres URL Google, który identyfikuje aplikację na podstawie parametrów zapytania oraz typ wymaganego dostępu do interfejsu API. Możesz otworzyć adres URL w bieżącej przeglądarce lub 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 poddać ją weryfikacji, a potem używać jej do wysyłania żądań do interfejsu API.

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

Jeśli używasz biblioteki klienta interfejsów API Google do obsługi JavaScriptu aby wykonywać autoryzowane połączenia do Google, należy używać Biblioteka JavaScript usług tożsamości Google do obsługi przepływu OAuth 2.0. Wejdź na stronę Google usług tożsamości token model, który jest na podstawie przepływu niejawnego uwierzytelnienia protokołu 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 funkcji 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. API Library zawiera listę wszystkich dostępnych interfejsów API pogrupowanych według usługi rodzina i popularność. Jeśli interfejsu API, który chcesz włączyć, nie ma na liście, użyj wyszukiwania, aby znajdź go lub kliknij Wyświetl wszystkie w rodzinie usług, do której należy.
  4. Wybierz interfejs API, który chcesz włączyć, a następnie kliknij przycisk Włącz.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

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 opisujemy, jak utworzysz dane logowania dla swojego projektu. Dzięki temu aplikacje mogą uzyskiwać dostęp do interfejsów API za pomocą danych logowania włączone 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 API Google musi określać autoryzowane źródła JavaScript. Źródła identyfikują domeny za pomocą której 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 umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów. co pozwala użytkownikom kontrolować zakres dostępu przyznawany do aplikacji. Dlatego też może być odwrotną zależnością między liczbą żądanych zakresów a prawdopodobieństwem w celu uzyskania zgody użytkownika.

Przed rozpoczęciem wdrażania autoryzacji OAuth 2.0 zalecamy określenie zakresów do których aplikacja potrzebuje uprawnień dostępu.

Dokument Zakresy interfejsu API OAuth 2.0 zawiera pełne 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

Poniższe kroki pokazują, w jaki sposób Twoja aplikacja współpracuje z serwerem Google OAuth 2.0 w celu zgody użytkownika na wykonanie żądania do interfejsu API w jego imieniu. Aplikacja musi zawierać te uzyskać zgodę użytkownika przed wykonaniem żądania do interfejsu API Google, które wymaga autoryzacji użytkownika.

Krok 1. Przekieruj na serwer OAuth 2.0 Google

Aby poprosić o dostęp do danych użytkownika, przekieruj go do protokołu OAuth 2.0 Google serwera.

OAuth 2.0 Endpoints

Wygeneruj URL, aby poprosić o dostęp z punktu końcowego OAuth 2.0 Google na 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 w przypadku stron internetowych te parametry ciągu zapytania aplikacje serwerowe:

Parametry
client_id Wymagany

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

redirect_uri Wymagany

Określa, dokąd serwer interfejsu API przekierowuje użytkownika po wykonaniu przez użytkownika instrukcji proces autoryzacji. Wartość musi być dokładnie zgodna z jednym z autoryzowanych identyfikatorów URI przekierowania dla klienta OAuth 2.0 skonfigurowanego na API Console Credentials pageJeśli ta wartość nie pasuje do parametru autoryzowany identyfikator URI przekierowania dla podanego adresu client_id otrzymasz Błąd redirect_uri_mismatch.

Zwróć uwagę na schemat http lub https, wielkość liter i ukośnik na końcu („/”) musi pasować.

response_type Wymagany

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

scope Wymagany

O rozdzielane 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żytkownika.

Zakresy umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów oraz prawdopodobieństwo uzyskania zgody użytkownika.

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, ułatwiasz użytkownikom zrozumieć, dlaczego aplikacja potrzebuje dostępu, o który prosi.

state Zalecane

Określa dowolną wartość ciągu, której aplikacja używa do utrzymywania stanu między i odpowiedzi serwera autoryzacji. Serwer zwraca dokładną wartość, która została wysłana jako para name=value w polu Identyfikator fragmentu adresu URL (#) z redirect_uri, gdy użytkownik wyrazi zgodę na o dostęp.

Tego parametru możesz używać do różnych celów, takich jak kierowanie użytkownika do parametru prawidłowe zasoby w aplikacji, wysyłanie żądań jednorazowych i ograniczanie żądań z innych witryn fałszerstwa. redirect_uri można odgadnąć, więc przy użyciu funkcji state możesz zwiększyć pewność, że połączenie przychodzące jest wynikiem żądania uwierzytelnienia. Jeśli generujesz losowy ciąg lub zakodujesz hasz pliku cookie lub innej wartości, która przechwytuje stan klienta, możesz zweryfikować odpowiedź dodatkowo upewnij się, że żądanie i odpowiedź pochodzą z tej samej przeglądarki, które zapewniają ochronę przed atakami takimi jak żądanie z innej witryny fałszerstwa. Zobacz OpenID Connect dokumentację zawierającą przykład tworzenia i potwierdzania tokena state.

include_granted_scopes Opcjonalny

Umożliwia aplikacjom korzystanie z autoryzacji przyrostowej w celu proszenia o dostęp do dodatkowych w kontekście. Jeśli ustawisz wartość tego parametru na true, a parametr żądania autoryzacji, to nowy token dostępu obejmie również wszystkie zakresy do których użytkownik przyznał wcześniej dostęp aplikacji. Zobacz 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 używa podpowiedzi do uprość proces logowania, wstępnie wypełniając pole adresu e-mail w formularzu wybór odpowiedniej sesji wielokrotnego logowania.

Ustaw wartość parametru na adres e-mail lub identyfikator sub, który jest odpowiadający identyfikatorowi Google użytkownika.

prompt Opcjonalny

Rozdzielona spacjami lista promptów, które mają zostać zaprezentowane użytkownikowi. Wielkość liter ma znaczenie. Jeśli nie chcesz określić ten parametr, użytkownik zostanie poproszony tylko przy pierwszym projekcie prosi o dostęp. Zobacz Ponowne wyrażenie zgody, aby uzyskać więcej informacji.

Możliwe wartości to:

none Nie wyświetlaj żadnych ekranów uwierzytelniania ani zgody użytkownika. Nie może być określony jako 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 podano poniżej ze znakami podziału wiersza i spacjami, aby zapewnić czytelność.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

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

Przykładowy kod JavaScript

Poniższy fragment kodu JavaScript pokazuje, jak rozpocząć proces autoryzacji JavaScript bez biblioteki klienta interfejsów API Google dla JavaScriptu. Ponieważ ten protokół OAuth Punkt końcowy 2.0 nie obsługuje współdzielenia zasobów między pochodzeniem (CORS), fragment kodu tworzy który otworzy żądanie 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/drive.metadata.readonly',
                '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 dostęp, o który prosisz. W tym miejscu Google wyświetla okno z prośbą o zgodę, w którym wyświetla się nazwa aplikacji i interfejs API Google usług, do których żąda dostępu za pomocą danych uwierzytelniających użytkownika podsumowanie zakresów dostępu, jakie należy przyznać. użytkownik może wyrazić zgodę na przyznanie dostępu do co najmniej jednego zakresu żądanego przez aplikację lub odrzucić tę prośbę.

Na tym etapie aplikacja nie musi nic robić, ponieważ czeka na odpowiedź Serwer Google OAuth 2.0 wskazujący, czy przyznano dostęp. Odpowiedź ta została wyjaśniona tutaj: w następujący sposób.

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 procesów uwierzytelniania i autoryzacji. Typowe i zalecane kody błędów rozwiązanie problemu znajdziesz poniżej.

admin_policy_enforced

Konto Google nie może autoryzować co najmniej jednego żądanego zakresu ze względu na zasady swoim administratorem Google Workspace. Przeczytaj artykuł pomocy dla administratorów Google Workspace Kontroluj, które zewnętrzne aplikacje wewnętrzne uzyskują dostęp do danych Google Workspace znajdziesz więcej informacji o tym, jak administrator może ograniczać dostęp do wszystkich zakresów lub zakresy z ograniczeniami, dopóki nie zostanie jednoznacznie przyznany dostępowi do identyfikatora klienta OAuth.

disallowed_useragent

Punkt końcowy autoryzacji jest wyświetlany w osadzonym kliencie użytkownika niedozwolonym przez Zasady 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 Logowanie przez Google na Androidzie lub OpenID Foundation AppAuth na Androida.

Deweloperzy stron internetowych mogą napotkać ten błąd, gdy aplikacja na Androida otwiera ogólny link internetowy w osadzony klient użytkownika, a użytkownik przechodzi do punktu końcowego autoryzacji OAuth 2.0 Google w Twojej witrynie. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków systemu operacyjnego, który zawiera Linki aplikacji na Androida modułów obsługi lub domyślnej aplikacji do przeglądania internetu. Karty niestandardowe na 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 Logowanie przez Google na iOS lub OpenID Foundation AppAuth na iOS.

Deweloperzy stron internetowych mogą napotkać ten błąd, gdy aplikacja na iOS lub macOS otworzy ogólny link internetowy w osadzony klient użytkownika, a użytkownik przechodzi do punktu końcowego autoryzacji OAuth 2.0 Google w Twojej witrynie. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków systemu operacyjnego, który zawiera Uniwersalne linki modułów obsługi lub domyślnej aplikacji do przeglądania internetu. SFSafariViewController. .

org_internal

Identyfikator klienta OAuth w żądaniu jest częścią projektu ograniczającego dostęp do kont Google w konkretne Organizacja Google Cloud. Więcej informacji o tej opcji konfiguracji znajdziesz w Typ użytkownika w artykule 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

W przypadku korzystania z autoryzacji przyrostowej token mógł wygasnąć. lub została unieważniona. Uwierzytelnij użytkownika ponownie i poproś o zgodę na uzyskanie nowych tokenów. Jeśli kontynuujesz w przypadku tego błędu. Upewnij się, że aplikacja została poprawnie skonfigurowana używając prawidłowych tokenów i parametrów w żądaniu. W przeciwnym razie konto użytkownika mogło mieć została usunięta lub wyłączona.

origin_mismatch

Schemat, domena i/lub port kodu JavaScript, z których 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

redirect_uri_mismatch

redirect_uri przekazany w żądaniu autoryzacji nie jest zgodny z autoryzowanym URI przekierowania dla identyfikatora klienta OAuth. Przejrzyj autoryzowane identyfikatory URI przekierowania w Google API Console Credentials page.

Schemat, domena i/lub port kodu JavaScript, z których 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 przepływu OAuth, w którym zastosowano została wycofana i nie jest już obsługiwana. Zapoznaj się z przewodnik po migracji, by zaktualizować i integrację społeczną.

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. Zweryfikuj OAuth integracja 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 redirect_uri określonego w żądania 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 we fragmencie z krzyżykiem identyfikatora URI przekierowania jest zwracany komunikat o błędzie, 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 parametr token_type, który jest zawsze ustawiony na Bearer oraz parametru expires_in, który określa czas życia tokena w sekundach. Jeśli parametr state został określony w żądaniu tokena dostępu, jego wartość jest również uwzględniona w odpowiedzi.

  • Odpowiedź o błędzie:
    https://oauth2.example.com/callback#error=access_denied
.

Przykładowa odpowiedź serwera OAuth 2.0

Możesz przetestować ten proces, klikając poniższy przykładowy adres URL, który 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//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Po zakończeniu procesu OAuth 2.0 przekierujemy Cię do strony http://localhost/oauth2callback Ten adres URL wygeneruje 404 NOT FOUND błąd, chyba że na komputerze lokalnym wyświetli się plik pod adresem pod tym adresem. W kolejnym kroku znajdziesz więcej informacji o informacjach zwracanych w Identyfikator URI, gdy użytkownik jest przekierowywany z powrotem do aplikacji.

Wywoływanie interfejsów API Google

OAuth 2.0 Endpoints

Gdy aplikacja uzyska token dostępu, możesz go używać do wywoływania API w imieniu danego konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, dołącz token dostępu w żądaniu wysyłanym do interfejsu API przez dodanie zapytania access_token; lub wartość nagłówka HTTP Authorization Bearer. Jeśli to możliwe, preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. Najwięcej można użyć biblioteki klienta do skonfigurowania wywołań interfejsów API Google (na przykład wywołaniem interfejsu Drive Files API).

Wszystkie interfejsy API Google możesz wypróbować i przejrzeć ich zakresy na stronie OAuth 2.0 Playground.

Przykłady żądań HTTP GET

Wywołanie funkcji drive.files (interfejs Drive Files API) korzystający z protokołu HTTP Authorization: Bearer nagłówek może wyglądać tak: Pamiętaj, że musisz podać własny token dostępu:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl przykładu

Możesz je przetestować za pomocą aplikacji wiersza poleceń curl. Oto przykład wykorzystujący opcję nagłówka HTTP (preferowane):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Przykładowy kod JavaScript

Fragment kodu poniżej pokazuje, jak używać CORS (udostępniania zasobów między domenami) do wysyłania do interfejsu API Google. W tym przykładzie nie korzystamy z biblioteki klienta interfejsów API Google dla JavaScriptu. Nawet jeśli nie korzystasz z biblioteki klienta, pomocy CORS w dokumentacji tej biblioteki. do lepszego zrozumienia tych próśb.

W tym fragmencie kodu zmienna access_token reprezentuje token, uzyskane do wysyłania żądań do interfejsu API w imieniu autoryzowanego użytkownika. Kompletna przykład pokazuje, jak zapisać token w pamięci lokalnej przeglądarki i go pobrać. przy tworzeniu żądania do interfejsu API.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/drive/v3/about?fields=user&' +
    '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 Biblioteka klienta interfejsów API Google do obsługi JavaScriptu. Kod jest przeznaczony dla strony HTML, która wyświetla przycisk spróbuj wysłać żądanie do interfejsu API. Jeśli go klikniesz, 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 Zakres: https://www.googleapis.com/auth/drive.metadata.readonly.
  2. Po przyznaniu (lub odmówieniu) dostępu do co najmniej 1 żądanego zakresu użytkownik jest przekierowywany do stronie oryginalnej, która analizuje token dostępu z ciągu znaków identyfikatora fragmentu.
  3. Strona używa tokena dostępu do przykładowego żądania do interfejsu API.

    Żądanie do interfejsu API wywołuje metodę about.get interfejsu Drive API, aby pobrać dane. informacje o koncie Dysku Google autoryzowanego użytkownika.

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

Dostęp do aplikacji możesz cofnąć w na stronie Uprawnienia Konto 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 dla: YOUR_CLIENT_ID i YOUR_REDIRECT_URI zmiennych, które odpowiadają danych logowania. Zmienna YOUR_REDIRECT_URI powinien zawierać ten sam adres URL, pod którym jest wyświetlana strona. Wartość musi dokładnie pasować do jednego ze autoryzowane identyfikatory URI przekierowania dla klienta OAuth 2.0 skonfigurowane w API Console Credentials page. Jeśli ta wartość nie jest zgodna z autoryzowanym identyfikatorem URI, otrzymasz redirect_uri_mismatch . Twój projekt musi też mieć włączył 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/drive/v3/about?fields=user&' +
          '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/drive.metadata.readonly',
                  '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 te reguły weryfikacji do źródeł JavaScript, aby ułatwić i programistom dbają o bezpieczeństwo swoich aplikacji. Źródła JavaScript muszą być zgodne z tymi regułami. W RFC 3986 (sekcja 3) znajdziesz definicji domeny, hosta i schematu.

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 lokalnego hosta) są zwolnione 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 najwyższego poziomu hosta (Domeny najwyższego poziomu) musi należeć do listy domen publicznych.
  • Domeny hosta nie mogą być “googleusercontent.com”.
  • Źródła JavaScript nie mogą zawierać domen skracania adresów URL (np. goo.gl) chyba że domena należy do aplikacji.
  • 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 zgodne z kodowaniem URL) jako znaku procenta, 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 aplikacja żąda autoryzacji dostępu do zasobów, które są określonych przez zakresy. Wysyłanie prośby o autoryzację jest uważane za najlepszą metodę obsługi użytkownika. aby zawsze mieć dostęp do zasobów, gdy ich potrzebujesz. Aby to umożliwić, serwer autoryzacji Google obsługuje autoryzację przyrostową. Ta funkcja pozwala prosić o zakresy w razie potrzeby. jeśli użytkownik przyzna uprawnienia dla nowego zakresu, zwraca kod autoryzacji, który może być wymienionych na token zawierający wszystkie zakresy, które użytkownik przyznał projektowi.

    Na przykład aplikacja, która umożliwia próbkowanie utworów i tworzenie składanek, może wymagać zasobów podczas logowania, prawdopodobnie tylko imienia i nazwiska osoby, która się loguje. Pamiętaj jednak: zapisanie gotowej składanki wymagałoby dostępu do Dysku Google. Większość osób uzna to by było to jasne, jeśli użytkownik otrzymał prośbę o dostęp do Dysku Google tylko w momencie, gdy aplikacja było tego potrzebne.

    W takim przypadku podczas logowania aplikacja może zażądać tych uprawnień: openid oraz profile zakresów, aby wykonać podstawowe logowanie, a później zażądać https://www.googleapis.com/auth/drive.file zakres w momencie pierwszego żądania zapisania składanka.

    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 nowa, połączona autoryzacja.
    • Gdy użyjesz tokena odświeżania w ramach połączonej autoryzacji w celu uzyskania tokena dostępu, token dostępu reprezentuje łączną autoryzację i może być używany do Odpowiedź zawiera scope wartości.
    • Połączona autoryzacja obejmuje wszystkie zakresy, które użytkownik przyznał projektowi API, nawet jeśli , jeśli o granty poproszono różnych klientów. Jeśli na przykład użytkownik przyznał dostęp jeden zakres za pomocą klienta komputerowego aplikacji, a następnie przyznano inny zakres temu samemu za pomocą klienta mobilnego, połączona autoryzacja obejmowała oba zakresy.
    • Unieważnienie tokena reprezentującego kombinację autoryzacji spowoduje, że uzyskasz dostęp do wszystkich zakresy autoryzacji w imieniu powiązanego użytkownika zostają anulowane jednocześnie.
    .

    Poniżej znajduje się przykładowy kod pokazujący, jak dodać zakresy do istniejącego tokena dostępu. Takie podejście pozwala w aplikacji, aby uniknąć konieczności zarządzania wieloma tokenami dostępu.

    OAuth 2.0 Endpoints

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

    Fragment kodu poniżej pokazuje, jak to zrobić. Fragment zakłada, że zapisane dane zakresy, dla których token dostępu jest prawidłowy w pamięci lokalnej przeglądarki. (Parametr pełny przykład zawiera listę zakresów, dla których token dostępu jest prawidłowe po ustawieniu właściwości oauth2-test-params.scope w ustawieniach storage.)

    Fragment kodu porównuje zakresy, dla których token dostępu jest prawidłowy, z zakresem, którego chcesz użyć dla 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 podana w kroku 2 (opisanego później w pełnym przykład).

    var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly';
    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 odwiedzając stronę Ustawienia konta. Zobacz Usuń sekcji dostępu do witryny lub aplikacji na stronie Witryny innych firm aplikacje, które mają dostęp do Twojego konta dokumentu pomocy, aby dowiedzieć się więcej.

    Aplikacja może też automatycznie anulować przyznany dostęp. Automatyczne unieważnienie jest ważne wtedy, gdy użytkownik anuluje subskrypcję, usuwa aplikacji lub zasoby API wymagane przez aplikację znacznie się zmieniły. Innymi słowy, może obejmować żądanie do interfejsu API mające na celu zapewnienie, że uprawnienia danych aplikacji są usuwane.

    OAuth 2.0 Endpoints

    Aby automatycznie unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i zawiera 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 parametr 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. z kodem błędu.

    Poniższy fragment kodu JavaScript pokazuje, jak unieważnić token w JavaScript bez użycia Biblioteka klienta interfejsów API Google do obsługi JavaScriptu. Ponieważ punkt końcowy OAuth 2.0 Google do unieważniania tokeny nie obsługują współdzielenia zasobów między domenami (CORS), kod tworzy formularz i przesyła do punktu końcowego, zamiast używać metody XMLHttpRequest() do publikowania użytkownika.

    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();
    }

    Wdrażanie Ochrony wszystkich kont

    Dodatkowy krok, który musisz wykonać, aby chronić użytkowników Liczba kont, na których jest zaimplementowane kilka kont ochrony dzięki korzystaniu z oferowanej przez Google usługi ochrony wszystkich kont. Ta usługa pozwala subskrybować powiadomienia o zdarzeniach związanych z bezpieczeństwem, które dostarczają do aplikacji informacje na temat: na koncie użytkownika. Następnie możesz wykorzystać te informacje do podjęcia działań w zależności od tego, podejmowania decyzji o reagowaniu na zdarzenia.

    Oto kilka przykładów typów zdarzeń wysyłanych do Twojej aplikacji przez usługę ochrony wszystkich kont Google:

    • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
    • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
    • https://schemas.openid.net/secevent/risc/event-type/account-disabled

    Zobacz Ochrona kont użytkowników za pomocą strony Ochrona wszystkich kont . , aby dowiedzieć się więcej o wdrażaniu Ochrony wszystkich kont i pełnej listy dostępnych zdarzeń.