OAuth 2.0 na potrzeby aplikacji mobilnych i komputerowych

Z tego dokumentu dowiesz się, jak aplikacje komputerowe (np. działające w systemie Windows, macOS lub Linux albo narzędzia interfejsu wiersza poleceń) używają punktów końcowych OAuth 2.0 Google do autoryzowania dostępu do interfejsu YouTube Data API.

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 może używać protokołu OAuth 2.0, aby uzyskać uprawnienia do pobierania danych kanału w YouTube.

Aplikacje komputerowe są instalowane lokalnie na komputerze użytkownika (np. samodzielne oprogramowanie komputerowe, narzędzia CLI dla programistów, narzędzia do synchronizacji w tle lub skrypty). Ponieważ te aplikacje są rozpowszechniane na poszczególnych urządzeniach, zakłada się, że nie mogą one zachować poufności (są to klienci publiczni). Mogą uzyskiwać dostęp do interfejsów API Google, gdy użytkownik aktywnie korzysta z aplikacji lub gdy aplikacja działa w tle.

Ten proces autoryzacji jest podobny do procesu używanego w przypadku aplikacji serwera WWW. Główna różnica polega na tym, że aplikacje komputerowe muszą otwierać przeglądarkę systemową i podawać lokalny identyfikator URI przekierowania (np. adres IP pętli zwrotnej), aby obsługiwać odpowiedzi z serwera autoryzacji Google.

Biblioteki i przykłady

Podczas wdrażania protokołu OAuth 2.0 w aplikacjach komputerowych zalecamy korzystanie z bibliotek klienta interfejsów API Google w wybranym języku programowania (np. Python, Java, Node.js, Go, .NET). Biblioteki klienta obsługują autoryzację użytkowników i zarządzanie tokenami, dzięki czemu implementacja jest prostsza i mniej podatna na błędy niż bezpośrednie korzystanie z punktów końcowych HTTP/REST niższego poziomu.

W przypadku aplikacji mobilnych zapoznaj się z przewodnikami po autoryzacji na Android i iOS.

W przypadku aplikacji działających na urządzeniach, które nie obsługują przeglądarki systemowej lub mają ograniczone możliwości wprowadzania danych, takich jak telewizory, konsole do gier, aparaty fotograficzne czy drukarki, zapoznaj się z artykułem OAuth 2.0 na telewizorach i urządzeniach lub Logowanie się na telewizorach i urządzeniach z ograniczoną możliwością wpisywania.

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:

1. Otwórz Bibliotekę interfejsów API w Konsoli interfejsów API Google.
2. Jeśli pojawi się taka prośba, wybierz projekt lub utwórz nowy.
3. Na stronie Biblioteka znajdź i włącz YouTube Data API. Znajdź inne interfejsy API, których będzie używać Twoja aplikacja, i je też włącz.

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.

1. Otwórz stronę Klienci.
2. Kliknij Utwórz klienta.
3. Wybierz typ aplikacji Aplikacja komputerowa.
4. W polu Nazwa wpisz nazwę klienta OAuth. Ta nazwa jest wyświetlana na stronie Klientów projektu, aby umożliwić identyfikację klienta.
5. Kliknij Utwórz.

Identyfikator klienta i tajny klucz klienta zostaną wygenerowane i wyświetlone w konsoli Google Cloud. Aplikacje komputerowe są klientami publicznymi i nie mogą zachować poufności tajnych kluczy. Podczas wysyłania żądań kodów autoryzacji zawsze używaj PKCE (Proof Key for Code Exchange).

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.

Interfejs YouTube Data API v3 używa tych zakresów:

Dokument Zakresy interfejsu OAuth 2.0 API zawiera pełną listę zakresów, których możesz używać do uzyskiwania dostępu do interfejsów API Google.

Uzyskiwanie tokenów dostępu OAuth 2.0

Poniżej opisujemy, jak aplikacja współdziała z serwerem OAuth 2.0 Google, aby uzyskać zgodę użytkownika na wysłanie żądania do interfejsu API w jego imieniu. Twoja aplikacja musi uzyskać tę zgodę, zanim będzie mogła wykonać żądanie do interfejsu API Google, które wymaga autoryzacji użytkownika.

Krok 1. Wygeneruj weryfikator kodu i wyzwanie

Google obsługuje protokół Proof Key for Code Exchange (PKCE), aby zwiększyć bezpieczeństwo przepływu aplikacji instalowanej. Dla każdego żądania autoryzacji tworzony jest unikalny weryfikator kodu, a jego przekształcona wartość, zwana „code_challenge”, jest wysyłana do serwera autoryzacji w celu uzyskania kodu autoryzacji.

Tworzenie weryfikatora kodu

code_verifier to losowy ciąg kryptograficzny o wysokiej entropii, który zawiera znaki [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" i ma długość od 43 do 128 znaków.

Weryfikator kodu powinien mieć wystarczającą entropię, aby odgadnięcie wartości było niemożliwe.

Tworzenie kodu

Obsługiwane są 2 metody tworzenia wyzwania kodu.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

Krok 2. Wyślij żądanie do serwera OAuth 2.0 Google

Aby uzyskać autoryzację użytkownika, wyślij żądanie do serwera autoryzacji Google na adres https://accounts.google.com/o/oauth2/v2/auth. Ten punkt końcowy obsługuje wyszukiwanie aktywnej sesji, uwierzytelnia użytkownika i uzyskuje jego zgodę. Punkt końcowy jest dostępny tylko przez SSL i odrzuca połączenia HTTP (inne niż SSL).

Serwer autoryzacji obsługuje te parametry ciągu zapytania w przypadku zainstalowanych aplikacji:

Przykładowe adresy URL autoryzacji

Na kartach poniżej znajdziesz przykładowe adresy URL autoryzacji dla różnych opcji identyfikatorów URI przekierowania.

Adresy URL są identyczne z wyjątkiem wartości parametru redirect_uri. Adresy URL zawierają też wymagane parametry response_type i client_id oraz opcjonalny parametr state. Każdy adres URL zawiera podziały wierszy i spacje, aby był bardziej czytelny.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Krok 3. Google prosi użytkownika o zgodę

W tym kroku użytkownik decyduje, czy przyznać aplikacji żądany dostęp. Na tym etapie Google wyświetla okno zgody, które zawiera nazwę aplikacji i interfejsy API Google, do których aplikacja prosi o dostęp, oraz dane uwierzytelniające użytkownika i podsumowanie zakresów dostępu, które zostaną przyznane. Użytkownik może wtedy wyrazić zgodę na przyznanie dostępu do co najmniej 1 zakresu, o który prosi aplikacja, lub odrzucić prośbę.

Na tym etapie aplikacja nie musi nic robić, ponieważ czeka na odpowiedź z serwera OAuth 2.0 Google, która wskazuje, czy dostęp został przyznany. Odpowiedź została wyjaśniona w następnym kroku.

Krok 4. Przetwórz odpowiedź serwera OAuth 2.0

Sposób, w jaki aplikacja otrzymuje odpowiedź autoryzacji, zależy od używanego przez nią schematu identyfikatora URI przekierowania. Niezależnie od schematu odpowiedź będzie zawierać kod autoryzacji (code) lub błąd (error). Na przykład error=access_denied oznacza, że użytkownik odrzucił prośbę.

Jeśli użytkownik przyzna dostęp do aplikacji, możesz wymienić kod autoryzacji na token dostępu i token odświeżania, jak opisano w następnym kroku.

Krok 5. Wymień kod autoryzacji na tokeny odświeżania i dostępu

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

Chociaż użycie DPoP jest opcjonalne, zalecamy je w celu zwiększenia bezpieczeństwa. Bezpieczeństwo DPoP zależy od tego, czy klucz prywatny jest ograniczony do jednego urządzenia. Zalecamy przechowywanie go w sposób uniemożliwiający skopiowanie go poza urządzenie, na przykład przy użyciu modułów TPM, bezpiecznych enklaw lub innych magazynów kluczy obsługiwanych sprzętowo. Aby korzystać z DPoP, aplikacja musi wygenerować nowy, unikalny token JWT potwierdzający DPoP dla każdego żądania do punktu końcowego tokena i dodać go jako nagłówek żądania HTTP.

Poniższy fragment kodu pokazuje przykładowe żądanie:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Tworzenie dowodu DPoP

Poniżej opisujemy, jak utworzyć dowód DPoP za pomocą OpenSSL z wiersza poleceń:

1. Wygeneruj parę kluczy EC P-256:

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. Utwórz nagłówek DPoP:

   Nagłówek musi zawierać oświadczenia typ, alg i jwk (klucz publiczny). Wartości x i y to współrzędne klucza publicznego EC zakodowane w formacie Base64Url. Zakoduj ten obiekt JSON w formacie Base64Url:

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. Utwórz ładunek DPoP:

   Ładunek musi zawierać jti (unikalny identyfikator żądania), htm (metoda HTTP, np. POST), htu (identyfikator URI HTTP, np. https://oauth2.googleapis.com/token) i iat (czas wydania). Jeśli w odpowiedzi na poprzednie żądanie serwer przesłał liczbę jednorazową w nagłówku DPoP-Nonce, musisz uwzględnić tę wartość w deklaracji nonce. Deklaracja liczby jednorazowej jest opcjonalna w przypadku wymiany kodów autoryzacji i jest używana tylko wtedy, gdy wcześniej otrzymano nagłówek DPoP-Nonce. Zakoduj ten obiekt JSON w formacie Base64Url:

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   Wartość jti zależy od typu giełdy:

   • W przypadku wymiany kodów autoryzacji parametr jti musi być zakodowanym w formacie Base64Url skrótem SHA256 kodu autoryzacji: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
   • W przypadku wymiany tokenów odświeżania parametr jti musi być unikalnym identyfikatorem żądania: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
4. Podpisywanie dowodu:

   Połącz zakodowany nagłówek i ładunek, używając kropki (.), a następnie podpisz wynik kluczem prywatnym za pomocą algorytmu ES256. Pamiętaj, że JWS wymaga, aby podpis był w nieprzetworzonym formacie połączonym R | S (64 bajty dla P-256). Jeśli używasz bezpośrednio OpenSSL, musisz przekonwertować domyślny podpis zakodowany w formacie ASN.1 DER na ten format nieprzetworzony.

Pomyślna wymiana jest sygnalizowana odpowiedzią 200 OK zawierającą tokeny. Jeśli podczas wymiany zostanie użyty prawidłowy dowód DPoP, token odświeżania zwrócony przez Google będzie powiązany z Twoim kluczem za pomocą DPoP, ale tokeny dostępu nie będą powiązane z DPoP. Tokeny dostępu zachowają token_type Bearer, a nie DPoP. Dodatkowo Google zwraca w odpowiedzi nagłówek HTTP DPoP-Nonce. Klient musi zapisać tę liczbę jednorazową w pamięci podręcznej i uwzględnić ją w oświadczeniu nonce dowodu DPoP w kolejnych żądaniach (np. podczas wymiany tokena odświeżania na nowy token dostępu lub wywoływania interfejsów API chronionych przez DPoP). Używając tej wcześniej wydanej liczby jednorazowej, możesz uniknąć dodatkowego błędu komunikacji (use_dpop_nonce) przy następnym żądaniu.

W przypadku żądań wymiany tokenów wysyłanych z tokenami odświeżania powiązanymi z DPoP należy dołączyć dowody DPoP.

Nieudana wymiana ma miejsce, gdy nagłówek DPoP jest nieobecny, mimo że jest oczekiwany, jest nieprawidłowy lub gdy dowód używa innego klucza niż ten powiązany z tokenem. W takich przypadkach serwer zwraca błąd 400 Bad Request. Jeśli dowód DPoP zawiera niezgodne deklaracje htm lub htu, wygasłą deklarację iat, ponownie użytą deklarację jti lub nieprawidłowy podpis, Google zwraca kod błędu invalid_dpop_proof. Jeśli wymagana jest liczba jednorazowa DPoP, np.podczas wymiany tokena odświeżania, a w dowodzie DPoP brakuje deklaracji nonce lub wartość liczby jednorazowej jest nieakceptowalna dla serwera (np. wygasła, została już użyta lub jest nieprawidłowa), Google zwraca kod błędu use_dpop_nonce wraz z nagłówkiem HTTP DPoP-Nonce zawierającym nową liczbę jednorazową, której możesz użyć w kolejnym żądaniu. Inne błędy mogą zwracać invalid_grant.

Google odpowiada na to żądanie, zwracając obiekt JSON zawierający krótkotrwały token dostępu i token odświeżania.

Odpowiedź zawiera te pola:

Poniższy fragment kodu pokazuje przykładowe nagłówki odpowiedzi i treść, gdy używany jest protokół DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

Krok 6. Sprawdź, które zakresy przyznali użytkownicy

Jeśli poprosisz o kilka uprawnień (zakresów), użytkownicy mogą nie przyznać aplikacji dostępu do wszystkich z nich. Aplikacja musi sprawdzić, które zakresy zostały faktycznie przyznane, i odpowiednio obsłużyć sytuacje, w których niektóre uprawnienia zostały odrzucone, zwykle przez wyłączenie funkcji, które korzystają z tych odrzuconych zakresów.

Są jednak wyjątki. Aplikacje Google Workspace Enterprise z przekazywaniem uprawnień dostępu w całej domenie lub aplikacje oznaczone jako zaufane pomijają ekran zgody na uprawnienia szczegółowe. W przypadku tych aplikacji użytkownicy nie zobaczą ekranu zgody na szczegółowe uprawnienia. Zamiast tego aplikacja otrzyma wszystkie żądane zakresy lub żadne.

Więcej informacji znajdziesz w artykule Jak postępować z uprawnieniami szczegółowymi.

Aby sprawdzić, czy użytkownik przyznał aplikacji dostęp do określonego zakresu, sprawdź pole scope w odpowiedzi tokena dostępu. Zakresy dostępu przyznane przez parametr access_token, wyrażone jako lista ciągów znaków rozdzielonych spacjami, z uwzględnieniem wielkości liter.

Na przykład ta przykładowa odpowiedź z tokenem dostępu wskazuje, że użytkownik przyznał aplikacji uprawnienia do odczytu aktywności na Dysku i wydarzeń w Kalendarzu:

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

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 YouTube Live Streaming API).

Pamiętaj, że interfejs YouTube Live Streaming API nie obsługuje przepływu konta usługi. Nie ma możliwości połączenia konta usługi z kontem YouTube, więc próby autoryzacji żądań za pomocą tego procesu będą generować błąd NoLinkedYouTubeAccount.

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 liveBroadcasts.list (interfejs YouTube Live Streaming API) za pomocą nagłówka HTTP Authorization: Bearer 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 z użyciem parametru ciągu zapytania access_token:

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

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/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

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:

Chociaż użycie DPoP jest opcjonalne, zalecamy je w celu zwiększenia bezpieczeństwa. Aby używać DPoP z tokenem odświeżania, aplikacja musi wygenerować nowy, unikalny token JWT potwierdzający DPoP dla każdego żądania wysyłanego do punktu końcowego tokena. To potwierdzenie musi być podpisane tym samym kluczem prywatnym, który został użyty podczas początkowej wymiany kodu autoryzacji. Aplikacja dodaje dowód jako nagłówek żądania HTTP.

Poniższy fragment kodu pokazuje przykładowe żądanie:

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Aby używać DPoP z tokenem odświeżania, musisz wygenerować nowy, unikalny token JWT potwierdzenia DPoP dla żądania. Szczegółowe instrukcje generowania pary kluczy i tworzenia tokena JWT znajdziesz w sekcji Tworzenie dowodu DPoP.

Pomyślna wymiana jest sygnalizowana odpowiedzią 200 OK zawierającą nowy token dostępu. Gdy używany jest protokół DPoP, token_type to Bearer. Odpowiedź z powodzeniem potwierdza, że dowód DPoP dla tokena odświeżania został zaakceptowany. Google może też zwrócić w odpowiedzi nowy nagłówek HTTP DPoP-Nonce. Jeśli zostanie zwrócony, klient musi zapisać tę liczbę jednorazową w pamięci podręcznej i uwzględnić ją w oświadczeniu nonce dowodu DPoP w kolejnych żądaniach.

Nieudana wymiana ma miejsce, gdy brakuje nagłówka DPoP, jest on nieprawidłowy lub używa nieprawidłowego klucza. Szczegółowe informacje o konkretnych kodach błędów DPoP i obsłudze liczb jednorazowych znajdziesz w sekcji Nieudana wymiana.

Poniższy fragment kodu pokazuje przykładowe nagłówki odpowiedzi i treść, gdy używany jest protokół DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

Metody przekierowania do aplikacji

Ochrona aplikacji

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.

Więcej informacji

Wiele sprawdzonych metod opisanych w tym dokumencie zostało określonych w dokumencie IETF Best Current Practice OAuth 2.0 for Native Apps.