Z tego dokumentu dowiesz się, jak zaimplementować autoryzację OAuth 2.0, aby uzyskać dostęp do interfejsów API Google za pomocą aplikacji działających na urządzeniach takich jak telewizory, konsole do gier czy drukarki. Proces ten jest przeznaczony do urządzeń, które nie mają dostępu do przeglądarki lub mają ograniczone możliwości wprowadzania danych.
OAuth 2.0 umożliwia użytkownikom udostępnianie określonych danych aplikacji przy jednoczesnym zachowaniu poufności nazw, haseł i innych informacji. Na przykład aplikacja na telewizor może używać OAuth 2.0, aby uzyskać uprawnienia do wybrania pliku zapisanego na Dysku Google.
Aplikacje korzystające z tego procesu są rozpowszechniane na poszczególne urządzenia, dlatego zakłada się, że nie mogą one trzymać tajemnic. Mogą one uzyskiwać dostęp do interfejsów API Google, gdy użytkownik korzysta z aplikacji lub gdy aplikacja działa w tle.
Alternatywy
Jeśli piszesz aplikację na platformę, np. Android, iOS, macOS, Linux lub Windows (w tym Universal Windows Platform), która ma dostęp do przeglądarki i pełne możliwości wprowadzania danych, użyj przepływu OAuth 2.0 w przypadku aplikacji mobilnych i komputera. (powinieneś użyć tego procesu nawet wtedy, gdy Twoja aplikacja jest narzędziem wiersza poleceń bez interfejsu graficznego).
Jeśli tylko chcesz, aby użytkownicy logowali się na swoje konta Google i używali tokena identyfikującego JWT, aby uzyskać podstawowe informacje z profilu użytkownika, zapoznaj się z artykułem Logowanie na telewizorach i urządzeniach z ograniczonymi możliwościami wprowadzania danych.
Wymagania wstępne
Włączanie interfejsów API w projekcie
Każda aplikacja, która wywołuje interfejsy API Google, musi włączyć te interfejsy w .
Aby włączyć interfejs API w projekcie:
- w .
- Wyświetla wszystkie dostępne interfejsy API pogrupowane według rodziny produktów i popularności. Jeśli interfejs API, który chcesz włączyć, nie jest widoczny na liście, wyszukaj go lub kliknij Wyświetl wszystkie w grupie produktów, do której należy.
- Wybierz interfejs API, który chcesz włączyć, a następnie kliknij przycisk Włącz.
Tworzenie danych uwierzytelniających
Każda aplikacja, która używa OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google, musi mieć poświadczenia autoryzacyjne, które identyfikują ją na serwerze OAuth 2.0 Google. Z tych instrukcji dowiesz się, jak utworzyć poświadczenia tożsamości do projektu. Twoje aplikacje mogą wtedy używać tych danych logowania do uzyskiwania dostępu do interfejsów API, które zostały włączone w danym projekcie.
- Kliknij Utwórz klienta.
- Wybierz typ aplikacji Telewizory i urządzenia z ograniczoną możliwością wpisywania.
- Podaj nazwę klienta OAuth 2.0 i kliknij Utwórz.
Określanie zakresów dostępu
Zakresy umożliwiają aplikacji żądanie dostępu tylko do tych zasobów, których potrzebuje, a także kontrolowanie zakresu dostępu przyznawanego aplikacji przez użytkowników. Dlatego może istnieć odwrotna zależność między liczbą żądanych zakresów uprawnień a prawdopodobieństwom uzyskania zgody użytkownika.
Zanim zaczniesz wdrażać autoryzację OAuth 2.0, zalecamy określenie zakresów, do których aplikacja będzie potrzebować uprawnień dostępu.
Sprawdź listę Dozwolone zakresy dla zainstalowanych aplikacji lub urządzeń.
Pobieranie tokenów dostępu OAuth 2.0
Chociaż aplikacja działa na urządzeniu z ograniczonymi możliwościami wprowadzania danych, użytkownicy muszą mieć osobny dostęp do urządzenia z bardziej rozbudowanymi możliwościami wprowadzania danych, aby ukończyć proces autoryzacji. Proces składa się z tych kroków:
- Aplikacja wysyła żądanie do serwera autoryzacji Google, który identyfikuje zakresy. Aplikacja poprosi o dostęp do tych zakresów.
- Serwer odpowiada, przekazując kilka informacji, które są używane w kolejnych krokach, takich jak kod urządzenia i kod użytkownika.
- Wyświetlasz informacje, które użytkownik może wpisać na osobnym urządzeniu, aby autoryzować aplikację.
- Aplikacja zaczyna wysyłać zapytania do serwera autoryzacji Google, aby ustalić, czy użytkownik autoryzował aplikację.
- Użytkownik przełącza się na urządzenie z bogatszymi możliwościami wprowadzania danych, uruchamia przeglądarkę, przechodzi do adresu URL wyświetlonego w kroku 3 i wpisuje kod, który również wyświetla się w kroku 3. Użytkownik może wtedy przyznać (lub odmówić) dostęp do aplikacji.
- Następna odpowiedź na żądanie sondowania zawiera tokeny, których aplikacja potrzebuje do autoryzacji żądań w imieniu użytkownika. Jeśli użytkownik odmówił dostępu do aplikacji, odpowiedź nie będzie zawierać tokenów.
Proces ten obrazuje obraz poniżej:
W następnych sekcjach znajdziesz szczegółowe instrukcje. Ze względu na zakres możliwości i środowiska wykonań, z których mogą korzystać urządzenia, przykłady w tym dokumencie korzystają z utility wiersza poleceń curl. Te przykłady powinny być łatwe do przeportowania na różne języki i platformy.
Krok 1. Poproś o kody urządzenia i użytkownika
Na tym etapie urządzenie wysyła żądanie HTTP POST do serwera autoryzacji Google (https://oauth2.googleapis.com/device/code), które identyfikuje Twoją aplikację oraz zakresy dostępu, do których aplikacja chce uzyskać dostęp w imieniu użytkownika.
Ten adres URL należy pobrać z dokumentu z danymi, korzystając z wartości metadanych device_authorization_endpoint. Uwzględnij te parametry żądania HTTP:
| Parametry | |
|---|---|
client_id |
Wymagany
Identyfikator klienta Twojej aplikacji. Znajdziesz ją w sekcji : . |
scope |
Wymagany
Oddzielona spacjami lista zakresów, które identyfikują zasoby, do których aplikacja może uzyskać dostęp w imieniu użytkownika. Te wartości informują o ekranie zgody, który Google wyświetla użytkownikowi. Sprawdź listę Dozwolone zakresy dla zainstalowanych aplikacji lub urządzeń. Zakresy umożliwiają aplikacji żądanie dostępu tylko do tych zasobów, których potrzebuje, a także kontrolowanie przez użytkowników zakresu dostępu przyznawanego aplikacji. Dlatego istnieje odwrotna zależność między liczbą żądanych zakresów uprawnień a prawdopodobieństwom uzyskania zgody użytkownika. |
Przykłady
Ten fragment kodu pokazuje przykładowe żądanie:
POST /device/code HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id&scope=email%20profile
Ten przykład pokazuje polecenie curl, które wysyła to samo żądanie:
curl -d "client_id=client_id&scope=email%20profile" \
https://oauth2.googleapis.com/device/code
Krok 2. Przetwórz odpowiedź serwera uwierzytelniania
Serwer autoryzacji zwróci jedną z tych odpowiedzi:
Odpowiedź na powodzenie
Jeśli żądanie jest prawidłowe, odpowiedź będzie obiektem JSON zawierającym te właściwości:
| Właściwości | |
|---|---|
device_code |
Wartość, którą Google przypisuje w celu identyfikacji urządzenia, na którym działa aplikacja prosząca o autoryzację. Użytkownik będzie autoryzować to urządzenie z innego urządzenia, które ma bardziej zaawansowane funkcje wprowadzania danych. Użytkownik może na przykład za pomocą laptopa lub telefonu zatwierdzić aplikację działającą na telewizorze. W tym przypadku device_code identyfikuje telewizor.
Ten kod umożliwia urządzeniu z aplikacją bezpieczne określenie, czy użytkownik zezwolił na dostęp, czy też odmówił. |
expires_in |
Czas (w sekundach) ważności wartości device_code i user_code. Jeśli w tym czasie użytkownik nie ukończy procesu autoryzacji, a Twoje urządzenie nie odbierz informacji o jego decyzji, może być konieczne ponowne uruchomienie tego procesu od kroku 1. |
interval |
Czas (w sekundach) oczekiwania urządzenia między kolejnymi żądaniami sprawdzania. Jeśli na przykład wartość wynosi 5, urządzenie powinno wysyłać żądanie sprawdzania do serwera autoryzacji Google co 5 sekund. Więcej informacji znajdziesz w kroku 3. |
user_code |
Wartość rozróżniająca wielkość liter, która identyfikuje w Google zakresy, do których aplikacja prosi o dostęp. Interfejs użytkownika będzie zawierać instrukcje dotyczące wpisywania tej wartości na osobnym urządzeniu z bogatszymi funkcjami wprowadzania danych. Następnie Google używa tej wartości, aby wyświetlić użytkownikowi odpowiedni zestaw zakresów dostępu, gdy poprosi go o przyznanie dostępu do aplikacji. |
verification_url |
Adres URL, do którego użytkownik musi przejść na osobnym urządzeniu, aby wprowadzić user_code i przyznać lub odmówić przyznania dostępu do aplikacji. Ta wartość będzie też widoczna w interfejsie. |
Ten fragment kodu pokazuje przykładową odpowiedź:
{ "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", "user_code": "GQVQ-JKEC", "verification_url": "https://www.google.com/device", "expires_in": 1800, "interval": 5 }
Odpowiedź na przekroczenie limitu
Jeśli żądania kodu urządzenia przekroczą limit związany z identyfikatorem klienta, otrzymasz odpowiedź 403 z tym błędem:
{ "error_code": "rate_limit_exceeded" }
W takim przypadku użyj strategii wycofywania się, aby zmniejszyć częstotliwość żądań.
Krok 3. Wyświetl kod użytkownika
Wyświetl użytkownikowi wartości verification_url i user_code uzyskane w kroku 2. Obie wartości mogą zawierać dowolny znak z zestawu znaków US-ASCII. Treści wyświetlane użytkownikowi powinny zawierać instrukcje przejścia do strony verification_url na osobnym urządzeniu i wpisania kodu user_code.
Podczas projektowania interfejsu pamiętaj o tych zasadach:
user_code- Wartość
user_codemusi być wyświetlana w polu, które może pomieścić 15 znaków o rozmiarze „W”. Innymi słowy, jeśli możesz wyświetlić kodWWWWWWWWWWWWWWWprawidłowo, interfejs jest prawidłowy. Zalecamy używanie tej wartości ciągu znaków podczas testowania sposobu wyświetlania wartościuser_codew interfejsie. - Wielkość liter w identyfikatorze
user_codema znaczenie i nie należy go w żaden sposób modyfikować, np. przez zmianę wielkości liter lub wstawianie innych znaków formatowania.
- Wartość
verification_url- Miejsce, w którym wyświetlasz element
verification_url, musi być wystarczająco szerokie, aby pomieścić ciąg znaków adresu URL o długości 40 znaków. - Nie należy modyfikować elementu
verification_urlw żaden sposób, z wyjątkiem opcjonalnego usunięcia schematu wyświetlania. Jeśli z powodu wyświetlania chcesz usunąć schemat (np.https://) z adresu URL, upewnij się, że Twoja aplikacja może obsługiwać wariantyhttpihttps.
- Miejsce, w którym wyświetlasz element
Krok 4. Odpytuj serwer autoryzacji Google
Użytkownik będzie używać osobnego urządzenia, aby przejść do verification_url i przyznać (lub odmówić przyznania) dostępu, więc urządzenie wysyłające żądanie nie zostanie automatycznie powiadomione, gdy użytkownik odpowie na prośbę o dostęp. Dlatego urządzenie wysyłające żądanie musi odpytywać serwer autoryzacji Google, aby określić, kiedy użytkownik odpowiedział na żądanie.
Urządzenie wysyłające żądanie powinno nadal wysyłać żądania sondowania, dopóki nie otrzyma odpowiedzi
wskazującej, że użytkownik odpowiedział na prośbę o dostęp, lub dopóki nie wygasną device_code
i user_code uzyskane w
kroku 2. Wartość interval zwracana w kroku 2 określa czas (w sekundach) oczekiwania między żądaniami.
Adres URL punktu końcowego do zapytania to https://oauth2.googleapis.com/token. Żądanie sondowania zawiera te parametry:
| Parametry | |
|---|---|
client_id |
Identyfikator klienta Twojej aplikacji. Znajdziesz ją w sekcji : . |
client_secret |
Tajny klucz klienta dla podanego client_id. Znajdziesz ją w sekcji : . |
device_code |
device_code zwrócony przez serwer autoryzacji w kroku 2. |
grant_type |
Ustaw ją na urn:ietf:params:oauth:grant-type:device_code. |
Przykłady
Ten fragment kodu pokazuje przykładowe żądanie:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id& client_secret=client_secret& device_code=device_code& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
Ten przykład pokazuje polecenie curl, które wysyła to samo żądanie:
curl -d "client_id=client_id&client_secret=client_secret& \
device_code=device_code& \
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
-H "Content-Type: application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/tokenKrok 5. Użytkownik odpowiada na prośbę o dostęp
Na poniższym obrazku widać stronę podobną do tej, którą użytkownicy widzą po przejściu do strony verification_url wyświetlonej w kroku 3:
Po wpisaniu user_code i zalogowaniu się w Google (jeśli nie jest jeszcze zalogowany) użytkownik zobaczy ekran zgody podobny do tego:
Krok 6. Przetwarzaj odpowiedzi na żądania głosowania
Serwer autoryzacji Google odpowiada na każde żądanie sondowania jedną z tych odpowiedzi:
Dostęp przyznany
Jeśli użytkownik przyznał dostęp do urządzenia (klikając Allow na ekranie zgody), odpowiedź zawiera token dostępu i token odświeżania. Tokeny umożliwiają urządzeniu dostęp do interfejsów Google API w imieniu użytkownika. (Właściwość scope w odpowiedzi określa, do których interfejsów API ma dostęp dane urządzenie).
W takim przypadku odpowiedź interfejsu API zawiera te pola:
| Pola | |
|---|---|
access_token |
Token wysyłany przez aplikację w celu autoryzacji żądania interfejsu Google API. |
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 czasu, gdy użytkownik cofnie dostęp lub token odświeżania wygaśnie. Pamiętaj, że tokeny odświeżania są zawsze zwracane w przypadku urządzeń. |
refresh_token_expires_in |
Pozostały czas ważności tokena odświeżania w sekundach. Ta wartość jest ustawiana tylko wtedy, gdy użytkownik przyzna dostęp czasowy. |
scope |
Zakresy dostępu przyznane przez access_token wyrażone jako lista rozróżnianych wielkością liter ciągów znaków oddzielonych spacjami. |
token_type |
Typ zwróconego tokena. Obecnie wartość tego pola zawsze wynosiBearer. |
Ten fragment kodu pokazuje przykładową odpowiedź:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email", "token_type": "Bearer", "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Tokeny dostępu mają ograniczony czas ważności. Jeśli aplikacja potrzebuje dostępu do interfejsu API przez dłuższy czas, może użyć tokena odświeżania, aby uzyskać nowy token dostępu. Jeśli aplikacja potrzebuje tego typu dostępu, powinna przechowywać token odświeżania na potrzeby późniejszego użycia.
Odmowa dostępu
Jeśli użytkownik odmówi przyznania dostępu do urządzenia, odpowiedź serwera będzie zawierać kod stanu odpowiedzi HTTP403 (Forbidden). Odpowiedź zawiera ten błąd:
{ "error": "access_denied", "error_description": "Forbidden" }
Oczekiwanie na autoryzację
Jeśli użytkownik nie ukończył jeszcze procesu autoryzacji, serwer zwraca kod stanu odpowiedzi HTTP 428 (Precondition Required). Odpowiedź zawiera ten błąd:
{ "error": "authorization_pending", "error_description": "Precondition Required" }
zbyt często przeprowadzać ankiety;
Jeśli urządzenie wysyła żądania sondowania zbyt często, serwer zwraca kod stanu odpowiedzi HTTP 403 (Forbidden). Odpowiedź zawiera ten błąd:
{ "error": "slow_down", "error_description": "Forbidden" }
Inne błędy
Serwer autoryzacji zwraca też błędy, jeśli w żądaniu sondowania brakuje wymaganych parametrów lub ich wartości są nieprawidłowe. Te żądania mają zwykle kod stanu odpowiedzi HTTP 400 (Bad Request) lub 401 (Unauthorized). Do takich błędów należą:
| Błąd | Kod stanu HTTP | Opis |
|---|---|---|
admin_policy_enforced |
400 |
Konto Google nie może autoryzować co najmniej 1 wymaganego zakresu ze względu na zasady administratora Google Workspace. Więcej informacji o tym, jak administrator może ograniczyć dostęp do zakresów, dopóki nie zostanie wyraźnie przyznany dostęp do Twojego identyfikatora klienta OAuth, znajdziesz w artykule pomocy dla administratorów Google Workspace Określanie, które aplikacje innych firm i aplikacje wewnętrzne mają dostęp do danych Google Workspace. |
invalid_client |
401 |
Nie znaleziono klienta OAuth. Ten błąd występuje na przykład, gdy wartość parametru Typ klienta OAuth jest nieprawidłowy. Sprawdź, czy typ aplikacji dla identyfikatora klienta jest ustawiony na TV i urządzenia z ograniczoną możliwością wpisywania. |
invalid_grant |
400 |
Wartość parametru code jest nieprawidłowa, została już zgłoszona lub nie można jej przeanalizować. |
unsupported_grant_type |
400 |
Wartość parametru grant_type jest nieprawidłowa. |
org_internal |
403 |
Identyfikator klienta OAuth w żądaniu należy do projektu, który ogranicza dostęp do kont Google w określonej organizacji Google Cloud. Potwierdź konfigurację typu użytkownika w aplikacji OAuth. |
Wywoływanie interfejsów API Google
Gdy aplikacja uzyska token dostępu, możesz go używać do wywoływania interfejsów API Google w imieniu danego konta użytkownika, jeśli przyznano uprawnienia dostępu wymagane przez interfejs API. Aby to zrobić, dodaj token dostępu do żądania do interfejsu API, podając parametr zapytania access_token lub wartość nagłówka HTTP Authorization Bearer. Jeśli to możliwe, zalecamy użycie nagłówka HTTP, ponieważ ciągi znaków zapytania są zwykle widoczne w dziennikach serwera. W większości przypadków możesz użyć biblioteki klienta, aby skonfigurować wywołania interfejsów API Google (na przykład wywołując interfejs Drive API).
Możesz wypróbować wszystkie interfejsy API Google i wyświetlić ich zakresy na stronie OAuth 2.0 Playground.
Przykłady żądań HTTP GET
Wywołanie punktu końcowego
drive.files (interfejsu Drive Files API) za pomocą nagłówka HTTP Authorization: Bearer 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 przez uwierzytelnionego użytkownika za pomocą parametru ciągu zapytania access_token:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl przykładu
Te polecenia możesz przetestować za pomocą aplikacji wiersza poleceń curl. Oto przykład użycia opcji nagłówka HTTP (preferowana):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Możesz też użyć parametru ciągu zapytania:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Odświeżanie tokena dostępu
Tokeny dostępu okresowo wygasają i stają się nieprawidłowymi danymi logowania w przypadku powiązanego żądania interfejsu API. Jeśli poprosisz o dostęp offline do zakresów powiązanych z tokenem, możesz odświeżyć token dostępu bez wyświetlania użytkownikowi prośby o pozwolenie (także wtedy, gdy użytkownika nie ma w pobliżu).
Aby odświeżyć token dostępu, aplikacja wysyła żądanie HTTPS POST do serwera autoryzacji Google (https://oauth2.googleapis.com/token), które zawiera te parametry:
| Pola | |
|---|---|
client_id |
Identyfikator klienta uzyskany z . |
client_secret |
Tajny klucz klienta uzyskany z . |
grant_type |
Zgodnie z specyfikacją OAuth 2.0 wartość tego pola musi wynosić refresh_token. |
refresh_token |
Token odświeżania zwrócony z wymiany kodu autoryzacji. |
Ten fragment kodu pokazuje przykładowe żądanie:
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 cofnie przyznanego aplikacji dostępu, serwer tokenów zwróci obiekt JSON zawierający nowy token dostępu. Ten fragment kodu pokazuje przykładową odpowiedź:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly", "token_type": "Bearer" }
Pamiętaj, że liczba wydawanych tokenów odświeżania jest ograniczona. Jeden limit dotyczy kombinacji klient/użytkownik, a drugi – wszystkich klientów. Tokeny odświeżania należy zapisać w długoterminowym magazynie danych i nadal z nich korzystać, dopóki są ważne. Jeśli Twoja aplikacja wysyła zbyt wiele żądań tokenów odświeżania, może przekroczyć te limity. W takim przypadku starsze tokeny odświeżania przestaną działać.
Unieważnianie tokena
W niektórych przypadkach użytkownik może chcieć cofnąć dostęp aplikacji. Użytkownik może cofnąć dostęp, otwierając Ustawienia konta. Więcej informacji znajdziesz w sekcji Usuwanie dostępu strony lub aplikacji do Twojego konta w dokumentacji pomocy Strony internetowe i aplikacje innych firm z dostępem do Twojego konta.
Aplikacja może też automatycznie cofnąć przyznany dostęp. Automatyczne odwoływanie jest ważne w przypadkach, gdy użytkownik zrezygnuje z subskrypcji, usunie aplikację lub zasoby interfejsu API wymagane przez aplikację ulegną znacznym zmianom. Innymi słowy, część procesu usuwania może obejmować żądanie interfejsu API, aby usunąć uprawnienia wcześniej przyznane aplikacji.
Aby programowo unieważnić token, aplikacja wysyła żądanie do adresu https://oauth2.googleapis.com/revoke, dołączając token jako parametr:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}Token może być tokenem dostępu lub tokenem odświeżania. Jeśli token jest tokenem dostępu i ma odpowiadający mu token odświeżania, token odświeżania zostanie również cofnięty.
Jeśli odwołanie zostało przetworzone, kod stanu HTTP odpowiedzi to 200. W przypadku błędów zwracany jest kod stanu HTTP 400 oraz kod błędu.
Dozwolone zakresy
Proces OAuth 2.0 na urządzeniach jest obsługiwany tylko w przypadku tych zakresów:
OpenID Connect, logowanie w Google
emailopenidprofile
Dysku API
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
Interfejs API YouTube
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly
Dostęp zależny od czasu
Dostęp czasowy umożliwia użytkownikowi przyznanie aplikacji dostępu do jego danych na ograniczony czas, aby wykonać określone działanie. Dostęp ograniczony czasowo jest dostępny w wybranych usługach Google podczas procesu uzyskiwania zgody. Użytkownicy mogą przyznać dostęp na ograniczony czas. Przykładem jest interfejs Data Portability API, który umożliwia jednokrotny transfer danych.
Gdy użytkownik przyzna aplikacji dostęp czasowy, token odświeżania wygaśnie po określonym czasie. Pamiętaj, że w określonych okolicznościach tokeny odświeżania mogą zostać unieważnione wcześniej. Więcej informacji znajdziesz w tych przypadkach. W takich przypadkach pole refresh_token_expires_in zwrócone w odpowiedzi na żądanie exchange dotyczące kodu autoryzacji zawiera czas pozostały do wygaśnięcia tokena odświeżania.
Wdrażanie Ochrony wszystkich kont
Dodatkowym krokiem, który należy wykonać, aby chronić konta użytkowników, jest wdrożenie ochrony na wielu kontach za pomocą usługi Google do ochrony na wielu kontach. Ta usługa umożliwia subskrybowanie powiadomień o zdarzeniach związanych z bezpieczeństwem, które dostarczają aplikacji informacji o ważnych zmianach na koncie użytkownika. Następnie możesz podjąć odpowiednie działania w zależności od tego, jak chcesz reagować na zdarzenia.
Przykłady typów zdarzeń wysyłanych do Twojej aplikacji przez usługę ochrony na wielu kontach:
-
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
Więcej informacji o wdrażaniu ochrony wszystkich kont oraz pełną listę dostępnych zdarzeń znajdziesz na stronie Ochrona kont użytkowników za pomocą ochrony wszystkich kont .