Ten dokument wyjaśnia, jak wdrożyć 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 i drukarki. Ten proces jest przeznaczony dla urządzeń, które nie mają dostępu do przeglądarki lub mają ograniczone możliwości wprowadzania danych.
Protokół 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 telewizyjna może używać protokołu OAuth 2.0, aby uzyskać uprawnienia do wybrania pliku przechowywanego na Dysku Google.
Aplikacje, które korzystają z tego przepływu, są rozpowszechniane na poszczególnych urządzeniach, dlatego zakłada się, że nie mogą one zachować poufności. Mogą uzyskiwać dostęp do interfejsów API Google, gdy użytkownik korzysta z aplikacji lub gdy aplikacja działa w tle.
Alternatywy
Jeśli chcesz logować użytkowników tylko za pomocą ich kont Google i używać tokena identyfikacji JWT do uzyskiwania podstawowych informacji z profilu użytkownika, zapoznaj się z artykułem Logowanie się 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 je włączyć w Konsoli interfejsów API.
Aby włączyć interfejs API w projekcie:
- Otwórz Bibliotekę interfejsów API w Konsoli interfejsów API Google.
- Jeśli pojawi się taka prośba, wybierz projekt lub utwórz nowy.
- Biblioteka interfejsów API zawiera listę wszystkich dostępnych interfejsów API pogrupowanych według rodziny usług 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 rodzinie usług, do której należy.
- Wybierz interfejs API, który chcesz włączyć, a następnie kliknij przycisk Włącz.
- Jeśli pojawi się taka prośba, włącz płatności.
- Jeśli pojawi się taka prośba, przeczytaj i zaakceptuj Warunki korzystania z interfejsu API.
Tworzenie danych uwierzytelniających
Każda aplikacja, która używa protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google, musi mieć dane uwierzytelniające, które identyfikują ją na serwerze OAuth 2.0 Google. Poniżej znajdziesz instrukcje tworzenia danych logowania do projektu. Twoje aplikacje mogą następnie używać tych danych logowania, aby uzyskiwać dostęp do interfejsów API, które zostały włączone w tym projekcie.
- Otwórz stronę Klienci.
- Kliknij Utwórz klienta.
- Wybierz typ aplikacji TV i urządzenia z ograniczoną możliwością wpisywania.
- Nazwij klienta OAuth 2.0 i kliknij Utwórz.
Identyfikowanie zakresów dostępu
Zakresy umożliwiają aplikacji żądanie dostępu tylko do tych zasobów, których potrzebuje, a użytkownikom – kontrolowanie zakresu dostępu, który przyznają aplikacji. W związku z tym może istnieć odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.
Zanim zaczniesz wdrażać autoryzację OAuth 2.0, zalecamy określenie zakresów, do których aplikacja będzie potrzebować uprawnień dostępu.
Zobacz listę Dozwolone zakresy dla aplikacji instalowanych lub urządzeń.
Uzyskiwanie tokenów dostępu OAuth 2.0
Nawet jeśli aplikacja działa na urządzeniu z ograniczonymi możliwościami wprowadzania danych, użytkownicy muszą mieć osobny dostęp do urządzenia z większymi możliwościami wprowadzania danych, aby ukończyć ten proces autoryzacji. Proces składa się z tych kroków:
- Aplikacja wysyła do serwera autoryzacji Google żądanie, które określa zakresy, do których aplikacja będzie prosić o dostęp.
- Serwer odpowiada, podając kilka informacji używanych 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 sprawdzić, czy użytkownik autoryzował aplikację.
- Użytkownik przełącza się na urządzenie z większymi możliwościami wprowadzania danych, uruchamia przeglądarkę, przechodzi na adres URL wyświetlony w kroku 3 i wpisuje kod, który również został wyświetlony w kroku 3. Użytkownik może wtedy przyznać (lub odmówić) dostęp do aplikacji.
- Następna odpowiedź na żądanie zawiera tokeny, których aplikacja potrzebuje do autoryzowania żądań w imieniu użytkownika. (Jeśli użytkownik odmówił dostępu do aplikacji, odpowiedź nie zawiera tokenów).
Ten proces przedstawia poniższy obraz:
W sekcjach poniżej znajdziesz szczegółowe informacje o tych krokach. Ze względu na zakres możliwości i środowisk wykonawczych, które mogą mieć urządzenia, w przykładach przedstawionych w tym dokumencie używamy narzędzia wiersza poleceń curl. Te przykłady można przenieść do różnych języków i środowisk wykonawczych.
Krok 1. Poproś o kody urządzenia i użytkownika
W tym kroku urządzenie wysyła żądanie HTTP POST do serwera autoryzacji Google pod adresem https://oauth2.googleapis.com/device/code, który identyfikuje 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 opisującego, używając wartości metadanych device_authorization_endpoint. Uwzględnij te parametry żądania HTTP:
| Parametry | |
|---|---|
client_id |
Wymagany
Identyfikator klienta aplikacji. Tę wartość znajdziesz na stronie Klienci w konsoli Cloud. |
scope |
Wymagany
Rozdzielona spacjami lista zakresów, które identyfikują zasoby, do których aplikacja może uzyskać dostęp w imieniu użytkownika. Te wartości są przekazywane do ekranu zgody, który Google wyświetla użytkownikowi. Zobacz listę Dozwolone zakresy dla aplikacji instalowanych lub urządzeń. Zakresy umożliwiają aplikacji żądanie dostępu tylko do tych zasobów, których potrzebuje, a użytkownikom – kontrolowanie zakresu dostępu, który przyznają aplikacji. Istnieje więc odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika. |
Przykłady
Poniższy 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 autoryzacji
Serwer autoryzacji zwróci jedną z tych odpowiedzi:
Odpowiedź o powodzeniu
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 unikalny sposób, aby zidentyfikować urządzenie, na którym działa aplikacja żądająca autoryzacji. Użytkownik autoryzuje to urządzenie z innego urządzenia o większych możliwościach wprowadzania danych. Użytkownik może na przykład użyć laptopa lub telefonu komórkowego, aby autoryzować aplikację działającą na telewizorze. W tym przypadku device_code identyfikuje telewizor.
Ten kod pozwala urządzeniu, na którym działa aplikacja, bezpiecznie określić, czy użytkownik przyznał lub odmówił dostępu. |
expires_in |
Czas (w sekundach), przez który device_code i user_code są ważne. Jeśli w tym czasie użytkownik nie ukończy procesu autoryzacji, a urządzenie nie wyśle zapytania o informacje o decyzji użytkownika, może być konieczne ponowne rozpoczęcie tego procesu od kroku 1. |
interval |
Czas (w sekundach), przez jaki urządzenie powinno czekać między żądaniami odpytywania. Jeśli na przykład wartość wynosi 5, urządzenie powinno wysyłać żądanie do serwera autoryzacji Google co 5 sekund. Więcej informacji znajdziesz w kroku 3. |
user_code |
Wartość z uwzględnieniem wielkości liter, która identyfikuje zakresy, do których aplikacja prosi o dostęp. Interfejs użytkownika poinstruuje użytkownika, aby wpisał tę wartość na osobnym urządzeniu z bardziej rozbudowanymi możliwościami wprowadzania danych. Google używa tej wartości do wyświetlania prawidłowego zestawu zakresów, gdy prosi użytkownika o przyznanie dostępu do aplikacji. |
verification_url |
Adres URL, który użytkownik musi otworzyć na osobnym urządzeniu, aby wpisać user_code i przyznać lub odmówić dostępu do aplikacji. Ta wartość będzie też wyświetlana w interfejsie użytkownika. |
Poniższy 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ź o przekroczeniu limitu
Jeśli żądania kodu urządzenia przekroczą limit powiązany z identyfikatorem klienta, otrzymasz odpowiedź 403 z tym błędem:
{ "error_code": "rate_limit_exceeded" }
W takim przypadku użyj strategii wycofywania, aby zmniejszyć częstotliwość żądań.
Krok 3. Wyświetl kod użytkownika
Wyświetl użytkownikowi verification_url i user_code uzyskane w kroku 2. Obie wartości mogą zawierać dowolne znaki drukowalne z zestawu znaków US-ASCII. Treść wyświetlana użytkownikowi powinna zawierać instrukcje, jak przejść do verification_url na osobnym urządzeniu i wpisać 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 prawidłowo wyświetlić kodWWWWWWWWWWWWWWW, interfejs jest prawidłowy. Zalecamy użycie tej wartości ciągu znaków podczas testowania sposobu wyświetlania elementuuser_codew interfejsie. - W parametrze
user_codewielkość liter ma znaczenie, dlatego nie należy go w żaden sposób modyfikować, np. zmieniać wielkości liter ani wstawiać innych znaków formatowania.
- Wartość
verification_url- Miejsce, w którym wyświetlasz
verification_url, musi być wystarczająco szerokie, aby zmieścił się w nim ciąg adresu URL o długości 40 znaków. - Nie należy w żaden sposób modyfikować
verification_url, z wyjątkiem opcjonalnego usunięcia schematu na potrzeby wyświetlania. Jeśli planujesz usunąć schemat (np.https://) z adresu URL ze względów związanych z wyświetlaniem, upewnij się, że aplikacja obsługuje zarówno wariantyhttp, jak ihttps.
- Miejsce, w którym wyświetlasz
Krok 4. Odpytaj serwer autoryzacji Google
Użytkownik będzie używać osobnego urządzenia, aby przejść do verification_url i przyznać (lub odmówić) dostęp, dlatego urządzenie wysyłające żądanie nie zostanie automatycznie powiadomione, gdy użytkownik odpowie na żądanie dostępu. Z tego powodu 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ą wartości device_code i user_code uzyskane w
kroku 2. Wartość interval zwrócona w kroku 2 określa czas w sekundach, który należy odczekać między żądaniami.
Adres URL punktu końcowego do odpytywania to https://oauth2.googleapis.com/token. Żądanie sondowania zawiera te parametry:
| Parametry | |
|---|---|
client_id |
Identyfikator klienta aplikacji. Tę wartość znajdziesz na stronie Klientów w konsoli Cloud. |
client_secret |
Tajny klucz klienta dla podanego client_id. Tę wartość znajdziesz na stronie Klientów w konsoli Cloud. |
device_code |
device_code zwrócony przez serwer autoryzacji w kroku 2. |
grant_type |
Ustaw tę wartość na urn:ietf:params:oauth:grant-type:device_code. |
Przykłady
Poniższy 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 obrazie poniżej widać stronę podobną do tej, którą użytkownicy zobaczą po przejściu do verification_url wyświetlonego w kroku 3:
Po wpisaniu user_code i zalogowaniu się w Google (jeśli użytkownik nie jest jeszcze zalogowany) użytkownik zobaczy ekran zgody:
Krok 6. Przetwarzaj odpowiedzi na żądania odpytywania
Serwer autoryzacji Google odpowiada na każde żądanie odpytywania 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 API Google w imieniu użytkownika. (Właściwość scope w odpowiedzi określa, do których interfejsów API urządzenie ma dostęp).
W takim przypadku odpowiedź interfejsu API zawiera te pola:
| Pola | |
|---|---|
access_token |
Token wysyłany przez aplikację w celu autoryzacji żą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, dopóki użytkownik nie unieważni dostępu lub token odświeżania nie wygaśnie. Pamiętaj, że tokeny odświeżania są zawsze zwracane w przypadku urządzeń. |
scope |
Zakresy dostępu przyznane przez access_token, wyrażone jako lista ciągów znaków rozdzielonych spacjami, z uwzględnieniem wielkości liter. |
token_type |
Typ zwracanego tokena. Ta wartość zawsze wynosi Bearer. |
Poniższy 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 okres 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 Twoja aplikacja potrzebuje tego typu dostępu, powinna zapisać token odświeżania do późniejszego użycia.
Odmowa dostępu
Jeśli użytkownik odmówi przyznania dostępu do urządzenia, odpowiedź serwera będzie miała kod stanu odpowiedzi HTTP 403 (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ęste sondowanie
Jeśli urządzenie zbyt często wysyła żądania sondowania, 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 odpytywania brakuje wymaganych parametrów lub wartość parametru jest nieprawidłowa. Te żądania zwykle mają kod stanu odpowiedzi HTTP 400 (Bad Request) lub 401 (Unauthorized). Te błędy to:
| Błąd | Kod stanu HTTP | Opis |
|---|---|---|
admin_policy_enforced |
400 |
Konto Google nie może autoryzować co najmniej jednego żądanego 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 on wyraźnie przyznany Twojemu identyfikatorowi 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 wtedy, gdy wartość parametru Typ klienta OAuth jest nieprawidłowy. Upewnij się, że typ aplikacji dla identyfikatora klienta jest ustawiony na Telewizory i urządzenia wejściowe 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 jest częścią projektu ograniczającego 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 interfejsu API Google w imieniu danego konta użytkownika, jeśli przyznano zakresy dostępu wymagane przez interfejs API. Aby to zrobić, dołącz token dostępu do żądania do interfejsu API, podając parametr zapytania access_token lub wartość Bearer nagłówka HTTP Authorization. Jeśli to możliwe, lepiej używać nagłówka HTTP, ponieważ ciągi zapytań są zwykle widoczne w logach serwera. W większości przypadków możesz użyć biblioteki klienta, aby skonfigurować wywołania interfejsów API Google (na przykład podczas wywoływania interfejsu Drive Files API).
Możesz wypróbować wszystkie interfejsy API Google i wyświetlić ich zakresy w OAuth 2.0 Playground.
Przykłady HTTP GET
Wywołanie punktu końcowego
drive.files (interfejs 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 dla uwierzytelnionego użytkownika z użyciem parametru ciągu zapytania access_token:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl przykładu
Możesz przetestować te polecenia za pomocą aplikacji wiersza poleceń curl. Oto przykład użycia opcji nagłówka HTTP (preferowanej):
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 dla powiązanego żądania do interfejsu API. Możesz odświeżyć token dostępu bez proszenia użytkownika o zgodę (nawet jeśli użytkownik nie jest obecny), jeśli poprosisz o dostęp offline do zakresów powiązanych z tokenem.
Aby odświeżyć token dostępu, aplikacja wysyła do serwera autoryzacji Google (https://oauth2.googleapis.com/token) żądanie HTTPS POST, które zawiera w treści te parametry:
| Nazwa | Wartość |
|---|---|
client_id |
Identyfikator klienta uzyskany z Konsoli interfejsów API. |
client_secret |
Opcjonalny
Tajny klucz klienta uzyskany z Konsoli interfejsów API. |
grant_type |
Zgodnie z definicją w specyfikacji OAuth 2.0 wartość tego pola musi być ustawiona na refresh_token. |
refresh_token |
Token odświeżania zwrócony z wymiany kodu autoryzacji. |
Poniższy 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& refresh_token=refresh_token& grant_type=refresh_token
Jeśli użytkownik nie unieważnił dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON zawierający nowy token dostępu. Poniższy 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 tokenów odświeżania, które zostaną wydane, jest ograniczona. Istnieje limit na kombinację klient/użytkownik oraz limit na użytkownika we wszystkich klientach. Tokeny odświeżania należy zapisywać w pamięci długoterminowej i używać ich, dopóki są ważne. Jeśli aplikacja żąda zbyt wielu tokenów odświeżania, może przekroczyć te limity. W takim przypadku starsze tokeny odświeżania przestaną działać.
Unieważnienie tokena
W niektórych przypadkach użytkownik może chcieć anulować dostęp przyznany aplikacji. Użytkownik może anulować dostęp w ustawieniach konta. Więcej informacji znajdziesz w sekcji Usuwanie dostępu witryny lub aplikacji w dokumencie pomocy „Aplikacje i witryny innych firm mające dostęp do Twojego konta”.
Aplikacja może też programowo unieważnić przyznany jej dostęp. Programowe unieważnianie jest ważne w przypadkach, gdy użytkownik anuluje subskrypcję, usunie aplikację lub zasoby interfejsu API wymagane przez aplikację ulegną znacznej zmianie. Innymi słowy, część procesu usuwania może obejmować żądanie do interfejsu API, aby upewnić się, że uprawnienia wcześniej przyznane aplikacji zostały usunięte.
Aby programowo unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i dołącza 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 również zostanie unieważniony.
Jeśli unieważnienie zostanie przetworzone, kod stanu HTTP odpowiedzi to 200. W przypadku błędów zwracany jest kod stanu HTTP 400 wraz z kodem błędu.
Dozwolone zakresy
Przepływ OAuth 2.0 na urządzeniach jest obsługiwany tylko w przypadku tych zakresów:
OpenID Connect, Logowanie przez Google
emailopenidprofile
Drive 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 w celu wykonania działania. Dostęp czasowy jest dostępny w wybranych usługach Google podczas procesu wyrażania zgody, co daje użytkownikom możliwość przyznania dostępu na ograniczony czas. Przykładem jest interfejs Data Portability API, który umożliwia jednorazowe przeniesienie danych.
Gdy użytkownik przyzna Twojej aplikacji dostęp na określony czas, token odświeżania wygaśnie po upływie tego czasu. Pamiętaj, że w pewnych okolicznościach tokeny odświeżania mogą zostać unieważnione wcześniej. Szczegółowe informacje znajdziesz w tych przypadkach. W takich przypadkach pole refresh_token_expires_in zwracane w odpowiedzi na wymianę kodu autoryzacji reprezentuje czas pozostały do wygaśnięcia tokena odświeżania.
Wdrażanie ochrony wszystkich kont
Dodatkowym krokiem, który należy podjąć, aby chronić konta użytkowników, jest wdrożenie ochrony wszystkich kont za pomocą usługi ochrony wszystkich kont Google. 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. Możesz następnie wykorzystać te informacje, aby podjąć działania w zależności od tego, jak chcesz zareagować 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
Więcej informacji o tym, jak wdrożyć ochronę wszystkich kont, oraz pełną listę dostępnych zdarzeń znajdziesz na stronie Chroń konta użytkowników za pomocą ochrony wszystkich kont .