Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

OAuth 2.0 dla aplikacji mobilnych i stacjonarnych

Ten dokument wyjaśnia, w jaki sposób aplikacje zainstalowane na urządzeniach takich jak telefony, tablety i komputery używają punktów końcowych Google OAuth 2.0 do autoryzacji dostępu do interfejsów API Google.

OAuth 2.0 umożliwia użytkownikom udostępnianie określonych danych aplikacji przy zachowaniu prywatności ich nazw użytkowników, haseł i innych informacji. Na przykład aplikacja może używać protokołu OAuth 2.0 do uzyskiwania od użytkowników uprawnień do przechowywania plików na ich Dyskach Google.

Zainstalowane aplikacje są dystrybuowane na poszczególne urządzenia i zakłada się, że te aplikacje nie mogą zachować tajemnic. Mogą uzyskiwać dostęp do interfejsów API Google, gdy użytkownik jest obecny w aplikacji lub gdy aplikacja działa w tle.

Ten przepływ autoryzacji jest podobny do tego używanego dla aplikacji serwera WWW . Główna różnica polega na tym, że zainstalowane aplikacje muszą otwierać przeglądarkę systemową i dostarczać lokalny identyfikator URI przekierowania, aby obsługiwać odpowiedzi z serwera autoryzacyjnego Google.

Alternatywy

W przypadku aplikacji mobilnych możesz preferować logowanie przez Google na Androida lub iOS . Biblioteki klienta logowania Google obsługują uwierzytelnianie i autoryzację użytkowników i mogą być prostsze w implementacji niż opisany tutaj protokół niższego poziomu.

W przypadku aplikacji działających na urządzeniach, które nie obsługują przeglądarki systemowej lub które mają ograniczone możliwości wprowadzania danych, takich jak telewizory, konsole do gier, kamery lub drukarki, zobacz OAuth 2.0 dla telewizorów i urządzeń lub Logowanie przez Google dla urządzeń .

Biblioteki i próbki

Zalecamy następujące biblioteki i przykłady, które pomogą Ci wdrożyć przepływ OAuth 2.0 opisany w tym dokumencie:

Wymagania wstępne

Włącz interfejsy API dla swojego projektu

Każda aplikacja, która wywołuje interfejsy API Google, musi je włączyć w API Console.

Aby włączyć interfejs API dla swojego projektu:

  1. Open the API Library w Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library zawiera listę wszystkich dostępnych interfejsów API, pogrupowanych według rodziny produktów i popularności. Jeśli API, które chcesz włączyć, nie jest widoczne na liście, użyj funkcji wyszukiwania, aby go znaleźć, lub kliknij opcję Wyświetl wszystko w rodzinie produktów, do której należy.
  4. Wybierz interfejs API, który chcesz włączyć, a następnie kliknij przycisk Włącz .
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Utwórz dane uwierzytelniające

Każda aplikacja korzystająca z protokołu OAuth 2.0 w celu uzyskania dostępu do interfejsów API Google musi mieć dane uwierzytelniające identyfikujące aplikację na serwerze Google OAuth 2.0. Poniższe kroki wyjaśniają, jak utworzyć poświadczenia dla projektu. Twoje aplikacje mogą następnie używać poświadczeń do uzyskiwania dostępu do interfejsów API, które zostały włączone dla tego projektu.

  1. Go to the Credentials page.
  2. Kliknij Utwórz dane logowania> Identyfikator klienta OAuth .
  3. Poniższe sekcje opisują typy klientów i metody przekierowania obsługiwane przez serwer autoryzacji Google. Wybierz typ klienta zalecany dla Twojej aplikacji, nazwij swojego klienta OAuth i odpowiednio ustaw pozostałe pola w formularzu.

Niestandardowy schemat URI (Android, iOS, UWP)

Niestandardowy schemat identyfikatora URI jest zalecany dla aplikacji na Androida, aplikacji dla systemu iOS i aplikacji platformy uniwersalnej systemu Windows (UWP).

Android
  1. Wybierz typ aplikacji na Androida .
  2. Wpisz nazwę klienta OAuth. Ta nazwa jest wyświetlana na Credentials page projektu w celu zidentyfikowania klienta.
  3. Wpisz nazwę pakietu aplikacji na Androida. Ta wartość jest zdefiniowana w atrybucie package elementu <manifest> w pliku manifestu aplikacji.
  4. Wprowadź odcisk cyfrowy certyfikatu podpisującego SHA-1 dystrybucji aplikacji.
    • Jeśli Twoja aplikacja korzysta z podpisywania aplikacji przez Google Play , skopiuj odcisk palca SHA-1 ze strony podpisywania aplikacji w Konsoli Play.
    • Jeśli zarządzasz własnym magazynem kluczy i kluczami do podpisywania, użyj narzędzia keytool dołączonego do języka Java, aby wydrukować informacje o certyfikatach w formacie czytelnym dla człowieka. Skopiuj wartość SHA1 z sekcji Certificate fingerprints danych wyjściowych narzędzia keytool . Aby uzyskać więcej informacji, zobacz Uwierzytelnianie klienta w dokumentacji interfejsów API Google dla Androida.
  5. Kliknij Utwórz .
iOS
  1. Wybierz typ aplikacji na iOS .
  2. Wpisz nazwę klienta OAuth. Ta nazwa jest wyświetlana na Credentials page projektu w celu zidentyfikowania klienta.
  3. Wpisz identyfikator pakietu dla swojej aplikacji. Identyfikator pakietu to wartość klucza CFBundleIdentifier w pliku zasobów listy właściwości informacji aplikacji ( info.plist ). Wartość jest najczęściej wyświetlana w okienku Ogólne lub w panelu Podpisywanie i możliwości w edytorze projektów Xcode. Identyfikator pakietu jest również wyświetlany w sekcji Informacje ogólne na stronie Informacje o aplikacji dla aplikacji w witrynie Apple App Store Connect .
  4. (Opcjonalny)

    Wprowadź identyfikator App Store swojej aplikacji, jeśli jest ona opublikowana w sklepie Apple App Store. Identyfikator sklepu to ciąg liczbowy zawarty w każdym adresie URL sklepu Apple App Store.

    1. Otwórz aplikację Apple App Store na urządzeniu z systemem iOS lub iPadOS.
    2. Wyszukaj swoją aplikację.
    3. Wybierz przycisk Udostępnij (kwadrat i symbol strzałki w górę).
    4. Wybierz opcję Kopiuj łącze .
    5. Wklej link do edytora tekstu. Identyfikator App Store to ostatnia część adresu URL.

      Przykład: https://apps.apple.com/app/google/id 284815942

  5. (Opcjonalny)

    Wpisz swój identyfikator zespołu. Aby uzyskać więcej informacji, zobacz Znajdowanie identyfikatora zespołu w dokumentacji konta programisty Apple.

  6. Kliknij Utwórz .
UWP
  1. Wybierz typ aplikacji Universal Windows Platform .
  2. Wpisz nazwę klienta OAuth. Ta nazwa jest wyświetlana na Credentials page projektu w celu zidentyfikowania klienta.
  3. Wprowadź 12-znakowy identyfikator Microsoft Store swojej aplikacji. Tę wartość można znaleźć w witrynie Microsoft Partner Center na stronie tożsamości aplikacji w sekcji Zarządzanie aplikacjami.
  4. Kliknij Utwórz .

W przypadku aplikacji platformy UWP niestandardowy schemat identyfikatora URI nie może być dłuższy niż 39 znaków.

Adres IP pętli zwrotnej (macOS, Linux, pulpit Windows)

Aby otrzymać kod autoryzacji przy użyciu tego adresu URL, Twoja aplikacja musi nasłuchiwać na lokalnym serwerze WWW. Jest to możliwe na wielu platformach, ale nie na wszystkich. Jeśli jednak Twoja platforma to obsługuje, jest to zalecany mechanizm uzyskiwania kodu autoryzacyjnego.

Gdy Twoja aplikacja otrzyma odpowiedź autoryzacyjną, w celu uzyskania najlepszej użyteczności powinna odpowiadać wyświetlając stronę HTML, która instruuje użytkownika, aby zamknął przeglądarkę i powrócił do aplikacji.

Zalecane użycie Aplikacje na komputery MacOS, Linux i Windows (ale nie Universal Windows Platform)
Wartości formularza Ustaw typ aplikacji na Aplikacja komputerowa .

Ręczne kopiowanie / wklejanie

Ekstrakcja programowa

Zidentyfikuj zakresy dostępu

Zakresy umożliwiają aplikacji żądanie dostępu tylko do zasobów, których potrzebuje, jednocześnie umożliwiając użytkownikom kontrolowanie ilości dostępu, który przyznają aplikacji. W związku z tym może wystąpić odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Przed rozpoczęciem wdrażania autoryzacji OAuth 2.0 zalecamy zidentyfikowanie zakresów, do których aplikacja będzie potrzebować uprawnień dostępu.

Dokument OAuth 2.0 API Scopes zawiera pełną listę zakresów, których możesz użyć, aby uzyskać dostęp do interfejsów API Google.

Uzyskanie tokenów dostępu OAuth 2.0

Poniższe kroki pokazują, jak Twoja aplikacja współdziała z serwerem Google OAuth 2.0 w celu uzyskania zgody użytkownika na wykonanie żądania API w imieniu użytkownika. Twoja aplikacja musi mieć tę zgodę, zanim będzie mogła wykonać żądanie Google API wymagające 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 zainstalowanej aplikacji. Dla każdego żądania autoryzacji tworzony jest unikalny weryfikator kodu, a jego przekształcona wartość o nazwie „code_challenge” jest wysyłana do serwera autoryzacyjnego w celu uzyskania kodu autoryzacyjnego.

Utwórz weryfikator kodu

code_verifier to losowy ciąg kryptograficzny o wysokiej entropii, code_verifier znaki [AZ] / [az] / [0-9] / "-" / "." / "_" / "~", o minimalnej długości 43 znaków i maksymalnej długości 128 znaków.

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

Utwórz wyzwanie kodu

Obsługiwane są dwie metody tworzenia wyzwania kodu.

Metody generowania wyzwań kodu
S256 (zalecane) Wyzwaniem kodu jest skrót SHA256 zakodowany w Base64URL (bez dopełnienia) weryfikatora kodu.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
Równina Wezwanie do kodu ma taką samą wartość, jak w przypadku weryfikatora kodu wygenerowanego powyżej.
code_challenge = code_verifier

Krok 2: wyślij żądanie do serwera Google OAuth 2.0

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

Serwer autoryzacji obsługuje następujące parametry ciągu zapytania dla zainstalowanych aplikacji:

Parametry
client_id wymagany

Identyfikator klienta dla Twojej aplikacji. Możesz znaleźć tę wartość w API Console Credentials page.

redirect_uri wymagany

Określa, w jaki sposób serwer autoryzacji Google wysyła odpowiedź do Twojej aplikacji. Dostępnych jest kilka opcji przekierowania dla zainstalowanych aplikacji, a poświadczenia autoryzacji należy skonfigurować z uwzględnieniem określonej metody przekierowania.

Wartość musi dokładnie odpowiadać jednemu z autoryzowanych identyfikatorów URI przekierowania dla klienta OAuth 2.0, które zostały skonfigurowane w pliku API Console Credentials page klienta. Jeśli ta wartość nie pasuje do autoryzowanego identyfikatora URI, pojawi się błąd redirect_uri_mismatch .

Poniższa tabela przedstawia odpowiednią wartość parametru redirect_uri dla każdej metody:

wartości redirect_uri
Niestandardowy schemat URI com.example.app : redirect_uri_path

lub

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.app to odwrotna notacja DNS domeny, nad którą masz kontrolę. Schemat niestandardowy musi zawierać okres, aby był ważny.
  • com.googleusercontent.apps.123 to odwrotna notacja DNS identyfikatora klienta.
  • redirect_uri_path to opcjonalny składnik ścieżki, taki jak /oauth2redirect . Zwróć uwagę, że ścieżka powinna zaczynać się od pojedynczego ukośnika, który różni się od zwykłych adresów URL HTTP.
Adres IP pętli zwrotnej http://127.0.0.1: port lub http://[::1]: port

Zapytaj swoją platformę o odpowiedni adres IP sprzężenia zwrotnego i uruchom nasłuchiwanie HTTP na losowo dostępnym porcie. Zastąp port faktycznym numerem portu, na którym nasłuchuje aplikacja.

Ręczne kopiowanie / wklejanie urn:ietf:wg:oauth:2.0:oob
Ekstrakcja programowa urn:ietf:wg:oauth:2.0:oob:auto
response_type wymagany

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

Ustaw wartość parametru na code dla zainstalowanych aplikacji.

scope wymagany

Rozdzielana spacjami lista zakresów identyfikująca zasoby, do których aplikacja może uzyskać dostęp w imieniu użytkownika. Te wartości informują o ekranie akceptacji, który Google wyświetla użytkownikowi.

Zakresy umożliwiają aplikacji żądanie dostępu tylko do zasobów, których potrzebuje, jednocześnie umożliwiając użytkownikom kontrolowanie ilości dostępu, który przyznają aplikacji. W związku z tym istnieje odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

code_challenge Zalecana

Określa zakodowany code_verifier który będzie używany jako wezwanie po stronie serwera podczas wymiany kodu autoryzacji. Ten parametr musi być używany z parametrem code_challenge opisanym powyżej. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą tworzenia kodu wyzwania powyżej.

code_challenge_method Zalecana

Określa, jaka metoda została użyta do zakodowania code_verifier który będzie używany podczas wymiany kodu autoryzacji. Ten parametr musi być używany z parametrem code_challenge . Wartość code_challenge_method domyślnie plain jeśli nie ma jej w żądaniu, które zawiera code_challenge . Jedyne obsługiwane wartości tego parametru to S256 lub plain .

state Zalecana

Określa dowolną wartość ciągu używaną przez aplikację do utrzymywania stanu między żądaniem autoryzacji a odpowiedzią serwera autoryzacji. Serwer zwraca dokładną wartość, którą wysyłasz jako parę name=value w identyfikatorze fragmentu adresu URL ( # ) redirect_uri po tym, jak użytkownik wyrazi zgodę lub odmówi dostępu do aplikacji.

Tego parametru można używać do różnych celów, takich jak kierowanie użytkownika do odpowiedniego zasobu w aplikacji, wysyłanie wartości nonces i ograniczanie możliwości fałszowania żądań między lokacjami. Ponieważ można odgadnąć Twoje redirect_uri , użycie wartości state może zwiększyć pewność, że połączenie przychodzące jest wynikiem żądania uwierzytelnienia. Jeśli wygenerujesz losowy ciąg lub zakodujesz skrót pliku cookie lub inną wartość, która przechwytuje stan klienta, możesz zweryfikować odpowiedź, aby dodatkowo upewnić się, że żądanie i odpowiedź pochodzą z tej samej przeglądarki, zapewniając ochronę przed atakami, takimi jak między witrynami zażądać fałszerstwa. Zobacz dokumentację OpenID Connect, aby zapoznać się z przykładem tworzenia i potwierdzania tokenu state .

login_hint Opcjonalny

Jeśli Twoja aplikacja wie, który użytkownik próbuje się uwierzytelnić, może użyć tego parametru, aby podać wskazówkę serwerowi Google Authentication Server. Serwer korzysta z podpowiedzi, aby uprościć proces logowania, wypełniając wstępnie pole adresu e-mail w formularzu logowania lub wybierając odpowiednią sesję wielokrotnego logowania.

Ustaw wartość parametru na adres e-mail lub identyfikator sub , który jest odpowiednikiem identyfikatora Google użytkownika.

Przykładowe adresy URL autoryzacji

Poniższe karty pokazują przykładowe adresy URL autoryzacji dla różnych opcji przekierowania URI.

Adresy URL są identyczne, z wyjątkiem wartości parametru redirect_uri . Adresy URL zawierają również wymagane parametry response_type i client_id , a także opcjonalny parametr state . Każdy adres URL zawiera podziały wierszy i spacje w celu zwiększenia czytelności.

Niestandardowy schemat URI

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

Adres IP pętli zwrotnej

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

Kopiuj wklej

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

Ekstrakcja programowa

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

Krok 3: Google prosi użytkownika o zgodę

Na tym etapie użytkownik decyduje, czy przyznać aplikacji żądany dostęp. Na tym etapie Google wyświetla okno zgody, które pokazuje nazwę Twojej aplikacji i usług Google API, do których prosi o pozwolenie, wraz z danymi uwierzytelniającymi użytkownika i podsumowaniem zakresów dostępu, które mają zostać przyznane. Użytkownik może następnie wyrazić zgodę na udzielenie dostępu do jednego lub większej liczby zakresów wymaganych w aplikacji lub odrzucić żądanie.

Twoja aplikacja nie musi nic robić na tym etapie, ponieważ czeka na odpowiedź z serwera Google OAuth 2.0 wskazującą, czy przyznano jakikolwiek dostęp. Ta odpowiedź jest wyjaśniona w następnym kroku.

Krok 4: obsłuż odpowiedź serwera OAuth 2.0

Sposób, w jaki aplikacja otrzymuje odpowiedź autoryzacyjną, zależy od schematu URI przekierowania , z którego korzysta. Niezależnie od schematu odpowiedź będzie zawierała albo kod autoryzacyjny ( code ), albo błąd ( error ). Na przykład error=access_denied wskazuje, że użytkownik odrzucił żądanie.

Jeśli użytkownik przyzna dostęp do Twojej aplikacji, możesz wymienić kod autoryzacyjny na token dostępu i token odświeżania zgodnie z opisem w następnym kroku.

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

Aby wymienić kod autoryzacyjny na token dostępu, wywołaj punkt końcowy https://oauth2.googleapis.com/token i ustaw następujące parametry:

Pola
client_id Identyfikator klienta uzyskany z API Console Credentials page.
client_secret Sekret klienta uzyskany z API Console Credentials page.
code Kod autoryzacji zwrócony z pierwotnego żądania.
code_verifier Weryfikator kodu utworzony w kroku 1 .
grant_type Zgodnie z definicją w specyfikacji OAuth 2.0 wartość tego pola musi być ustawiona na authorization_code .
redirect_uri Jeden z identyfikatorów URI przekierowania wymienionych dla Twojego projektu w API Console Credentials page dla podanego client_id .

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

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

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

Odpowiedź zawiera następujące pola:

Pola
access_token Token wysyłany przez Twoją aplikację w celu autoryzacji żądania Google API.
expires_in Pozostały okres istnienia tokenu dostępu w sekundach.
id_token Uwaga: ta właściwość jest zwracana tylko wtedy, gdy żądanie zawierało zakres tożsamości, taki jak identyfikator openid , profile lub email . Wartością jest token sieciowy JSON (JWT) zawierający podpisane cyfrowo informacje o tożsamości użytkownika.
refresh_token Token, za pomocą którego możesz uzyskać nowy token dostępu. Tokeny odświeżania są ważne, dopóki użytkownik nie cofnie dostępu. Należy pamiętać, że tokeny odświeżania są zawsze zwracane w przypadku zainstalowanych aplikacji.
scope Zakresy dostępu przyznane przez access_token wyrażone jako lista ciągów rozdzielanych spacjami z rozróżnianiem wielkości liter.
token_type Typ zwróconego tokena. W tej chwili wartość tego pola jest zawsze ustawiona na Bearer .

Poniższy fragment kodu przedstawia przykładową odpowiedź:

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

Wywołanie interfejsów API Google

Gdy aplikacja uzyska token dostępu, możesz go używać do wykonywania wywołań interfejsu API Google w imieniu danego konta użytkownika, jeśli zakres (y) dostępu wymagane przez interfejs API zostały przyznane. Aby to zrobić, należy dołączyć token dostępu w żądaniu API poprzez włączenie OSOBĄ access_token parametr zapytania lub Authorization HTTP nagłówek Bearer wartości. Jeśli to możliwe, preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. W większości przypadków możesz użyć biblioteki klienckiej, 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 (interfejsu Drive Files API) przy użyciu nagłówka HTTP Authorization: Bearer może wyglądać następująco. Pamiętaj, że musisz określić 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 przy użyciu parametru ciągu zapytania access_token :

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl przykłady

Możesz przetestować te polecenia za pomocą aplikacji wiersza poleceń curl . Oto przykład wykorzystujący opcję nagłówka HTTP (preferowana):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Lub alternatywnie opcja 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 tracą ważność i stają się nieprawidłowe poświadczenia dla powiązanego żądania API. Możesz odświeżyć token dostępu bez pytania użytkownika o pozwolenie (także wtedy, gdy użytkownika nie ma), jeśli zażądałeś dostępu w trybie offline do zakresów skojarzonych z tokenem.

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

Pola
client_id Identyfikator klienta uzyskany z API Console.
client_secret Sekret klienta uzyskany z API Console. ( client_secret nie ma zastosowania do żądań od klientów zarejestrowanych jako aplikacje na Androida, iOS lub Chrome).
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 autoryzacyjnego.

Poniższy fragment kodu przedstawia 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 odwoła dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON, który zawiera nowy token dostępu. Poniższy fragment kodu przedstawia przykładową odpowiedź:

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

Zwróć uwagę, że istnieją ograniczenia liczby tokenów odświeżania, które zostaną wydane; jeden limit na kombinację klienta / użytkownika i inny na użytkownika dla wszystkich klientów. Należy zapisać tokeny odświeżania w długoterminowym magazynie i nadal ich używać, dopóki pozostają ważne. Jeśli aplikacja zażąda zbyt wielu tokenów odświeżania, może napotkać te limity, w którym to przypadku starsze tokeny odświeżania przestaną działać.

Unieważnienie tokena

W niektórych przypadkach użytkownik może chcieć cofnąć dostęp przyznany aplikacji. Użytkownik może odwołać dostęp, odwiedzając Ustawienia konta . Aby uzyskać więcej informacji, zobacz sekcję Usuwanie dostępu do witryny lub aplikacji w Witrynach i aplikacjach innych firm z dostępem do Twojego konta .

Aplikacja może również programowo odwołać przyznany jej dostęp. Programmatic odwołanie jest ważne w przypadkach, gdy użytkownik rezygnuje z subskrypcji, usuwa aplikację lub zasoby API wymagane przez aplikację uległy znacznej zmianie. Innymi słowy, część procesu usuwania może obejmować żądanie API, aby upewnić się, że uprawnienia przyznane wcześniej aplikacji zostaną 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 odpowiedni token odświeżania, token odświeżania również zostanie unieważniony.

Jeśli odwołanie zostało pomyślnie przetworzone, kod stanu HTTP odpowiedzi to 200 . W przypadku błędów zwracany jest kod statusu HTTP 400 wraz z kodem błędu.

Dalsza lektura

IETF Best Current Practice OAuth 2.0 for Native Apps zawiera wiele z udokumentowanych tutaj najlepszych praktyk.