Korzystanie z protokołu OAuth 2.0 w aplikacjach serwerowych

Ten dokument wyjaśnia, jak aplikacje serwerów WWW korzystają z bibliotek klienta interfejsów API Google lub usług Google punkty końcowe OAuth 2.0 w celu implementacji autoryzacji OAuth 2.0 na potrzeby dostępu interfejsów API Google.

OAuth 2.0 pozwala użytkownikom udostępniać określone dane aplikacji przy zachowaniu nazw użytkowników, haseł i innych informacji. 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 proces OAuth 2.0 jest przeznaczony specjalnie do autoryzacji użytkowników. Zaprojektowano ją z myślą które mogą przechowywać poufne informacje i utrzymywać stan. Prawidłowo autoryzowany serwer WWW aplikacja może uzyskiwać dostęp do interfejsu API, gdy użytkownik wchodzi w interakcję z aplikacją lub po nim Uczestnik odłączył aplikację.

Aplikacje serwerów WWW często używają też kont usługi do autoryzowania żądań do interfejsów API, zwłaszcza przy wywoływaniu Cloud APIs w celu uzyskania dostępu na podstawie danych projektowych, a nie danych poszczególnych użytkowników. Aplikacje serwera WWW mogą używać usługi w połączeniu z autoryzacją użytkownika.

Biblioteki klienta

W przykładach w różnych językach na tej stronie jest używany Biblioteki klienta interfejsów API Google do wdrożenia Autoryzacja OAuth 2.0. Aby uruchomić przykładowy kod, musisz najpierw zainstalować biblioteki klienta w Twoim języku.

Jeśli do obsługi przepływu aplikacji OAuth 2.0 używasz biblioteki klienta interfejsu API Google, klient wykonuje wiele działań, które aplikacja musiałaby wykonać sama. Dla: na przykład określa, kiedy aplikacja może używać lub odświeżyć zapisanych tokenów dostępu, a także gdy aplikacja musi wymagać zgody. Prawidłowe przekierowanie generuje też biblioteka klienta Adresy URL i ułatwiają wdrażanie modułów obsługi przekierowań, które wymieniają kody autoryzacji na tokeny dostępu.

Biblioteki klienta interfejsów API Google do aplikacji po stronie serwera są dostępne w następujących językach:

.

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 i kliknij Utwórz. Aplikacje korzystające z języków i platform (na przykład PHP, Java, Python, Ruby i .NET) muszą mieć określone autoryzowane identyfikatory URI przekierowania. Identyfikatory URI przekierowania to punkty końcowe, do których serwer OAuth 2.0 może wysyłać odpowiedzi. Te punkty końcowe muszą być zgodne z regułami weryfikacji Google.

    Na potrzeby testowania możesz podać identyfikatory URI odnoszące się do komputera lokalnego, na przykład http://localhost:8080 Mając to na uwadze, pamiętaj, że wszystkie W przykładach w tym dokumencie identyfikator URI przekierowania to http://localhost:8080.

    Zalecamy zaprojektowanie punktów końcowych uwierzytelniania aplikacji, że aplikacja nie udostępnia kodów autoryzacji innym zasobom w stronę.

Po utworzeniu danych logowania pobierz plik client_secret.json z API ConsoleBezpiecznie przechowuj plik w lokalizacji, w której aplikacji.

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.

Zalecamy też, aby aplikacja żądała dostępu do zakresów autoryzacji za pomocą dodatkowego procesu autoryzacji, w ramach którego prosi o dostęp do danych użytkownika w kontekście. Ta sprawdzona metoda pomaga użytkownikom dlaczego aplikacja potrzebuje dostępu, o który prosi.

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.

Wymagania dla poszczególnych języków

Aby uruchomić przykładowy kod z tego dokumentu, musisz mieć konto Google, dostęp do Internet i przeglądarka. Jeśli używasz jednej z bibliotek klienta interfejsu API, zapoznaj się też wymagania dotyczące określonych języków.

PHP

Do uruchomienia przykładowego kodu w języku PHP w tym dokumencie będziesz potrzebować:

  • Interfejs PHP w wersji 5.6 lub nowszej z zainstalowanym interfejsem wiersza poleceń i rozszerzeniem JSON.
  • Narzędzie do zarządzania zależnościami Composer.

  • Biblioteka klienta interfejsów API Google do języka PHP:

    composer require google/apiclient:^2.10

Python

Do uruchomienia przykładowego kodu w Pythonie w tym dokumencie będziesz potrzebować:

  • Python w wersji 2.6 lub nowszej
  • Narzędzie do zarządzania pakietami pip.
  • Biblioteka klienta interfejsów API Google do języka Python: 
    pip install --upgrade google-api-python-client
  • google-auth, google-auth-oauthlib i google-auth-httplib2 do autoryzacji użytkownika. 
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • platforma aplikacji internetowej Flask w Pythonie. 
    pip install --upgrade flask
  • Biblioteka HTTP requests. 
    pip install --upgrade requests

Ruby

Aby uruchomić przykładowy kod Ruby w tym dokumencie, musisz mieć:

  • Ruby w wersji 2.6 lub nowszej

  • Google Auth Library dla Ruby:

    gem install googleauth

  • platforma aplikacji internetowej Sinatra Ruby;

    gem install sinatra

Node.js

Do uruchomienia przykładowego kodu w środowisku Node.js w tym dokumencie będziesz potrzebować:

  • Konserwacyjny kanał LTS, aktywny kanał LTS lub bieżąca wersja Node.js.

  • Klient Node.js interfejsów API Google:

    npm install googleapis crypto express express-session

HTTP/REST

Nie musisz instalować żadnych bibliotek, aby móc bezpośrednio wywoływać OAuth 2.0 i punktów końcowych.

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.

Oto krótkie podsumowanie tych czynności:

  1. Aplikacja określa wymagane uprawnienia.
  2. Aplikacja przekierowuje użytkownika do Google wraz z listą żądanych żądań uprawnień.
  3. Użytkownik decyduje, czy przyznać aplikacji uprawnienia.
  4. Aplikacja uzyskuje informacje na temat decyzji użytkownika.
  5. Jeśli użytkownik przyznał odpowiednie uprawnienia, aplikacja pobiera tokeny potrzebne do wysyłania żądań do interfejsu API w imieniu użytkownika.

Krok 1. Ustaw parametry autoryzacji

Pierwszym krokiem jest utworzenie żądania autoryzacji. Żądanie to ustawia parametry, które Zidentyfikuj swoją aplikację i zdefiniuj uprawnienia, które będzie musiał przyznać użytkownik Twojej aplikacji.

  • Jeśli używasz biblioteki klienta Google do uwierzytelniania i autoryzacji OAuth 2.0, utworzysz i skonfigurujesz obiekt definiujący te parametry.
  • Jeśli wywołasz punkt końcowy Google OAuth 2.0 bezpośrednio, wygenerujesz URL i ustawisz parametr dla tego adresu URL.

Poniższe karty określają obsługiwane parametry autoryzacji aplikacji serwera WWW. przykłady w konkretnych językach pokazują też, jak używać biblioteki klienta lub biblioteki autoryzacji do skonfigurować obiekt ustawiający te parametry.

PHP

Poniższy fragment kodu tworzy obiekt Google\Client(), który definiuje w żądaniu autoryzacji.

Ten obiekt wykorzystuje informacje z pliku client_secret.json do identyfikowania aplikacji. Więcej informacji znajdziesz w artykule o tworzeniu danych uwierzytelniających. ten plik). Obiekt określa też zakresy, o które aplikacja prosi o uprawnienia. oraz adres URL punktu końcowego uwierzytelniania aplikacji, który przetwarza odpowiedź z Serwer OAuth 2.0 Google. Na koniec kod ustawia opcjonalne wartości access_type i include_granted_scopes.

Na przykład ten kod wymaga dostępu offline (tylko do odczytu) do Dysk Google: 

$client = new Google\Client();

// Required, call the setAuthConfig function to load authorization credentials from
// client_secret.json file.
$client->setAuthConfig('client_secret.json');

// Required, to set the scope value, call the addScope function
$client->addScope(Google\Service\Drive::DRIVE_METADATA_READONLY);

// Required, call the setRedirectUri function to specify a valid redirect URI for the
// provided client_id
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');

// Recommended, offline access will give you both an access and refresh token so that
// your app can refresh the access token without user interaction.
$client->setAccessType('offline');

// Recommended, call the setState function. Using a state value can increase your assurance that
// an incoming connection is the result of an authentication request.
$client->setState($sample_passthrough_value);

// Optional, if your application knows which user is trying to authenticate, it can use this
// parameter to provide a hint to the Google Authentication Server.
$client->setLoginHint('hint@example.com');

// Optional, call the setPrompt function to set "consent" will prompt the user for consent
$client->setPrompt('consent');

// Optional, call the setIncludeGrantedScopes function with true to enable incremental
// authorization
$client->setIncludeGrantedScopes(true);

Python

Następujący fragment kodu korzysta z modułu google-auth-oauthlib.flow do utworzenia z żądaniem autoryzacji.

Kod tworzy obiekt Flow, który identyfikuje aplikację za pomocą z pliku client_secret.json pobranego po tworzenie danych uwierzytelniających. Ten obiekt identyfikuje również zakresy, do których aplikacja żąda uprawnień dostępu, oraz adres URL punktu końcowego auth, który będzie obsługiwać odpowiedź z serwera Google OAuth 2.0. Kod ustawia opcjonalne parametry access_type i include_granted_scopes.

Na przykład ten kod wymaga dostępu offline (tylko do odczytu) do Dysk Google: 

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Required, call the from_client_secrets_file method to retrieve the client ID from a
# client_secret.json file. The client ID (from that file) and access scopes are required. (You can
# also use the from_client_config method, which passes the client configuration as it originally
# appeared in a client secrets file but doesn't access the file itself.)
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

# Required, indicate where the API server will redirect the user after the user completes
# the authorization flow. The redirect URI is required. The value must exactly
# match one of the authorized redirect URIs for the OAuth 2.0 client, which you
# configured in the API Console. If this value doesn't match an authorized URI,
# you will get a 'redirect_uri_mismatch' error.
flow.redirect_uri = 'https://www.example.com/oauth2callback'

# Generate URL for request to Google's OAuth 2.0 server.
# Use kwargs to set optional request parameters.
authorization_url, state = flow.authorization_url(
    # Recommended, enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Optional, enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true',
    # Optional, if your application knows which user is trying to authenticate, it can use this
    # parameter to provide a hint to the Google Authentication Server.
    login_hint='hint@example.com',
    # Optional, set prompt to 'consent' will prompt the user for consent
    prompt='consent')

Ruby

Użyj utworzonego pliku client_secrets.json, aby skonfigurować obiekt klienta w aplikacji. Podczas konfigurowania obiektu klienta określasz zakresy, których potrzebuje aplikacja dostępu wraz z adresem URL do punktu końcowego uwierzytelniania aplikacji, który przetwarza odpowiedź z serwera OAuth 2.0.

Na przykład ten kod wymaga dostępu offline (tylko do odczytu) do Dysk Google: 

require 'google/apis/drive_v3'
require "googleauth"
require 'googleauth/stores/redis_token_store'

client_id = Google::Auth::ClientId.from_file('/path/to/client_secret.json')
scope = 'https://www.googleapis.com/auth/drive.metadata.readonly'
token_store = Google::Auth::Stores::RedisTokenStore.new(redis: Redis.new)
authorizer = Google::Auth::WebUserAuthorizer.new(client_id, scope, token_store, '/oauth2callback')

Twoja aplikacja używa obiektu klienckiego do wykonywania operacji OAuth 2.0, np. generowania adresów URL żądań autoryzacji i stosowania tokenów dostępu do żądań HTTP.

Node.js

Ten fragment kodu tworzy obiekt google.auth.OAuth2, który definiuje w żądaniu autoryzacji.

Ten obiekt identyfikuje aplikację na podstawie informacji z pliku client_secret.json. Do prosisz użytkownika o zgodę na pobranie tokena dostępu, a następnie przekierowujesz go na stronę z prośbą o zgodę na przetwarzanie danych. Aby utworzyć adres URL strony z prośbą o zgodę na przetwarzanie danych: 

const {google} = require('googleapis');
const crypto = require('crypto');
const express = require('express');
const session = require('express-session');

/**
 * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI
 * from the client_secret.json file. To get these credentials for your application, visit
 * https://console.cloud.google.com/apis/credentials.
 */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Drive activity.
const scopes = [
  'https://www.googleapis.com/auth/drive.metadata.readonly'
];

// Generate a secure random state value.
const state = crypto.randomBytes(32).toString('hex');

// Store state in the session
req.session.state = state;

// Generate a url that asks permissions for the Drive activity scope
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as a best practice.
  include_granted_scopes: true,
  // Include the state parameter to reduce the risk of CSRF attacks.
  state: state
});

Ważna uwaga: refresh_token jest zwracany tylko pierwszego dnia autoryzacji. Więcej szczegółów tutaj.

HTTP/REST

Punkt końcowy OAuth 2.0 Google jest pod adresem https://accounts.google.com/o/oauth2/v2/auth. Ten Punkt końcowy jest dostępny tylko 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

Określa, czy punkt końcowy Google OAuth 2.0 zwraca kod autoryzacji.

W przypadku aplikacji serwera WWW ustaw parametr na code.
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.
access_type Zalecane

Wskazuje, czy aplikacja może odświeżać tokeny dostępu, gdy użytkownika nie jest obecny w przeglądarce. Prawidłowe wartości parametrów to online (jest to wartość domyślna). i offline.

Ustaw wartość offline, jeśli aplikacja musi odświeżać tokeny dostępu gdy użytkownik nie korzysta z przeglądarki. To jest metoda odświeżania dostępu tokenów opisanych w dalszej części tego dokumentu. Ta wartość instruuje autoryzację Google serwer zwraca token odświeżania oraz token dostępu, gdy aplikacja wymienia kod autoryzacji na tokeny.
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 Komponent zapytania o adres URL (?) elementu 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.

Krok 2. Przekieruj na serwer OAuth 2.0 Google

Przekieruj użytkownika na serwer Google OAuth 2.0, aby zainicjować uwierzytelnianie i proces autoryzacji. Zwykle dzieje się tak, gdy aplikacja po raz pierwszy musi uzyskać dostęp do danych użytkownika. W przypadku dodatkowej autoryzacji ten ma miejsce również wtedy, gdy aplikacja po raz pierwszy potrzebuje dostępu do dodatkowych zasobów, nie mają jeszcze uprawnień dostępu.

PHP

  1. Wygeneruj URL, aby poprosić o dostęp z serwera Google OAuth 2.0: 
    $auth_url = $client->createAuthUrl();
  2. Przekieruj użytkownika do usługi $auth_url: 
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

Python

Ten przykład pokazuje, jak przekierować użytkownika na adres URL autoryzacji za pomocą strony Flask schemat aplikacji:

return flask.redirect(authorization_url)

Ruby

  1. Wygeneruj URL, aby poprosić o dostęp z serwera Google OAuth 2.0: 
    auth_uri = authorizer.get_authorization_url(login_hint: user_id, request: request)
  2. Przekieruj użytkownika na stronę auth_uri.

Node.js

  1. Użyj adresu URL wygenerowanego authorizationUrl z kroku 1 Metoda generateAuthUrl żądania dostępu z serwera Google OAuth 2.0.
  2. Przekieruj użytkownika na stronę authorizationUrl. 
    res.redirect(authorizationUrl);

HTTP/REST

Sample redirect to Google's authorization server

An example URL is shown below, with line breaks and spaces for readability.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 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.

Serwer OAuth Google 2.0 uwierzytelnia użytkownika i uzyskuje od niego zgodę na aplikacji do uzyskiwania dostępu do żądanych zakresów. Odpowiedź jest wysyłana z powrotem do aplikacji używając podanego adresu URL.

Krok 3. 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

Tajny klucz klienta OAuth jest nieprawidłowy. Zapoznaj się z Klient OAuth , w tym identyfikator klienta i klucz tajny użyte w przypadku tego żądania.

invalid_grant

W przypadku odświeżania tokena dostępu lub użycia: 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 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.

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.

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 4. Przetwórz odpowiedź serwera OAuth 2.0

Serwer OAuth 2.0 odpowiada na żądanie dostępu aplikacji, korzystając z podanego adresu URL do danego wniosku.

Jeśli użytkownik zatwierdzi prośbę o dostęp, odpowiedź będzie zawierać kod autoryzacji. Jeśli użytkownik nie zatwierdzi żądania, odpowiedź będzie zawierać komunikat o błędzie. kod autoryzacji lub komunikat o błędzie zwrócony do serwera WWW pojawia się w zapytaniu ciągu znaków, jak poniżej:

Odpowiedź o błędzie:

https://oauth2.example.com/auth?error=access_denied

Odpowiedź kodu autoryzacji:

https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

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&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Po zakończeniu procesu OAuth 2.0 powinno nastąpić przekierowanie do http://localhost/oauth2callback, która prawdopodobnie wygeneruje 404 NOT FOUND, chyba że komputer lokalny wyświetla plik pod tym adresem. Możesz też podać więcej szczegółów na temat informacji zwracanych w identyfikatorze URI, gdy użytkownik nastąpiło przekierowanie z powrotem do aplikacji.

Krok 5. Kod autoryzacji Exchange w celu odświeżenia i dostępu tokeny

Gdy serwer WWW otrzyma kod autoryzacji, może wymienić kod autoryzacji dla tokena dostępu.

PHP

Aby wymienić kod autoryzacji na token dostępu, użyj interfejsu authenticate :

$client->authenticate($_GET['code']);

Token dostępu możesz pobrać za pomocą metody getAccessToken:

$access_token = $client->getAccessToken();

Python

Na stronie wywołania zwrotnego użyj biblioteki google-auth, aby zweryfikować autoryzację odpowiedź serwera. Następnie użyj metody flow.fetch_token, aby wymienić autoryzację dla tokena dostępu:

state = flask.session['state']
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'],
    state=state)
flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

authorization_response = flask.request.url
flow.fetch_token(authorization_response=authorization_response)

# Store the credentials in the session.
# ACTION ITEM for developers:
#     Store user's access and refresh tokens in your data store if
#     incorporating this code into your real app.
credentials = flow.credentials
flask.session['credentials'] = {
    'token': credentials.token,
    'refresh_token': credentials.refresh_token,
    'token_uri': credentials.token_uri,
    'client_id': credentials.client_id,
    'client_secret': credentials.client_secret,
    'scopes': credentials.scopes}

Ruby

Na stronie wywołania zwrotnego użyj biblioteki googleauth, aby zweryfikować serwer autoryzacji . Użyj metody authorizer.handle_auth_callback_deferred, aby zapisać parametr i przekieruj z powrotem na adres URL, z którego pochodziła prośba o autoryzację. Ten opóźnia wymianę kodu przez tymczasowe przechowywanie wyników w sesji użytkownika.

  target_url = Google::Auth::WebUserAuthorizer.handle_auth_callback_deferred(request)
  redirect target_url

Node.js

Aby wymienić kod autoryzacji na token dostępu, użyj interfejsu getToken :

const url = require('url');

// Receive the callback from Google's OAuth 2.0 server.
app.get('/oauth2callback', async (req, res) => {
  let q = url.parse(req.url, true).query;

  if (q.error) { // An error response e.g. error=access_denied
    console.log('Error:' + q.error);
  } else if (q.state !== req.session.state) { //check state value
    console.log('State mismatch. Possible CSRF attack');
    res.end('State mismatch. Possible CSRF attack');
  } else { // Get access and refresh tokens (if access_type is offline)

    let { tokens } = await oauth2Client.getToken(q.code);
    oauth2Client.setCredentials(tokens);
});

HTTP/REST

Aby wymienić kod autoryzacji na token dostępu, wywołaj metodę https://oauth2.googleapis.com/token i ustaw te parametry:

Pola
client_id Identyfikator klienta uzyskany z API Console Credentials page
client_secret Tajny klucz klienta uzyskany z API Console Credentials page
code Kod autoryzacji zwrócony z pierwszego żądania.
grant_type Zgodnie z definicją w protokole OAuth 2.0 specyfikacji, wartość tego pola musi być ustawiona na authorization_code.
redirect_uri Jeden z identyfikatorów URI przekierowania wymienionych w projekcie API Console Credentials page dla danego client_id

Oto przykładowy fragment kodu:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

Google w odpowiedzi na to żądanie zwraca obiekt JSON z dostępem krótkotrwałym. token i token odświeżania. Pamiętaj, że token odświeżania jest zwracany tylko wtedy, gdy aplikacja ustawiła access_type. na offline w pierwszym żądaniu wysyłanym do Google serwera autoryzacji.

Odpowiedź zawiera te pola:

Pola
access_token Token wysyłany przez aplikację do autoryzowania żądania do interfejsu API Google.
expires_in Pozostały czas ważności tokena dostępu (w sekundach).
refresh_token Token, którego możesz użyć do uzyskania nowego tokena dostępu. Tokeny odświeżania są ważne do Użytkownik anuluje dostęp. Również w tym przypadku to pole występuje w tej odpowiedzi tylko wtedy, gdy ustawisz access_type na offline w początkowym żądaniu wysyłanym do serwera autoryzacji Google.
scope Zakresy dostępu przyznane przez access_token wyrażone jako lista ciągów tekstowych rozdzielanych spacjami, w których wielkość liter ma znaczenie.
token_type Typ zwróconego tokena. Obecnie wartość tego pola jest zawsze ustawiona na Bearer

Ten fragment kodu zawiera przykładową odpowiedź:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Błędy

Podczas wymiany kodu autoryzacji na token dostępu możesz napotkać następujące elementy zamiast oczekiwanej odpowiedzi. Typowe kody błędów i sugerowane rozwiązania to: wymienionych poniżej.

invalid_grant

Podany kod autoryzacji jest nieprawidłowy lub ma nieprawidłowy format. Poproś o nowy kod do ponowne uruchomienie procesu OAuth w celu wyświetlenia użytkownikowi prośby o zgodę na wykorzystanie danych. ponownie.

Wywoływanie interfejsów API Google

PHP

Aby wywołać interfejsy API Google, użyj tokena dostępu, wykonując te czynności:

  1. Jeśli musisz zastosować token dostępu do nowego obiektu Google\Client – dla na przykład jeśli token dostępu jest przechowywany w sesji użytkownika, użyj Metoda setAccessToken: 
    $client->setAccessToken($access_token);
  2. Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać. Obiekt usługi tworzysz przez udostępniając autoryzowany obiekt Google\Client konstruktorowi dla interfejsu API nawiązać połączenie. Aby na przykład wywołać interfejs Drive API: 
    $drive = new Google\Service\Drive($client);
  3. Wysyłaj żądania do usługi interfejsu API za pomocą interfejsu udostępnianego przez obiekt usługi. Aby na przykład wyświetlić listę plików na Dysku Google uwierzytelnionego użytkownika: 
    $files = $drive->files->listFiles(array())->getItems();

Python

Po uzyskaniu tokena dostępu aplikacja może używać go do autoryzowania żądań do interfejsu API danego konta użytkownika lub konta usługi. Używanie danych uwierzytelniających konkretnego użytkownika do utworzenia obiektu usługi dla interfejsu API, który chcesz wywołać, a następnie użyć tego obiektu do utworzenia autoryzowane żądania API.

  1. Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać. Obiekt usługi tworzysz przez wywołanie metody build biblioteki googleapiclient.discovery z parametrem nazwę i wersję interfejsu API oraz dane logowania użytkownika: Aby na przykład wywołać wersję 3 interfejsu Drive API: 
    from googleapiclient.discovery import build

drive = build('drive', 'v2', credentials=credentials)
  2. Wysyłaj żądania do usługi interfejsu API za pomocą interfejsu udostępnianego przez obiekt usługi. Aby na przykład wyświetlić listę plików na Dysku Google uwierzytelnionego użytkownika: 
    files = drive.files().list().execute()

Ruby

Po uzyskaniu tokena dostępu aplikacja może używać go do wysyłania żądań do interfejsu API danego konta użytkownika lub konta usługi. Używanie danych uwierzytelniających konkretnego użytkownika do utworzenia obiektu usługi dla interfejsu API, który chcesz wywołać, a następnie użyć tego obiektu do utworzenia autoryzowane żądania API.

  1. Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać. Aby na przykład wywołać wersję 3 interfejsu Drive API: 
    drive = Google::Apis::DriveV3::DriveService.new
  2. Ustaw dane logowania do usługi: 
    drive.authorization = credentials
  3. Wysyłaj żądania do usługi interfejsu API za pomocą interfejs udostępniane przez obiekt usługi. Aby na przykład wyświetlić listę plików na Dysku Google uwierzytelnionego użytkownika: 
    files = drive.list_files

Autoryzację można też przeprowadzić w przypadku poszczególnych metod, podając atrybut Parametr options metody:

files = drive.list_files(options: { authorization: credentials })

Node.js

Gdy uzyskasz token dostępu i ustawisz go na obiekt OAuth2, użyj tego do wywoływania interfejsów API Google. Aplikacja może używać tego tokena do autoryzowania żądań interfejsu API w imieniu: dane konto użytkownika lub konto usługi. Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać.

const { google } = require('googleapis');

// Example of using Google Drive API to list filenames in user's Drive.
const drive = google.drive('v3');
drive.files.list({
  auth: oauth2Client,
  pageSize: 10,
  fields: 'nextPageToken, files(id, name)',
}, (err1, res1) => {
  if (err1) return console.log('The API returned an error: ' + err1);
  const files = res1.data.files;
  if (files.length) {
    console.log('Files:');
    files.map((file) => {
      console.log(`${file.name} (${file.id})`);
    });
  } else {
    console.log('No files found.');
  }
});

HTTP/REST

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

Pełny przykład

Poniższy przykład umożliwia wydrukowanie w formacie JSON listy plików na Dysku Google użytkownika po fragmencie użytkownik uwierzytelnia się i wyraża zgodę na dostęp aplikacji do metadanych użytkownika na Dysku.

PHP

Aby uruchomić ten przykład:

  1. W pliku API Consoledodaj adres URL komputera lokalnego do pliku listę przekierowań. Na przykład dodaj http://localhost:8080.
  2. Utwórz nowy katalog i przejdź do niego. Na przykład: 
    mkdir ~/php-oauth2-example
cd ~/php-oauth2-example
  3. Instalowanie klienta interfejsu API Google Biblioteka PHP w usłudze Composer: 
    composer require google/apiclient:^2.10
  4. Utwórz pliki index.php i oauth2callback.php wraz z treścią poniżej.
  5. Uruchom ten przykład z serwerem WWW skonfigurowanym do obsługi języka PHP. Jeśli używasz PHP w wersji 5.6 lub nowszej, może użyć wbudowanego testowego serwera WWW PHP: 
    php -S localhost:8080 ~/php-oauth2-example

index.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google\Client();
$client->setAuthConfig('client_secrets.json');
$client->addScope(Google\Service\Drive::DRIVE_METADATA_READONLY);

if (isset($_SESSION['access_token']) && $_SESSION['access_token']) {
  $client->setAccessToken($_SESSION['access_token']);
  $drive = new Google\Service\Drive($client);
  $files = $drive->files->listFiles(array())->getItems();
  echo json_encode($files);
} else {
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

oauth2callback.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google\Client();
$client->setAuthConfigFile('client_secrets.json');
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
$client->addScope(Google\Service\Drive::DRIVE_METADATA_READONLY);

if (! isset($_GET['code'])) {
  // Generate and set state value
  $state = bin2hex(random_bytes(16));
  $client->setState($state);
  $_SESSION['state'] = $state;

  $auth_url = $client->createAuthUrl();
  header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
} else {
  // Check the state value
  if (!isset($_GET['state']) || $_GET['state'] !== $_SESSION['state']) {
    die('State mismatch. Possible CSRF attack.');
  }
  $client->authenticate($_GET['code']);
  $_SESSION['access_token'] = $client->getAccessToken();
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

Python

W tym przykładzie użyto platformy Flask. it uruchamia aplikację internetową pod adresem http://localhost:8080, która pozwala przetestować OAuth 2.0 przepływu danych. Jeśli przejdziesz do tego adresu URL, powinny wyświetlić się 4 linki:

  • Testowanie żądania do interfejsu API: ten link wskazuje stronę, która próbuje wykonać przykładowy interfejs API. użytkownika. W razie potrzeby uruchamia proces autoryzacji. Jeśli operacja się uda, na stronie pojawi się Odpowiedź interfejsu API.
  • Przetestuj bezpośrednio proces uwierzytelniania: ten link prowadzi do strony, która próbuje wysłać użytkownika procesu autoryzacji. Aplikacja prosi o pozwolenie na: przesyłania autoryzowanych żądań do interfejsu API w imieniu użytkownika.
  • Unieważnij bieżące dane logowania: ten link wskazuje stronę, która anuluje uprawnienia, które użytkownik już przyznał aplikacji.
  • Wyczyść dane logowania sesji Flask: ten link usuwa dane uwierzytelniające, które są zapisanych w sesji Flask. Dzięki temu można zobaczyć, co by się stało, gdyby użytkownik, który już wcześniej aplikacja, której przyznano uprawnienia, próbowała wykonać żądanie do interfejsu API w nowej sesji. Pozwala też zobaczysz odpowiedź interfejsu API, którą otrzymałaby Twoja aplikacja, gdyby użytkownik unieważnił uprawnienia a aplikacja nadal próbowała autoryzować żądanie za pomocą unieważnionego tokena dostępu.
. 
# -*- coding: utf-8 -*-

import os
import flask
import requests

import google.oauth2.credentials
import google_auth_oauthlib.flow
import googleapiclient.discovery

# This variable specifies the name of a file that contains the OAuth 2.0
# information for this application, including its client_id and client_secret.
CLIENT_SECRETS_FILE = "client_secret.json"

# This OAuth 2.0 access scope allows for full read/write access to the
# authenticated user's account and requires requests to use an SSL connection.
SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly']
API_SERVICE_NAME = 'drive'
API_VERSION = 'v2'

app = flask.Flask(__name__)
# Note: A secret key is included in the sample so that it works.
# If you use this code in your application, replace this with a truly secret
# key. See https://flask.palletsprojects.com/quickstart/#sessions.
app.secret_key = 'REPLACE ME - this value is here as a placeholder.'


@app.route('/')
def index():
  return print_index_table()


@app.route('/test')
def test_api_request():
  if 'credentials' not in flask.session:
    return flask.redirect('authorize')

  # Load credentials from the session.
  credentials = google.oauth2.credentials.Credentials(
      **flask.session['credentials'])

  drive = googleapiclient.discovery.build(
      API_SERVICE_NAME, API_VERSION, credentials=credentials)

  files = drive.files().list().execute()

  # Save credentials back to session in case access token was refreshed.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.jsonify(**files)


@app.route('/authorize')
def authorize():
  # Create flow instance to manage the OAuth 2.0 Authorization Grant Flow steps.
  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES)

  # The URI created here must exactly match one of the authorized redirect URIs
  # for the OAuth 2.0 client, which you configured in the API Console. If this
  # value doesn't match an authorized URI, you will get a 'redirect_uri_mismatch'
  # error.
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  authorization_url, state = flow.authorization_url(
      # Enable offline access so that you can refresh an access token without
      # re-prompting the user for permission. Recommended for web server apps.
      access_type='offline',
      # Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes='true')

  # Store the state so the callback can verify the auth server response.
  flask.session['state'] = state

  return flask.redirect(authorization_url)


@app.route('/oauth2callback')
def oauth2callback():
  # Specify the state when creating the flow in the callback so that it can
  # verified in the authorization server response.
  state = flask.session['state']

  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES, state=state)
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  # Use the authorization server's response to fetch the OAuth 2.0 tokens.
  authorization_response = flask.request.url
  flow.fetch_token(authorization_response=authorization_response)

  # Store credentials in the session.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  credentials = flow.credentials
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.redirect(flask.url_for('test_api_request'))


@app.route('/revoke')
def revoke():
  if 'credentials' not in flask.session:
    return ('You need to <a href="/authorize">authorize</a> before ' +
            'testing the code to revoke credentials.')

  credentials = google.oauth2.credentials.Credentials(
    **flask.session['credentials'])

  revoke = requests.post('https://oauth2.googleapis.com/revoke',
      params={'token': credentials.token},
      headers = {'content-type': 'application/x-www-form-urlencoded'})

  status_code = getattr(revoke, 'status_code')
  if status_code == 200:
    return('Credentials successfully revoked.' + print_index_table())
  else:
    return('An error occurred.' + print_index_table())


@app.route('/clear')
def clear_credentials():
  if 'credentials' in flask.session:
    del flask.session['credentials']
  return ('Credentials have been cleared.<br><br>' +
          print_index_table())


def credentials_to_dict(credentials):
  return {'token': credentials.token,
          'refresh_token': credentials.refresh_token,
          'token_uri': credentials.token_uri,
          'client_id': credentials.client_id,
          'client_secret': credentials.client_secret,
          'scopes': credentials.scopes}

def print_index_table():
  return ('<table>' +
          '<tr><td><a href="/test">Test an API request</a></td>' +
          '<td>Submit an API request and see a formatted JSON response. ' +
          '    Go through the authorization flow if there are no stored ' +
          '    credentials for the user.</td></tr>' +
          '<tr><td><a href="/authorize">Test the auth flow directly</a></td>' +
          '<td>Go directly to the authorization flow. If there are stored ' +
          '    credentials, you still might not be prompted to reauthorize ' +
          '    the application.</td></tr>' +
          '<tr><td><a href="/revoke">Revoke current credentials</a></td>' +
          '<td>Revoke the access token associated with the current user ' +
          '    session. After revoking credentials, if you go to the test ' +
          '    page, you should see an <code>invalid_grant</code> error.' +
          '</td></tr>' +
          '<tr><td><a href="/clear">Clear Flask session credentials</a></td>' +
          '<td>Clear the access token currently stored in the user session. ' +
          '    After clearing the token, if you <a href="/test">test the ' +
          '    API request</a> again, you should go back to the auth flow.' +
          '</td></tr></table>')


if __name__ == '__main__':
  # When running locally, disable OAuthlib's HTTPs verification.
  # ACTION ITEM for developers:
  #     When running in production *do not* leave this option enabled.
  os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1'

  # Specify a hostname and port that are set as a valid redirect URI
  # for your API project in the Google API Console.
  app.run('localhost', 8080, debug=True)

Ruby

W tym przykładzie użyto platformy Sinatra.

require 'google/apis/drive_v3'
require 'sinatra'
require 'googleauth'
require 'googleauth/stores/redis_token_store'

configure do
  enable :sessions

  set :client_id, Google::Auth::ClientId.from_file('/path/to/client_secret.json')
  set :scope, Google::Apis::DriveV3::AUTH_DRIVE_METADATA_READONLY
  set :token_store, Google::Auth::Stores::RedisTokenStore.new(redis: Redis.new)
  set :authorizer, Google::Auth::WebUserAuthorizer.new(settings.client_id, settings.scope, settings.token_store, '/oauth2callback')
end

get '/' do
  user_id = settings.client_id.id
  credentials = settings.authorizer.get_credentials(user_id, request)
  if credentials.nil?
    redirect settings.authorizer.get_authorization_url(login_hint: user_id, request: request)
  end
  drive = Google::Apis::DriveV3::DriveService.new
  files = drive.list_files(options: { authorization: credentials })
  "<pre>#{JSON.pretty_generate(files.to_h)}</pre>"
end

get '/oauth2callback' do
  target_url = Google::Auth::WebUserAuthorizer.handle_auth_callback_deferred(request)
  redirect target_url
end

Node.js

Aby uruchomić ten przykład:

  1. W pliku API Consoledodaj adres URL tagu na komputerze lokalnym na listę przekierowań. Na przykład dodaj http://localhost
  2. Sprawdź, czy masz kanał LTS do konserwacji, aktywny kanał LTS lub aktualną wersję Zainstalowano Node.js.
  3. Utwórz nowy katalog i przejdź do niego. Na przykład: 
    mkdir ~/nodejs-oauth2-example
cd ~/nodejs-oauth2-example
  4. Install the Google API Client Library for Node.js using npm: 
    npm install googleapis
  5. Utwórz pliki main.js z poniższą zawartością.
  6. Uruchom przykład: 
    node .\main.js

main.js

const http = require('http');
const https = require('https');
const url = require('url');
const { google } = require('googleapis');
const crypto = require('crypto');
const express = require('express');
const session = require('express-session');

/**
 * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI.
 * To get these credentials for your application, visit
 * https://console.cloud.google.com/apis/credentials.
 */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Drive activity.
const scopes = [
  'https://www.googleapis.com/auth/drive.metadata.readonly'
];
/* Global variable that stores user credential in this code example.
 * ACTION ITEM for developers:
 *   Store user's refresh token in your data store if
 *   incorporating this code into your real app.
 *   For more information on handling refresh tokens,
 *   see https://github.com/googleapis/google-api-nodejs-client#handling-refresh-tokens
 */
let userCredential = null;

async function main() {
  const app = express();

  app.use(session({
    secret: 'your_secure_secret_key', // Replace with a strong secret
    resave: false,
    saveUninitialized: false,
  }));

  // Example on redirecting user to Google's OAuth 2.0 server.
  app.get('/', async (req, res) => {
    // Generate a secure random state value.
    const state = crypto.randomBytes(32).toString('hex');
    // Store state in the session
    req.session.state = state;

    // Generate a url that asks permissions for the Drive activity scope
    const authorizationUrl = oauth2Client.generateAuthUrl({
      // 'online' (default) or 'offline' (gets refresh_token)
      access_type: 'offline',
      /** Pass in the scopes array defined above.
        * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
      scope: scopes,
      // Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes: true,
      // Include the state parameter to reduce the risk of CSRF attacks.
      state: state
    });

    res.redirect(authorizationUrl);
  });

  // Receive the callback from Google's OAuth 2.0 server.
  app.get('/oauth2callback', async (req, res) => {
    // Handle the OAuth 2.0 server response
    let q = url.parse(req.url, true).query;

    if (q.error) { // An error response e.g. error=access_denied
      console.log('Error:' + q.error);
    } else if (q.state !== req.session.state) { //check state value
      console.log('State mismatch. Possible CSRF attack');
      res.end('State mismatch. Possible CSRF attack');
    } else { // Get access and refresh tokens (if access_type is offline)
      let { tokens } = await oauth2Client.getToken(q.code);
      oauth2Client.setCredentials(tokens);

      /** Save credential to the global variable in case access token was refreshed.
        * ACTION ITEM: In a production app, you likely want to save the refresh token
        *              in a secure persistent database instead. */
      userCredential = tokens;

      // Example of using Google Drive API to list filenames in user's Drive.
      const drive = google.drive('v3');
      drive.files.list({
        auth: oauth2Client,
        pageSize: 10,
        fields: 'nextPageToken, files(id, name)',
      }, (err1, res1) => {
        if (err1) return console.log('The API returned an error: ' + err1);
        const files = res1.data.files;
        if (files.length) {
          console.log('Files:');
          files.map((file) => {
            console.log(`${file.name} (${file.id})`);
          });
        } else {
          console.log('No files found.');
        }
      });
    }
  });

  // Example on revoking a token
  app.get('/revoke', async (req, res) => {
    // Build the string for the POST request
    let postData = "token=" + userCredential.access_token;

    // Options for POST request to Google's OAuth 2.0 server to revoke a token
    let postOptions = {
      host: 'oauth2.googleapis.com',
      port: '443',
      path: '/revoke',
      method: 'POST',
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Content-Length': Buffer.byteLength(postData)
      }
    };

    // Set up the request
    const postReq = https.request(postOptions, function (res) {
      res.setEncoding('utf8');
      res.on('data', d => {
        console.log('Response: ' + d);
      });
    });

    postReq.on('error', error => {
      console.log(error)
    });

    // Post the request with data
    postReq.write(postData);
    postReq.end();
  });


  const server = http.createServer(app);
  server.listen(80);
}
main().catch(console.error);

HTTP/REST

W tym przykładzie w Pythonie użyto platformy Flask. i bibliotekę Requests (Żądania), aby zademonstrować protokół OAuth 2.0 – przepływ w internecie. W tym procesie zalecamy korzystanie z biblioteki klienta interfejsu API Google dla Pythona. (Parametr na karcie Python korzysta z biblioteki klienta).

import json

import flask
import requests


app = flask.Flask(__name__)

CLIENT_ID = '123456789.apps.googleusercontent.com'
CLIENT_SECRET = 'abc123'  # Read from a file or environmental variable in a real app
SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly'
REDIRECT_URI = 'http://example.com/oauth2callback'


@app.route('/')
def index():
  if 'credentials' not in flask.session:
    return flask.redirect(flask.url_for('oauth2callback'))
  credentials = json.loads(flask.session['credentials'])
  if credentials['expires_in'] <= 0:
    return flask.redirect(flask.url_for('oauth2callback'))
  else:
    headers = {'Authorization': 'Bearer {}'.format(credentials['access_token'])}
    req_uri = 'https://www.googleapis.com/drive/v2/files'
    r = requests.get(req_uri, headers=headers)
    return r.text


@app.route('/oauth2callback')
def oauth2callback():
  if 'code' not in flask.request.args:
    state = str(uuid.uuid4())
    flask.session['state'] = state
    auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code'
                '&client_id={}&redirect_uri={}&scope={}&state={}').format(CLIENT_ID, REDIRECT_URI,
                                                                          SCOPE, state)
    return flask.redirect(auth_uri)
  else:
    if 'state' not in flask.request.args or flask.request.args['state'] != flask.session['state']:
      return 'State mismatch. Possible CSRF attack.', 400

    auth_code = flask.request.args.get('code')
    data = {'code': auth_code,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET,
            'redirect_uri': REDIRECT_URI,
            'grant_type': 'authorization_code'}
    r = requests.post('https://oauth2.googleapis.com/token', data=data)
    flask.session['credentials'] = r.text
    return flask.redirect(flask.url_for('index'))


if __name__ == '__main__':
  import uuid
  app.secret_key = str(uuid.uuid4())
  app.debug = False
  app.run()

Reguły weryfikacji identyfikatora URI przekierowania

Google stosuje te reguły weryfikacji do przekierowania identyfikatorów URI, aby ułatwić deweloperom aby chronić swoje aplikacje. Identyfikatory URI przekierowania muszą być zgodne z tymi regułami. Zobacz RFC 3986 (sekcja 3) dla definicja domeny, hosta, ścieżki, zapytania, schematu i informacji o użytkowniku wymienionych poniżej.

Reguły weryfikacji
Schemat

Identyfikatory URI przekierowania muszą korzystać ze schematu HTTPS, a nie zwykłego protokołu HTTP. Identyfikatory URI hostów lokalnych (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 najwyższego poziomu hosta (Domeny najwyższego poziomu) musi należeć do listy domen publicznych.
  • Domeny hosta nie mogą być “googleusercontent.com”.
  • Identyfikatory URI przekierowania nie mogą zawierać domen skracających adresy URL (np. goo.gl), chyba że jest właścicielem domeny. Ponadto, jeśli aplikacja należąca do domeny skracającej do tej domeny, ten identyfikator URI przekierowania musi zawierać “/google-callback/” na swojej ścieżce lub na końcu “/google-callback”
    		•
    Informacje o użytkowniku

    Identyfikatory URI przekierowania nie mogą zawierać podkomponentu informacji o użytkowniku.
    Ścieżka

    Identyfikatory URI przekierowania nie mogą zawierać przemierzania ścieżki (nazywanej też śledzeniem wstecznym katalogu) co jest reprezentowane przez atrybut “/..” lub “\..” albo jego adres URL kodowanie.
    Zapytanie

    Identyfikatory URI przekierowania nie mogą zawierać otwartych przekierowań.
    Fragment

    Identyfikatory URI przekierowania nie mogą zawierać komponentu fragmentu.
    Znaki Identyfikatory URI przekierowań nie mogą 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.

    Aby wdrożyć autoryzację przyrostową, musisz wykonać zwykłą procedurę wysyłania prośby o dostęp , ale upewnij się, że żądanie autoryzacji zawiera zakresy przyznane wcześniej. Ten pozwala aplikacji uniknąć konieczności zarządzania wieloma tokenami dostępu.

    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.
    .

    Przykładowe fragmenty kodu w konkretnych językach z sekcji Krok 1. Ustaw autoryzację i przykładowy adres URL przekierowania HTTP/REST w kroku 2: Przekieruj na serwer Google OAuth 2.0 wszystkie używają autoryzacji przyrostowej. Przykładowy kod poniżej znajdują się również kod, który należy dodać, aby użyć autoryzacji przyrostowej.

    PHP

    $client->setIncludeGrantedScopes(true);

    Python

    W Pythonie ustaw argument słowa kluczowego include_granted_scopes na true na sprawdź, czy żądanie autoryzacji obejmuje wcześniej przyznane zakresy. Jest bardzo możliwe, że include_granted_scopes nie będzie tylko ustawionym argumentem słowa kluczowego, ponieważ w poniższym przykładzie.

    authorization_url, state = flow.authorization_url(
    # Enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true')

    Ruby

    auth_client.update!(
  :additional_parameters => {"include_granted_scopes" => "true"}
)

    Node.js

    const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as a best practice.
  include_granted_scopes: true
});

    HTTP/REST

    GET https://accounts.google.com/o/oauth2/v2/auth?
  client_id=your_client_id&
  response_type=code&
  state=state_parameter_passthrough_value&
  scope=https%3A//www.googleapis.com/auth/drive.file&
  redirect_uri=https%3A//oauth2.example.com/code&
  prompt=consent&
  include_granted_scopes=true

    Odświeżanie tokena dostępu (dostęp offline)

    Tokeny dostępu okresowo tracą ważność i stają się nieprawidłowymi danymi logowania dla powiązanego żądania do interfejsu API. Ty może odświeżać token dostępu bez pytania użytkownika o zgodę (także wtedy, gdy nie występuje), jeśli została wysłana prośba o dostęp offline do zakresów powiązanych z tokenem.

    • Jeśli używasz biblioteki klienta interfejsu API Google, obiekt klienta zostanie odświeżony. token dostępu, o ile skonfigurowano do niego dostęp offline.
    • Jeśli nie korzystasz z biblioteki klienta, musisz ustawić żądanie HTTP access_type na adres offline podczas przekierowania użytkownika do strony serwer Google OAuth 2.0. W takim przypadku serwer autoryzacji Google zwraca błąd odśwież token po wymianie autoryzacji dla tokena dostępu. Następnie, jeśli token dostępu wygaśnie (lub w innym momencie), może użyć tokena odświeżania, aby uzyskać nowy token dostępu.

    Żądanie dostępu offline jest wymagane w przypadku każdej aplikacji, która potrzebuje dostępu do Interfejs API, gdy nie ma użytkownika. Na przykład aplikacja oferująca usługi tworzenia kopii zapasowych wykonując działania w ustalonym czasie, musi mieć możliwość odświeżenia swojego tokena dostępu, gdy brak użytkownika. Domyślny styl dostępu to online.

    Aplikacje internetowe po stronie serwera, zainstalowane aplikacje i urządzenia otrzymują tokeny odświeżania podczas procesu autoryzacji. Tokeny odświeżania nie są zwykle używane po stronie klienta (JavaScript).

    PHP

    Jeśli Twoja aplikacja wymaga dostępu offline do interfejsu API Google, ustaw typ dostępu klienta interfejsu API na offline:

    $client->setAccessType("offline");

    Gdy użytkownik przyzna dostęp offline do żądanych zakresów, możesz nadal korzystać z interfejsu API dostęp do interfejsów API Google w imieniu użytkownika, gdy jest on offline. Obiekt klienta w razie potrzeby odświeża token dostępu.

    Python

    W Pythonie ustaw argument słowa kluczowego access_type na offline, aby mieć pewność, aby móc odświeżyć token dostępu bez konieczności ponownego pytania użytkownika uprawnienia. Bardzo możliwe, że access_type nie będzie jedynym słowem kluczowym zgodnie z poniższym przykładem.

    authorization_url, state = flow.authorization_url(
    # Enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true')

    Gdy użytkownik przyzna dostęp offline do żądanych zakresów, możesz nadal korzystać z interfejsu API dostęp do interfejsów API Google w imieniu użytkownika, gdy jest on offline. Obiekt klienta w razie potrzeby odświeża token dostępu.

    Ruby

    Jeśli Twoja aplikacja wymaga dostępu offline do interfejsu API Google, ustaw typ dostępu klienta interfejsu API na offline:

    auth_client.update!(
  :additional_parameters => {"access_type" => "offline"}
)

    Gdy użytkownik przyzna dostęp offline do żądanych zakresów, możesz nadal korzystać z interfejsu API dostęp do interfejsów API Google w imieniu użytkownika, gdy jest on offline. Obiekt klienta w razie potrzeby odświeża token dostępu.

    Node.js

    Jeśli Twoja aplikacja wymaga dostępu offline do interfejsu API Google, ustaw typ dostępu klienta interfejsu API na offline:

    const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as a best practice.
  include_granted_scopes: true
});

    Gdy użytkownik przyzna dostęp offline do żądanych zakresów, możesz nadal korzystać z interfejsu API dostęp do interfejsów API Google w imieniu użytkownika, gdy jest on offline. Obiekt klienta w razie potrzeby odświeża token dostępu.

    Tokeny dostępu wygasają. Ta biblioteka będzie automatycznie używać tokena odświeżania, aby uzyskać nowy dostęp token wygaśnie. Prosty sposób, aby mieć pewność, że zawsze przechowujesz najnowsze tokeny jest użycie zdarzenia tokenów:

    oauth2Client.on('tokens', (tokens) => {
  if (tokens.refresh_token) {
    // store the refresh_token in your secure persistent database
    console.log(tokens.refresh_token);
  }
  console.log(tokens.access_token);
});

    To zdarzenie tokenów występuje tylko podczas pierwszej autoryzacji i musisz skonfigurować Z access_type do offline podczas wywoływania generateAuthUrl , aby otrzymać token odświeżania. Jeśli aplikacja ma już wymagane uprawnienia bez ustawiania odpowiednich ograniczeń dotyczących otrzymywania tokena odświeżania, musisz ponownie autoryzuj aplikację do otrzymywania nowego tokena odświeżania.

    Aby ustawić refresh_token później, możesz użyć metody setCredentials: 

    oauth2Client.setCredentials({
  refresh_token: `STORED_REFRESH_TOKEN`
});

    Gdy klient uzyska token odświeżania, tokeny dostępu będą pobierane i odświeżane automatycznie przy następnym wywołaniu interfejsu API.

    HTTP/REST

    Aby odświeżyć token dostępu, aplikacja wysyła żądanie POST HTTPS do serwera autoryzacji Google (https://oauth2.googleapis.com/token), który zawiera następujące parametry:

    Pola
    client_id Identyfikator klienta uzyskany z API Console.
    client_secret Tajny klucz klienta uzyskany z API Console.
    grant_type Jako zdefiniowane w specyfikacja protokołu OAuth 2.0, wartość tego pola musi być ustawiona na refresh_token.
    refresh_token Token odświeżania zwrócony z wymiany kodów autoryzacji.

    Oto przykładowy fragment kodu:

    POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

    Dopóki użytkownik nie unieważni dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON zawierający nowy token dostępu. Fragment kodu poniżej zawiera odpowiedź:

    {
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

    Pamiętaj, że liczba przyznanych tokenów odświeżania jest ograniczona. jeden limit na kombinacja klient/użytkownik oraz inna kombinacja na użytkownika w przypadku wszystkich klientów. Należy zapisać tokeny odświeżania do przechowywania długoterminowego i używać ich, dopóki są ważne. Jeśli Twoja aplikacja żąda zbyt wielu tokenów odświeżania, mogą wystąpić te limity. W takim przypadku starsze tokeny odświeżania przestanie działać.

    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.

    PHP

    Aby automatycznie unieważnić token, wywołaj revokeToken():

    $client->revokeToken();

    Python

    Aby automatycznie unieważnić token, wyślij żądanie do https://oauth2.googleapis.com/revoke, który zawiera token jako parametr i ustawia Nagłówek Content-Type:

    requests.post('https://oauth2.googleapis.com/revoke',
    params={'token': credentials.token},
    headers = {'content-type': 'application/x-www-form-urlencoded'})

    Ruby

    Aby automatycznie unieważnić token, wyślij żądanie HTTP do oauth2.revoke punkt końcowy:

    uri = URI('https://oauth2.googleapis.com/revoke')
response = Net::HTTP.post_form(uri, 'token' => auth_client.access_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 odpowiedzi będzie miał postać 200 W przypadku błędu zwracany jest kod stanu 400 wraz z .

    Node.js

    Aby automatycznie unieważnić token, wyślij żądanie HTTPS POST do /revoke punkt końcowy:

    const https = require('https');

// Build the string for the POST request
let postData = "token=" + userCredential.access_token;

// Options for POST request to Google's OAuth 2.0 server to revoke a token
let postOptions = {
  host: 'oauth2.googleapis.com',
  port: '443',
  path: '/revoke',
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
    'Content-Length': Buffer.byteLength(postData)
  }
};

// Set up the request
const postReq = https.request(postOptions, function (res) {
  res.setEncoding('utf8');
  res.on('data', d => {
    console.log('Response: ' + d);
  });
});

postReq.on('error', error => {
  console.log(error)
});

// Post the request with data
postReq.write(postData);
postReq.end();

    Parametrem tokena 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 odpowiedzi będzie miał postać 200 W przypadku błędu zwracany jest kod stanu 400 wraz z .

    HTTP/REST

    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.

    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ń.