Ten dokument wyjaśnia, jak wdrożyć autoryzację dostępu OAuth 2.0 Interfejsy API Google z aplikacji internetowej w języku JavaScript. OAuth 2.0 pozwala użytkownikom udostępniać aplikacji określone dane, zachowując nazwy użytkowników, hasła i inne do prywatności danych. Na przykład aplikacja może używać protokołu OAuth 2.0, aby uzyskiwać uprawnienia na przechowywanie plików na Dysku Google przez użytkowników.
Ten przepływ protokołu OAuth 2.0 jest nazywany przepływem niejawnym. Przeznaczenie aplikacje uzyskujące dostęp do interfejsów API tylko wtedy, gdy użytkownik jest obecny w aplikacji. Te aplikacje nie mogą przechowywać informacji poufnych.
W ramach tego procesu aplikacja otwiera adres URL Google, który identyfikuje aplikację na podstawie parametrów zapytania oraz typ wymaganego dostępu do interfejsu API. Możesz otworzyć adres URL w bieżącej przeglądarce lub wyskakującym okienku. Użytkownik może uwierzytelnić się w Google i przyznać wymagane uprawnienia. Następnie Google przekierowuje użytkownika z powrotem do Twojej aplikacji. Przekierowanie zawiera token dostępu, który poddać ją weryfikacji, a potem używać jej do wysyłania żądań do interfejsu API.
Biblioteka klienta interfejsów API Google i usługi tożsamości Google
Jeśli używasz biblioteki klienta interfejsów API Google do obsługi JavaScriptu aby wykonywać autoryzowane połączenia do Google, należy używać Biblioteka JavaScript usług tożsamości Google do obsługi przepływu OAuth 2.0. Wejdź na stronę Google usług tożsamości token model, który jest na podstawie przepływu niejawnego uwierzytelnienia protokołu OAuth 2.0.
Wymagania wstępne
Włączanie interfejsów API w projekcie
Każda aplikacja, która wywołuje interfejsy API Google, musi je włączyć w funkcji API Console
Aby włączyć interfejs API w projekcie:
- Open the API Library w Google API Console
- If prompted, select a project, or create a new one.
- API Library zawiera listę wszystkich dostępnych interfejsów API pogrupowanych według usługi rodzina i popularność. Jeśli interfejsu API, który chcesz włączyć, nie ma na liście, użyj wyszukiwania, aby znajdź 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.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
Tworzenie danych uwierzytelniających
Każda aplikacja korzystająca z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google musi mieć dane uwierzytelniające które identyfikują aplikację na serwerze Google OAuth 2.0. Poniżej opisujemy, jak utworzysz dane logowania dla swojego projektu. Dzięki temu aplikacje mogą uzyskiwać dostęp do interfejsów API za pomocą danych logowania włączone w tym projekcie.
- Go to the Credentials page.
- Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
- Jako typ aplikacji wybierz Aplikacja internetowa.
- Wypełnij formularz. Aplikacje używające JavaScriptu do wysyłania autoryzowanych żądań do interfejsu API Google musi określać autoryzowane źródła JavaScript. Źródła identyfikują domeny za pomocą której aplikacja może wysyłać żądania do serwera OAuth 2.0. Te źródła muszą być zgodne z regułami weryfikacji Google.
Określanie zakresów dostępu
Zakresy umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów. co pozwala użytkownikom kontrolować zakres dostępu przyznawany do aplikacji. Dlatego też może być odwrotną zależnością między liczbą żądanych zakresów a prawdopodobieństwem w celu uzyskania zgody użytkownika.
Przed rozpoczęciem wdrażania autoryzacji OAuth 2.0 zalecamy określenie zakresów do których aplikacja potrzebuje uprawnień dostępu.
Dokument Zakresy interfejsu API OAuth 2.0 zawiera pełne listę zakresów, których możesz używać do uzyskiwania dostępu do interfejsów API Google.
Uzyskiwanie tokenów dostępu OAuth 2.0
Poniższe kroki pokazują, w jaki sposób Twoja aplikacja współpracuje z serwerem Google OAuth 2.0 w celu zgody użytkownika na wykonanie żądania do interfejsu API w jego imieniu. Aplikacja musi zawierać te uzyskać zgodę użytkownika przed wykonaniem żądania do interfejsu API Google, które wymaga autoryzacji użytkownika.
Krok 1. Przekieruj na serwer OAuth 2.0 Google
Aby poprosić o dostęp do danych użytkownika, przekieruj go do protokołu OAuth 2.0 Google serwera.
OAuth 2.0 Endpoints
Wygeneruj URL, aby poprosić o dostęp z punktu końcowego OAuth 2.0 Google na
https://accounts.google.com/o/oauth2/v2/auth
Ten punkt końcowy jest dostępny przez HTTPS.
zwykłe połączenia HTTP są odrzucane.
Serwer autoryzacji Google obsługuje w przypadku stron internetowych te parametry ciągu zapytania aplikacje serwerowe:
Parametry | |||||||
---|---|---|---|---|---|---|---|
client_id |
Wymagany
Identyfikator klienta aplikacji. Tę wartość znajdziesz w sekcji API Console Credentials page |
||||||
redirect_uri |
Wymagany
Określa, dokąd serwer interfejsu API przekierowuje użytkownika po wykonaniu przez użytkownika instrukcji
proces autoryzacji. Wartość musi być dokładnie zgodna z jednym z autoryzowanych identyfikatorów URI przekierowania dla
klienta OAuth 2.0 skonfigurowanego na
API Console
Credentials pageJeśli ta wartość nie pasuje do
autoryzowany identyfikator URI przekierowania dla podanego adresu Zwróć uwagę na schemat |
||||||
response_type |
Wymagany
Aplikacje JavaScript muszą ustawić wartość parametru na |
||||||
scope |
Wymagany
O rozdzielane spacjami lista zakresów identyfikujących zasoby, do których aplikacja może uzyskiwać dostęp w imieniu użytkownika. Wartości te informują o ekranie zgody, który Google wyświetla użytkownika. Zakresy umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów oraz prawdopodobieństwo uzyskania zgody użytkownika. Zalecamy, aby aplikacja żądała dostępu do zakresów autoryzacji w kontekście gdy tylko jest to możliwe. Prosząc o dostęp do danych użytkownika w kontekście, za pomocą: dodatkowej autoryzacji, ułatwiasz użytkownikom zrozumieć, dlaczego aplikacja potrzebuje dostępu, o który prosi. |
||||||
state |
Zalecane
Określa dowolną wartość ciągu, której aplikacja używa do utrzymywania stanu między
i odpowiedzi serwera autoryzacji.
Serwer zwraca dokładną wartość, która została wysłana jako para Tego parametru możesz używać do różnych celów, takich jak kierowanie użytkownika do parametru
prawidłowe zasoby w aplikacji, wysyłanie żądań jednorazowych i ograniczanie żądań z innych witryn
fałszerstwa. |
||||||
include_granted_scopes |
Opcjonalny
Umożliwia aplikacjom korzystanie z autoryzacji przyrostowej w celu proszenia o dostęp do dodatkowych
w kontekście. Jeśli ustawisz wartość tego parametru na |
||||||
enable_granular_consent |
Opcjonalny
Domyślna wartość to Gdy Google włączy szczegółowe uprawnienia aplikacji, ten parametr nie będzie nie wywierają żadnego wpływu. |
||||||
login_hint |
Opcjonalny
Jeśli aplikacja wie, który użytkownik próbuje się uwierzytelnić, może użyć tego parametru aby podać wskazówkę dla serwera uwierzytelniania Google. Serwer używa podpowiedzi do uprość proces logowania, wstępnie wypełniając pole adresu e-mail w formularzu wybór odpowiedniej sesji wielokrotnego logowania. Ustaw wartość parametru na adres e-mail lub identyfikator |
||||||
prompt |
Opcjonalny
Rozdzielona spacjami lista promptów, które mają zostać zaprezentowane użytkownikowi. Wielkość liter ma znaczenie. Jeśli nie chcesz określić ten parametr, użytkownik zostanie poproszony tylko przy pierwszym projekcie prosi o dostęp. Zobacz Ponowne wyrażenie zgody, aby uzyskać więcej informacji. Możliwe wartości to:
|
Przykładowe przekierowanie na serwer autoryzacji Google
Przykładowy adres URL podano poniżej ze znakami podziału wiersza i spacjami, aby zapewnić czytelność.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Po utworzeniu adresu URL żądania przekieruj na niego użytkownika.
Przykładowy kod JavaScript
Poniższy fragment kodu JavaScript pokazuje, jak rozpocząć proces autoryzacji JavaScript bez biblioteki klienta interfejsów API Google dla JavaScriptu. Ponieważ ten protokół OAuth Punkt końcowy 2.0 nie obsługuje współdzielenia zasobów między pochodzeniem (CORS), fragment kodu tworzy który otworzy żądanie do tego punktu końcowego.
/* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create <form> element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': 'YOUR_CLIENT_ID', 'redirect_uri': 'YOUR_REDIRECT_URI', 'response_type': 'token', 'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly', 'include_granted_scopes': 'true', 'state': 'pass-through value'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); }
Krok 2. Google prosi użytkownika o zgodę
Na tym etapie użytkownik decyduje, czy przyznać aplikacji żądany dostęp. W tym miejscu Google wyświetla okno z prośbą o zgodę, w którym wyświetla się nazwa aplikacji i interfejs API Google usług, do których żąda dostępu za pomocą danych uwierzytelniających użytkownika podsumowanie zakresów dostępu, jakie należy przyznać. użytkownik może wyrazić zgodę na przyznanie dostępu do co najmniej jednego zakresu żądanego przez aplikację lub odrzucić tę prośbę.
Na tym etapie aplikacja nie musi nic robić, ponieważ czeka na odpowiedź Serwer Google OAuth 2.0 wskazujący, czy przyznano dostęp. Odpowiedź ta została wyjaśniona tutaj: w następujący sposób.
Błędy
Żądania wysyłane do punktu końcowego autoryzacji OAuth 2.0 Google mogą wyświetlać komunikaty o błędach widoczne dla użytkowników zamiast oczekiwanych procesów uwierzytelniania i autoryzacji. Typowe i zalecane kody błędów rozwiązanie problemu znajdziesz poniżej.
admin_policy_enforced
Konto Google nie może autoryzować co najmniej jednego żądanego zakresu ze względu na zasady swoim administratorem Google Workspace. Przeczytaj artykuł pomocy dla administratorów Google Workspace Kontroluj, które zewnętrzne aplikacje wewnętrzne uzyskują dostęp do danych Google Workspace znajdziesz więcej informacji o tym, jak administrator może ograniczać dostęp do wszystkich zakresów lub zakresy z ograniczeniami, dopóki nie zostanie jednoznacznie przyznany dostępowi do identyfikatora klienta OAuth.
disallowed_useragent
Punkt końcowy autoryzacji jest wyświetlany w osadzonym kliencie użytkownika niedozwolonym przez Zasady dotyczące protokołu OAuth 2.0
Android
Deweloperzy aplikacji na Androida mogą napotkać ten komunikat o błędzie podczas otwierania żądań autoryzacji w
android.webkit.WebView
Deweloperzy powinni zamiast tego używać bibliotek Androida, takich jak
Logowanie przez Google na Androidzie lub OpenID Foundation
AppAuth na Androida.
Deweloperzy stron internetowych mogą napotkać ten błąd, gdy aplikacja na Androida otwiera ogólny link internetowy w osadzony klient użytkownika, a użytkownik przechodzi do punktu końcowego autoryzacji OAuth 2.0 Google w Twojej witrynie. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków systemu operacyjnego, który zawiera Linki aplikacji na Androida modułów obsługi lub domyślnej aplikacji do przeglądania internetu. Karty niestandardowe na Androida .
iOS
Deweloperzy systemów iOS i macOS mogą napotkać ten błąd podczas otwierania żądań autoryzacji w
WKWebView
Deweloperzy powinni zamiast tego używać bibliotek iOS, takich jak
Logowanie przez Google na iOS lub OpenID Foundation
AppAuth na iOS.
Deweloperzy stron internetowych mogą napotkać ten błąd, gdy aplikacja na iOS lub macOS otworzy ogólny link internetowy w
osadzony klient użytkownika, a użytkownik przechodzi do punktu końcowego autoryzacji OAuth 2.0 Google
w Twojej witrynie. Deweloperzy powinni zezwolić na otwieranie ogólnych linków w domyślnym module obsługi linków
systemu operacyjnego, który zawiera
Uniwersalne linki
modułów obsługi
lub domyślnej aplikacji do przeglądania internetu.
SFSafariViewController
.
org_internal
Identyfikator klienta OAuth w żądaniu jest częścią projektu ograniczającego dostęp do kont Google w konkretne Organizacja Google Cloud. Więcej informacji o tej opcji konfiguracji znajdziesz w Typ użytkownika w artykule pomocy „Konfigurowanie ekranu zgody OAuth”.
invalid_client
Źródło, z którego przesłano żądanie, nie jest autoryzowane w przypadku tego klienta. Zobacz
origin_mismatch
invalid_grant
W przypadku korzystania z autoryzacji przyrostowej token mógł wygasnąć. lub została unieważniona. Uwierzytelnij użytkownika ponownie i poproś o zgodę na uzyskanie nowych tokenów. Jeśli kontynuujesz w przypadku tego błędu. Upewnij się, że aplikacja została poprawnie skonfigurowana używając prawidłowych tokenów i parametrów w żądaniu. W przeciwnym razie konto użytkownika mogło mieć została usunięta lub wyłączona.
origin_mismatch
Schemat, domena i/lub port kodu JavaScript, z których pochodzi żądanie autoryzacji, mogą nie być zgodne z autoryzowanym identyfikatorem URI źródła JavaScript zarejestrowanym dla identyfikatora klienta OAuth. Sprawdź autoryzowane Źródła JavaScript w Google API Console Credentials page
redirect_uri_mismatch
redirect_uri
przekazany w żądaniu autoryzacji nie jest zgodny z autoryzowanym
URI przekierowania dla identyfikatora klienta OAuth. Przejrzyj autoryzowane identyfikatory URI przekierowania w
Google API Console Credentials page.
Schemat, domena i/lub port kodu JavaScript, z których pochodzi żądanie autoryzacji, mogą nie być zgodne z autoryzowanym identyfikatorem URI źródła JavaScript zarejestrowanym dla identyfikatora klienta OAuth. Sprawdź autoryzowane źródła JavaScript w Google API Console Credentials page.
Parametr redirect_uri
może odnosić się do zewnętrznego przepływu OAuth, w którym zastosowano
została wycofana i nie jest już obsługiwana. Zapoznaj się z
przewodnik po migracji, by zaktualizować
i integrację społeczną.
invalid_request
Coś poszło nie tak z Twoją prośbą. Możliwych jest kilka przyczyn tej sytuacji:
- Żądanie było nieprawidłowo sformatowane
- W żądaniu brakowało wymaganych parametrów
- Żądanie używa metody autoryzacji, której Google nie obsługuje. Zweryfikuj OAuth integracja korzysta z zalecanej metody integracji
Krok 3. Przetwórz odpowiedź serwera OAuth 2.0
OAuth 2.0 Endpoints
Serwer OAuth 2.0 wysyła odpowiedź do redirect_uri
określonego w
żądania tokena dostępu.
Jeśli użytkownik zatwierdzi żądanie, odpowiedź będzie zawierać token dostępu. Jeśli użytkownik nie zatwierdzi żądania, odpowiedź będzie zawierać komunikat o błędzie. Token dostępu we fragmencie z krzyżykiem identyfikatora URI przekierowania jest zwracany komunikat o błędzie, jak pokazano poniżej:
Odpowiedź tokena dostępu:
https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
Oprócz parametru
access_token
ciąg znaków z fragmentem zawiera parametrtoken_type
, który jest zawsze ustawiony naBearer
oraz parametruexpires_in
, który określa czas życia tokena w sekundach. Jeśli parametrstate
został określony w żądaniu tokena dostępu, jego wartość jest również uwzględniona w odpowiedzi.- Odpowiedź o błędzie:
https://oauth2.example.com/callback#error=access_denied
Przykładowa odpowiedź serwera OAuth 2.0
Możesz przetestować ten proces, klikając poniższy przykładowy adres URL, który dostęp tylko do odczytu z możliwością wyświetlania metadanych plików na Dysku Google:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Po zakończeniu procesu OAuth 2.0 przekierujemy Cię do strony
http://localhost/oauth2callback
Ten adres URL wygeneruje
404 NOT FOUND
błąd, chyba że na komputerze lokalnym wyświetli się plik pod adresem
pod tym adresem. W kolejnym kroku znajdziesz więcej informacji o informacjach zwracanych w
Identyfikator URI, gdy użytkownik jest przekierowywany z powrotem do aplikacji.
Wywoływanie interfejsów API Google
OAuth 2.0 Endpoints
Gdy aplikacja uzyska token dostępu, możesz go używać do wywoływania
API w imieniu danego
konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, dołącz
token dostępu w żądaniu wysyłanym do interfejsu API przez dodanie zapytania access_token
;
lub wartość nagłówka HTTP Authorization
Bearer
. Jeśli to możliwe,
preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. Najwięcej
można użyć biblioteki klienta do skonfigurowania wywołań interfejsów API Google (na przykład
wywołaniem interfejsu Drive Files API).
Wszystkie interfejsy API Google możesz wypróbować i przejrzeć ich zakresy na stronie OAuth 2.0 Playground.
Przykłady żądań HTTP GET
Wywołanie funkcji
drive.files
(interfejs Drive Files API) korzystający z protokołu HTTP Authorization: Bearer
nagłówek 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 za pomocą interfejsu access_token
parametr ciągu zapytania:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl
przykładu
Możesz je przetestować za pomocą aplikacji wiersza poleceń curl
. Oto
przykład wykorzystujący opcję nagłówka HTTP (preferowane):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Możesz też użyć opcji parametru ciągu zapytania:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Przykładowy kod JavaScript
Fragment kodu poniżej pokazuje, jak używać CORS (udostępniania zasobów między domenami) do wysyłania do interfejsu API Google. W tym przykładzie nie korzystamy z biblioteki klienta interfejsów API Google dla JavaScriptu. Nawet jeśli nie korzystasz z biblioteki klienta, pomocy CORS w dokumentacji tej biblioteki. do lepszego zrozumienia tych próśb.
W tym fragmencie kodu zmienna access_token
reprezentuje token,
uzyskane do wysyłania żądań do interfejsu API w imieniu autoryzowanego użytkownika. Kompletna
przykład pokazuje, jak zapisać token w pamięci lokalnej przeglądarki i go pobrać.
przy tworzeniu żądania do interfejsu API.
var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/drive/v3/about?fields=user&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null);
Pełny przykład
OAuth 2.0 Endpoints
Ten przykładowy kod pokazuje, jak wykonać przepływ OAuth 2.0 w JavaScripcie bez użycia Biblioteka klienta interfejsów API Google do obsługi JavaScriptu. Kod jest przeznaczony dla strony HTML, która wyświetla przycisk spróbuj wysłać żądanie do interfejsu API. Jeśli go klikniesz, kod sprawdzi, czy strona zapisała Token dostępu API w pamięci lokalnej przeglądarki. Jeśli tak, wykonuje żądanie do interfejsu API. W przeciwnym razie inicjuje przepływ OAuth 2.0.
W przypadku procesu OAuth 2.0 na stronie wykonaj te czynności:
- Kieruje użytkownika do serwera OAuth 2.0 Google, który żąda dostępu do
Zakres:
https://www.googleapis.com/auth/drive.metadata.readonly
. - Po przyznaniu (lub odmówieniu) dostępu do co najmniej 1 żądanego zakresu użytkownik jest przekierowywany do stronie oryginalnej, która analizuje token dostępu z ciągu znaków identyfikatora fragmentu.
Strona używa tokena dostępu do przykładowego żądania do interfejsu API.
Żądanie do interfejsu API wywołuje metodę
about.get
interfejsu Drive API, aby pobrać dane. informacje o koncie Dysku Google autoryzowanego użytkownika.- Jeśli żądanie się powiedzie, odpowiedź interfejsu API zostanie zarejestrowana w interfejsie debugowania przeglądarki konsoli.
Dostęp do aplikacji możesz cofnąć w na stronie Uprawnienia Konto Google. Aplikacja będzie widoczna jako Wersja demonstracyjna OAuth 2.0 w Dokumentach interfejsu Google API.
Aby uruchomić ten kod lokalnie, musisz ustawić wartości dla: YOUR_CLIENT_ID
i
YOUR_REDIRECT_URI
zmiennych, które odpowiadają
danych logowania. Zmienna YOUR_REDIRECT_URI
powinien zawierać ten sam adres URL, pod którym jest wyświetlana strona. Wartość musi dokładnie pasować do jednego ze
autoryzowane identyfikatory URI przekierowania dla klienta OAuth 2.0 skonfigurowane w
API Console Credentials page. Jeśli
ta wartość nie jest zgodna z autoryzowanym identyfikatorem URI, otrzymasz redirect_uri_mismatch
. Twój projekt musi też mieć
włączył odpowiedni interfejs API dla tego żądania.
<html><head></head><body> <script> var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE'; var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE'; // Parse query string to see if page request is coming from OAuth 2.0 server. var fragmentString = location.hash.substring(1); var params = {}; var regex = /([^&=]+)=([^&]*)/g, m; while (m = regex.exec(fragmentString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); } if (Object.keys(params).length > 0 && params['state']) { if (params['state'] == localStorage.getItem('state')) { localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); trySampleRequest(); } else { console.log('State mismatch. Possible CSRF attack'); } } // Function to generate a random state value function generateCryptoRandomState() { const randomValues = new Uint32Array(2); window.crypto.getRandomValues(randomValues); // Encode as UTF-8 const utf8Encoder = new TextEncoder(); const utf8Array = utf8Encoder.encode( String.fromCharCode.apply(null, randomValues) ); // Base64 encode the UTF-8 data return btoa(String.fromCharCode.apply(null, utf8Array)) .replace(/\+/g, '-') .replace(/\//g, '_') .replace(/=+$/, ''); } // If there's an access token, try an API request. // Otherwise, start OAuth 2.0 flow. function trySampleRequest() { var params = JSON.parse(localStorage.getItem('oauth2-test-params')); if (params && params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/drive/v3/about?fields=user&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { if (xhr.readyState === 4 && xhr.status === 200) { console.log(xhr.response); } else if (xhr.readyState === 4 && xhr.status === 401) { // Token invalid, so prompt for user permission. oauth2SignIn(); } }; xhr.send(null); } else { oauth2SignIn(); } } /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauth2SignIn() { // create random state value and store in local storage var state = generateCryptoRandomState(); localStorage.setItem('state', state); // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create element to open OAuth 2.0 endpoint in new window. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': YOUR_CLIENT_ID, 'redirect_uri': YOUR_REDIRECT_URI, 'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly', 'state': state, 'include_granted_scopes': 'true', 'response_type': 'token'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } </script> <button onclick="trySampleRequest();">Try sample request</button> </body></html>
Reguły weryfikacji źródła JavaScript
Google stosuje te reguły weryfikacji do źródeł JavaScript, aby ułatwić i programistom dbają o bezpieczeństwo swoich aplikacji. Źródła JavaScript muszą być zgodne z tymi regułami. W RFC 3986 (sekcja 3) znajdziesz definicji domeny, hosta i schematu.
Reguły weryfikacji | |
---|---|
Schemat |
Źródła JavaScript muszą używać schematu HTTPS, a nie zwykłego protokołu HTTP. Identyfikatory URI hosta lokalnego (w tym identyfikatory URI adresów IP lokalnego hosta) są zwolnione z tej reguły. |
Osoba prowadząca |
Hosty nie mogą być nieprzetworzonymi adresami IP. Adresy IP lokalnego hosta są wykluczone z tej reguły. |
Domena |
“googleusercontent.com” .goo.gl )
chyba że domena należy do aplikacji. |
Informacje o użytkowniku |
Źródła JavaScript nie mogą zawierać podkomponentu userinfo. |
Ścieżka |
Źródła JavaScript nie mogą zawierać komponentu ścieżki. |
Zapytanie |
Źródła JavaScript nie mogą zawierać komponentu zapytania. |
Fragment |
Źródła JavaScript nie mogą zawierać komponentu fragmentu. |
Znaki |
Źródło JavaScript nie może zawierać niektórych znaków, w tym:
|
Autoryzacja przyrostowa
W ramach protokołu OAuth 2.0 aplikacja żąda autoryzacji dostępu do zasobów, które są określonych przez zakresy. Wysyłanie prośby o autoryzację jest uważane za najlepszą metodę obsługi użytkownika. aby zawsze mieć dostęp do zasobów, gdy ich potrzebujesz. Aby to umożliwić, serwer autoryzacji Google obsługuje autoryzację przyrostową. Ta funkcja pozwala prosić o zakresy w razie potrzeby. jeśli użytkownik przyzna uprawnienia dla nowego zakresu, zwraca kod autoryzacji, który może być wymienionych na token zawierający wszystkie zakresy, które użytkownik przyznał projektowi.
Na przykład aplikacja, która umożliwia próbkowanie utworów i tworzenie składanek, może wymagać zasobów używanych podczas logowania, być może nie tylko imienia i nazwiska osoby, która się loguje. Pamiętaj jednak: zapisanie gotowej składanki wymagałoby dostępu do Dysku Google. Większość osób uzna to by było to jasne, jeśli użytkownik otrzymał prośbę o dostęp do Dysku Google tylko w momencie, gdy aplikacja było tego potrzebne.
W takim przypadku podczas logowania aplikacja może zażądać tych uprawnień: openid
oraz
profile
zakresów, aby wykonać podstawowe logowanie, a później zażądać
https://www.googleapis.com/auth/drive.file
zakres w momencie pierwszego żądania zapisania
składanka.
Te reguły mają zastosowanie do tokena dostępu uzyskanego z autoryzacji przyrostowej:
- Token może służyć do uzyskiwania dostępu do zasobów odpowiadających dowolnym zakresom uwzględnionym w nowa, połączona autoryzacja.
- Gdy użyjesz tokena odświeżania w ramach połączonej autoryzacji w celu uzyskania tokena dostępu,
token dostępu reprezentuje łączną autoryzację i może być używany do
Odpowiedź zawiera
scope
wartości. - Połączona autoryzacja obejmuje wszystkie zakresy, które użytkownik przyznał projektowi API, nawet jeśli , jeśli o granty poproszono różnych klientów. Jeśli na przykład użytkownik przyznał dostęp jeden zakres za pomocą klienta komputerowego aplikacji, a następnie przyznano inny zakres temu samemu za pomocą klienta mobilnego, połączona autoryzacja obejmowała oba zakresy.
- Unieważnienie tokena reprezentującego kombinację autoryzacji spowoduje, że uzyskasz dostęp do wszystkich zakresy autoryzacji w imieniu powiązanego użytkownika zostają anulowane jednocześnie.
Poniżej znajduje się przykładowy kod pokazujący, jak dodać zakresy do istniejącego tokena dostępu. Takie podejście pozwala w aplikacji, aby uniknąć konieczności zarządzania wieloma tokenami dostępu.
OAuth 2.0 Endpoints
Aby dodać zakresy do istniejącego tokena dostępu, dołącz include_granted_scopes
w żądaniu wysyłanym do serwera Google OAuth 2.0.
Fragment kodu poniżej pokazuje, jak to zrobić. Fragment zakłada, że zapisane dane
zakresy, dla których token dostępu jest prawidłowy w pamięci lokalnej przeglądarki. (Parametr
pełny przykład zawiera listę zakresów, dla których token dostępu
jest prawidłowe po ustawieniu właściwości oauth2-test-params.scope
w ustawieniach
storage.)
Fragment kodu porównuje zakresy, dla których token dostępu jest prawidłowy, z zakresem, którego chcesz użyć
dla konkretnego zapytania. Jeśli token dostępu nie obejmuje tego zakresu, rozpoczyna się przepływ OAuth 2.0.
W tym przypadku funkcja oauth2SignIn
jest taka sama jak funkcja podana w
kroku 2 (opisanego później w pełnym
przykład).
var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s < scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. }
Unieważnianie tokena
W niektórych przypadkach użytkownik może cofnąć dostęp przyznany aplikacji. Użytkownik może anulować dostęp odwiedzając stronę Ustawienia konta. Zobacz Usuń sekcji dostępu do witryny lub aplikacji na stronie Witryny innych firm aplikacje, które mają dostęp do Twojego konta dokumentu pomocy, aby dowiedzieć się więcej.
Aplikacja może też automatycznie anulować przyznany dostęp. Automatyczne unieważnienie jest ważne wtedy, gdy użytkownik anuluje subskrypcję, usuwa aplikacji lub zasoby API wymagane przez aplikację znacznie się zmieniły. Innymi słowy, może obejmować żądanie do interfejsu API mające na celu zapewnienie, że uprawnienia danych aplikacji są usuwane.
OAuth 2.0 Endpoints
Aby automatycznie unieważnić token, aplikacja wysyła żądanie do
https://oauth2.googleapis.com/revoke
i zawiera token jako parametr:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \ https://oauth2.googleapis.com/revoke?token={token}
Tokenem może być token dostępu lub token odświeżania. Jeśli token jest tokenem dostępu i ma parametr token odświeżania, token odświeżania również zostanie unieważniony.
Jeśli odwołanie zostanie przetworzone, kod stanu HTTP odpowiedzi będzie miał postać
200
W przypadku wystąpienia błędu zwracany jest kod stanu HTTP 400
.
z kodem błędu.
Poniższy fragment kodu JavaScript pokazuje, jak unieważnić token w JavaScript bez użycia
Biblioteka klienta interfejsów API Google do obsługi JavaScriptu. Ponieważ punkt końcowy OAuth 2.0 Google do unieważniania
tokeny nie obsługują współdzielenia zasobów między domenami (CORS), kod tworzy formularz i przesyła
do punktu końcowego, zamiast używać metody XMLHttpRequest()
do publikowania
użytkownika.
function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke'; // Create <form> element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is: // https://oauth2.googleapis.com/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); }