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 za pomocą interfejsu YouTube Data API.
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 uzyskać uprawnienia aby pobrać dane kanału z YouTube.
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.
Interfejs YouTube Live Streaming API nie obsługuje procesu konta usługi. Ponieważ nie ma sposobu,
połączyć konto usługi z kontem YouTube, próby autoryzowania żądań w ramach tego procesu
generują błąd NoLinkedYouTubeAccount
.
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:
- Open the API Library w Google API Console
- If prompted, select a project, or create a new one.
- Znajdź i włącz interfejs YouTube Data API, korzystając ze strony Biblioteka. Znajdź i włącz wszystkie inne interfejsy API, których będzie używać Twoja aplikacja.
Tworzenie danych uwierzytelniających
Każda aplikacja korzystająca z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google musi mieć dane uwierzytelniające które identyfikują aplikację na serwerze Google OAuth 2.0. Poniżej 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.
- Go to the Credentials page.
- Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
- Jako typ aplikacji wybierz Aplikacja internetowa.
- 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 tohttp://localhost:8080
.Zalecamy zaprojektowanie punktów końcowych uwierzytelniania, aby ż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. Dzięki tej sprawdzonej metodzie użytkownicy łatwiej zrozumieją, dlaczego aplikacja potrzebuje dostępu, o który prosi.
Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:
Zakresy | |
---|---|
https://www.googleapis.com/auth/youtube | Zarządzanie kontem YouTube |
https://www.googleapis.com/auth/youtube.channel-memberships.creator | Wyświetlanie listy aktualnie aktywnych użytkowników wspierających kanał, ich obecnych poziomów i dat rozpoczęcia wsparcia |
https://www.googleapis.com/auth/youtube.force-ssl | Przeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube |
https://www.googleapis.com/auth/youtube.readonly | Wyświetlanie konta YouTube |
https://www.googleapis.com/auth/youtube.upload | Zarządzanie filmami w YouTube |
https://www.googleapis.com/auth/youtubepartner | Przeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube |
https://www.googleapis.com/auth/youtubepartner-channel-audit | Przeglądanie prywatnych danych kanału YouTube istotnych podczas rozmowy z partnerem YouTube |
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ż oraz wymagania dotyczące konkretnego języka.
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
igoogle-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:
- Aplikacja określa wymagane uprawnienia.
- Aplikacja przekierowuje użytkownika do Google wraz z listą żądanych żądań uprawnień.
- Użytkownik decyduje, czy przyznać aplikacji uprawnienia.
- Aplikacja uzyskuje informacje na temat decyzji użytkownika.
- 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
.
Aby na przykład poprosić o dostęp offline do pobrania danych użytkownika z YouTube:
$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_YouTube::YOUTUBE_FORCE_SSL); // 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
.
Aby na przykład poprosić o dostęp offline do pobrania danych użytkownika z YouTube:
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/youtube.force-ssl']) # 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.
Aby na przykład poprosić o dostęp offline do pobrania danych użytkownika z YouTube:
require 'google/apis/youtube_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/youtube.force-ssl' 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: wartość refresh_token
jest zwracana 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
autoryzowany identyfikator URI przekierowania dla podanego adresu Zwróć uwagę na schemat |
||||||||||||||||
response_type |
Wymagany
Określa, czy punkt końcowy Google OAuth 2.0 zwraca kod autoryzacji. W przypadku aplikacji serwera WWW ustaw parametr na |
||||||||||||||||
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. Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:
Dokument Zakresy interfejsu API OAuth 2.0 zawiera informacje pełną listę zakresów, których możesz używać, aby uzyskać dostęp do interfejsów API Google. Zalecamy, aby aplikacja żądała dostępu do zakresów autoryzacji w kontekście gdy tylko jest to możliwe. Prosząc o dostęp do danych użytkownika w kontekście, za pomocą: dodatkowej autoryzacji, 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 Ustaw wartość |
||||||||||||||||
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 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. |
||||||||||||||||
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 |
||||||||||||||||
enable_granular_consent |
Opcjonalny
Domyślna wartość to Gdy Google włączy szczegółowe uprawnienia aplikacji, ten parametr nie będzie nie wywierają żadnego wpływu. |
||||||||||||||||
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, aby 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 |
||||||||||||||||
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:
|
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 też wtedy, gdy aplikacja po raz pierwszy potrzebuje dostępu do dodatkowych zasobów, nie mają jeszcze uprawnień dostępu.
PHP
- Wygeneruj URL, aby poprosić o dostęp z serwera Google OAuth 2.0:
$auth_url = $client->createAuthUrl();
- 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
- 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)
- Przekieruj użytkownika na stronę
auth_uri
.
Node.js
-
Użyj adresu URL wygenerowanego
authorizationUrl
z kroku 1 MetodagenerateAuthUrl
żądania dostępu z serwera Google OAuth 2.0. -
Przekieruj użytkownika na stronę
authorizationUrl
.res.redirect(authorizationUrl);
HTTP/REST
Przykładowe przekierowanie na serwer autoryzacji Google
Przykładowy adres URL podano poniżej ze znakami podziału wiersza i spacjami, aby zapewnić czytelność. Adres URL wysyła żądania
Dostęp do zakresu, który umożliwia pobieranie danych użytkownika z YouTube. Wykorzystuje przyrostowe
(include_granted_scopes=true
), by zagwarantować, że nowy token dostępu
obejmuje wszystkie zakresy, do których użytkownik przyznał wcześniej dostęp aplikacji. Kilka innych
określone w przykładzie.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& 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 żądany dostęp. 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%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& 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/youtube.force-ssl'], 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/youtube.force-ssl", "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:
- Jeśli musisz zastosować token dostępu do nowego obiektu
Google\Client
– dla Jeśli na przykład token dostępu jest przechowywany w sesji użytkownika, użyj MetodasetAccessToken
:$client->setAccessToken($access_token);
- 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 YouTube Data API:$youtube = new Google_Service_YouTube($client);
- Wysyłaj żądania do usługi interfejsu API za pomocą
interfejsu udostępnianego przez obiekt usługi.
Aby np. skorzystać z interfejsu YouTube Data API, by pobrać listę transmisji na żywo uwierzytelnionych
kanał użytkownika:
$broadcasts = $youtube->liveBroadcasts->listLiveBroadcasts('id,snippet', [ 'mine' => true ]);
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.
- Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać. Obiekt usługi tworzysz przez
wywołania metody
build
bibliotekigoogleapiclient.discovery
z parametrem nazwę i wersję interfejsu API oraz dane logowania użytkownika: Aby na przykład wywołać wersję 3 interfejsu YouTube Data API:from googleapiclient.discovery import build youtube = build('youtube', 'v3', credentials=credentials)
- Wysyłaj żądania do usługi interfejsu API za pomocą
interfejsu udostępnianego przez obiekt usługi.
Aby np. skorzystać z interfejsu YouTube Data API, by pobrać listę transmisji na żywo uwierzytelnionych
kanał użytkownika:
broadcasts = youtube.liveBroadcasts().list(part='id,snippet', mine=True).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.
- Utwórz obiekt usługi dla interfejsu API, który chcesz wywoływać.
Aby na przykład wywołać wersję 3 interfejsu YouTube Data API:
youtube = Google::Apis::YoutubeV3::YouTubeService.new
- Ustaw dane logowania do usługi:
youtube.authorization = credentials
- Wysyłaj żądania do usługi interfejsu API za pomocą
interfejs
udostępniane przez obiekt usługi.
Aby np. skorzystać z interfejsu YouTube Data API, by pobrać listę transmisji na żywo uwierzytelnionych
kanał użytkownika:
broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true)
Autoryzację można też przeprowadzić w przypadku poszczególnych metod, podając atrybut
Parametr options
metody:
broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true)
Node.js
Po uzyskaniu tokena dostępu i ustawieniu 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 YouTube Live Streaming API).
Pamiętaj, że interfejs YouTube Live Streaming API nie obsługuje procesu konta usługi. Od tego dnia
konta usługi nie można powiązać z kontem YouTube, próbuje autoryzować żądania za pomocą tego
proces wygeneruje błąd NoLinkedYouTubeAccount
.
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
liveBroadcasts.list
(interfejs YouTube Live Streaming API) za pomocą protokołu HTTP Authorization: Bearer
nagłówek może wyglądać tak: Pamiętaj, że musisz podać własny token dostępu:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Oto wywołanie tego samego interfejsu API dla uwierzytelnionego użytkownika za pomocą interfejsu access_token
parametr ciągu zapytania:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
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/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
Możesz też użyć opcji parametru ciągu zapytania:
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Pełny przykład
Poniższy przykład umożliwia wydrukowanie obiektu w formacie JSON przedstawiającego transmisje na żywo kanału YouTube uwierzytelnionego użytkownika po autoryzacji która może je pobrać.
PHP
Aby uruchomić ten przykład:
- W pliku API Consoledodaj adres URL komputera lokalnego do pliku
listę przekierowań. Na przykład dodaj
http://localhost:8080
. - Utwórz nowy katalog i przejdź do niego. Na przykład:
mkdir ~/php-oauth2-example cd ~/php-oauth2-example
- Instalowanie klienta interfejsu API Google
Biblioteka PHP w usłudze Composer:
composer require google/apiclient:^2.10
- Utwórz pliki
index.php
ioauth2callback.php
wraz z treścią poniżej. - 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_YouTube::YOUTUBE_FORCE_SSL); if (isset($_SESSION['access_token']) && $_SESSION['access_token']) { $client->setAccessToken($_SESSION['access_token']); $youtube = new Google_Service_YouTube($client); $broadcasts = $youtube->liveBroadcasts->listLiveBroadcasts('id,snippet', [ 'mine' => true ]); echo json_encode($broadcasts); } 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_YouTube::YOUTUBE_FORCE_SSL); 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/youtube.force-ssl'] API_SERVICE_NAME = 'youtube' API_VERSION = 'v3' 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']) youtube = googleapiclient.discovery.build( API_SERVICE_NAME, API_VERSION, credentials=credentials) broadcasts = youtube.liveBroadcasts().list(part='id,snippet', mine=True).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(**broadcasts) @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/youtube_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 youtube = Google::Apis::YoutubeV3::YouTubeService.new broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true) "<pre>#{JSON.pretty_generate(broadcasts.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:
-
W pliku API Consoledodaj adres URL tagu
na komputerze lokalnym na listę przekierowań. Na przykład dodaj
http://localhost
- Sprawdź, czy masz kanał LTS do konserwacji, aktywny kanał LTS lub aktualną wersję Zainstalowano Node.js.
-
Utwórz nowy katalog i przejdź do niego. Na przykład:
mkdir ~/nodejs-oauth2-example cd ~/nodejs-oauth2-example
-
Zainstaluj
Klient interfejsów API Google
Biblioteka
w przypadku Node.js przy użyciu npm:
npm install googleapis
-
Utwórz pliki
main.js
z poniższą zawartością. -
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/youtube.force-ssl' 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://youtube.googleapis.com/youtube/v3/liveBroadcasts' 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 |
“googleusercontent.com” .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 |
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:
|
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.
Załóżmy na przykład, że aplikacja pobiera dane z kanału YouTube uwierzytelnionego użytkownika oraz
umożliwia użytkownikowi pobranie danych Statystyk YouTube za pomocą specjalnego procesu. W tym przypadku podczas logowania
aplikacja może poprosić o dostęp tylko do https://www.googleapis.com/auth/youtube.force-ssl
zakresu. Gdyby jednak użytkownik próbował uzyskać dostęp do danych Analytics dotyczących kanału, aplikacja mogła też
poproś o dostęp do zakresu https://www.googleapis.com/auth/yt-analytics.readonly
.
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
W tym przykładzie aplikacja wywołująca prosi o dostęp do pobrania danych YouTube użytkownika, oprócz wszelkich innych uprawnień dostępu, aplikacja została już udzielona.
GET https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& state=security_token%3D138rk%3Btarget_url%3Dhttp...index& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& response_type=code& client_id=client_id& include_granted_scopes=true
Refreshing an access token (offline access)
Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.
- If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
- If you are not using a client library, you need to set the
access_type
HTTP query parameter tooffline
when redirecting the user to Google's OAuth 2.0 server. In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.
Requesting offline access is a requirement for any application that needs to access a Google
API when the user is not present. For example, an app that performs backup services or
executes actions at predetermined times needs to be able to refresh its access token when the
user is not present. The default style of access is called online
.
Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.
PHP
If your application needs offline access to a Google API, set the API client's access type to
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 usłudze ochrony wszystkich kont Google. 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ń.