Przegląd
16 lutego 2022 r. ogłosiliśmy, że korzystanie z bezpieczniejszych przepływów OAuth będzie bezpieczniejsze. Ten przewodnik pomoże Ci zrozumieć niezbędne zmiany i kroki, które trzeba wykonać, aby przeprowadzić migrację adresu IP pętli do obsługiwanych rozwiązań alternatywnych.
Ma to na celu ochronę przed atakami phishingowymi i podszywaniem się pod aplikacje podczas interakcji z punktami końcowymi Google OAuth 2.0.
Co to jest proces adresu IP typu sprzężenie zwrotne?
Przepływ adresów IP pętli pozwala użyć adresu IP typu pętli lublocalhost
jako elementu hosta identyfikatora URI przekierowania, na który są wysyłane dane logowania, gdy użytkownik zatwierdzi prośbę o zgodę OAuth. Ten przepływ jest podatny na ataki man in the middle, w wyniku których negatywna aplikacja uzyskująca dostęp do tego samego interfejsu zapętlenia w niektórych systemach operacyjnych może przechwycić odpowiedź z serwera autoryzacji do danego identyfikatora URI przekierowania i uzyskać dostęp do kodu autoryzacji.
Wycofujemy przepływ adresów IP typu pętli reklam w przypadku klientów natywnych aplikacji na iOS, Androida i Chrome OAuth, ale będą one nadal obsługiwane w aplikacjach na komputer.
Kluczowe daty zgodności
- 14 marca 2022 r. – w przypadku nowych klientów OAuth zablokowane będzie możliwość korzystania z adresu IP pętli Loopback.
- 1 sierpnia 2022 r. – ostrzeżenie o naruszeniu wytycznych dla użytkowników może być wyświetlane w przypadku niezgodnych żądań OAuth
- 31 sierpnia 2022 r. – przepływ adresów IP Loopback został zablokowany w przypadku natywnych klientów Androida, aplikacji Chrome i klientów OAuth na iOS utworzonych przed 14 marca 2022 r.
- 21 października 2022 r. – dostęp do wszystkich obecnych klientów (w tym wykluczonych) będzie zablokowany. Klienci mogą poprosić o jednorazowe udostępnienie rozszerzenia do korzystania z adresu IP pętli pętli do 21 października 2022 r., zgodnie z instrukcjami wysłanymi w e-mailach do klientów, których dotyczy ten problem.
Miesiąc przed wysłaniem prośby o zgodę na wykorzystanie danych może być wyświetlany komunikat dla użytkowników niespełniających wymagań. Oznacza to, że 1 sierpnia 2022 roku przepływ adresów IP Loopback został całkowicie wycofany. Komunikat informuje użytkowników, że aplikacja może zostać wkrótce zablokowana, wyświetlając adres e-mail pomocy zarejestrowany przez Ciebie na ekranie zgody OAuth w konsoli Google API.
Możesz zaakceptować komunikat ostrzegawczy wyświetlany użytkownikom i pominąć go, przekazując parametr zapytania w wywołaniu autoryzacji, jak pokazano poniżej.- Przejdź do kodu w aplikacji, w którym są wysyłane żądania punktu końcowego autoryzacji OAuth 2.0 Google.
-
Dodaj parametr
ack_loopback_shutdown
z wartością daty egzekwowania: 31.08.2022 do żądania przekierowania. Przykład:ack_loopback_shutdown=2022-08-31
- Sprawdź, czy zmiana Cię dotyczy.
- Jeśli zmiana Cię nie dotyczy, przejdź na obsługiwaną wersję alternatywną.
Sprawdź, czy problem Cię dotyczy
Sprawdź typ identyfikatora klienta OAuth
Przejdź do Credentials page Google API Console i wyświetl identyfikator klienta OAuth w sekcji Identyfikatory klienta OAuth 2.0. Możesz wybrać jedną z tych opcji: Aplikacja internetowa, Android, iOS, Universal Windows Platform (UWP), Aplikacja Chrome, Telewizory i urządzenia z ograniczonym dostępem, Aplikacja komputerowa.
Jeśli korzystasz z urządzenia z Androidem, aplikacji Chrome lub iOS oraz używasz przepływu adresów IP typu pętli, możesz przejść do następnego kroku.
Jeśli korzystasz z adresu IP typu pętli pakietów w przypadku klienta OAuth dla aplikacji komputerowych, nie musisz nic robić, ponieważ ten typ klienta OAuth będzie nadal obsługiwany.
Jak sprawdzić, czy aplikacja używa adresu IP typu pętli pętli
Sprawdź kod aplikacji lub wychodzące połączenie sieciowe (na wypadek, gdyby aplikacja korzystała z biblioteki OAuth) w celu określenia, czy żądanie autoryzacji Google OAuth wykorzystuje wartości identyfikatorów URI przekierowania pętli pętli.
Sprawdzanie kodu aplikacji
redirect_uri
ma dowolną z tych wartości:-
redirect_uri=http://127.0.0.1:<port>
, np.redirect_uri=http://127.0.0.1:3000
-
redirect_uri=http://[::1]:<port>
, np.redirect_uri=http://[::1]:3000
-
redirect_uri=http://localhost:<port>
, np.redirect_uri=http://localhost:3000
https://accounts.google.com/o/oauth2/v2/auth? redirect_uri=http://localhost:3000& response_type=code& scope=<SCOPES>& state=<STATE>& client_id=<CLIENT_ID>
Sprawdź wychodzące połączenie sieciowe
- Aplikacja internetowa – sprawdź aktywność w sieci
- Android – sprawdź ruch w sieci za pomocą inspektora sieci
-
Aplikacje Chrome
- Otwórz stronę Rozszerzenia do Chrome.
- Zaznacz pole wyboru Tryb programisty w prawym górnym rogu strony rozszerzenia.
- Wybierz rozszerzenie, które chcesz monitorować
- W sekcji Sprawdź widoki danych kliknij link Strona w tle na stronie rozszerzenia.
- Otworzy się wyskakujące okienko Narzędzi dla programistów, na którym możesz monitorować ruch sieciowy na karcie Sieć.
- iOS – Analizowanie ruchu HTTP za pomocą instrumentów
- Universal Windows Platform (UWP) – sprawdź ruch sieciowy w Visual Studio.
- Aplikacje na komputer – użyj narzędzia do przechwytywania sieci dostępnego w systemie operacyjnym, na którym została utworzona aplikacja
redirect_uri
ma dowolną z tych wartości:-
redirect_uri=http://127.0.0.1:<port>
, np.redirect_uri=http://127.0.0.1:3000
-
redirect_uri=http://[::1]:<port>
, np.redirect_uri=http://[::1]:3000
-
redirect_uri=http://localhost:<port>
, np.redirect_uri=http://localhost:3000
https://accounts.google.com/o/oauth2/v2/auth? redirect_uri=http://localhost:3000& response_type=code& scope=<SCOPES>& state=<STATE>& client_id=<CLIENT_ID>
Migracja do obsługiwanej alternatywy
Klienty mobilne (Android / iOS)
Jeśli okaże się, że Twoja aplikacja korzysta z pętla adresów IP z typem klienta OAuth na Androida lub iOS, przejdź na pakiet SDK do logowania jednokrotnego na urządzeniach z Androidem (Android, iOS).
Pakiet SDK ułatwia dostęp do interfejsów API Google i obsługuje wszystkie wywołania punktów końcowych autoryzacji OAuth 2.0 firmy Google.
Poniższe linki do dokumentacji zawierają informacje o tym, jak używać pakietów SDK logowania Google, aby uzyskiwać dostęp do interfejsów API Google, bez używania identyfikatora URI przekierowania adresu IP.
Uzyskiwanie dostępu do interfejsów API Google na urządzeniach z Androidem
Dostęp po stronie serwera (offline)
Poniższy przykład pokazuje, jak uzyskać dostęp do interfejsów API Google po stronie serwera w Androidzie.Task<GoogleSignInAccount> task = GoogleSignIn.getSignedInAccountFromIntent(data); try { GoogleSignInAccount account = task.getResult(ApiException.class); // request a one-time authorization code that your server exchanges for an // access token and sometimes refresh token String authCode = account.getServerAuthCode(); // Show signed-in UI updateUI(account); // TODO(developer): send code to server and exchange for access/refresh/ID tokens } catch (ApiException e) { Log.w(TAG, "Sign-in failed", e); updateUI(null); }
Zapoznaj się z przewodnikiem po dostępie po stronie serwera, aby dowiedzieć się, jak uzyskać dostęp do interfejsów API Google po stronie serwera.
Dostęp do interfejsów API Google w aplikacji na iOS
Dostęp po stronie klienta
Poniższy przykład pokazuje, jak uzyskać dostęp do interfejsów API Google po stronie klienta w systemie iOS.
user.authentication.do { authentication, error in guard error == nil else { return } guard let authentication = authentication else { return } // Get the access token to attach it to a REST or gRPC request. let accessToken = authentication.accessToken // Or, get an object that conforms to GTMFetcherAuthorizationProtocol for // use with GTMAppAuth and the Google APIs client library. let authorizer = authentication.fetcherAuthorizer() }
Użyj tokena dostępu do wywoływania interfejsu API, dodając token dostępu w nagłówku żądania REST lub gRPC (Authorization: Bearer ACCESS_TOKEN
) albo korzystając z narzędzia do pobierania (GTMFetcherAuthorizationProtocol
) z biblioteką klienta interfejsów API Google dla REST.
Zapoznaj się z przewodnikiem po dostępie po stronie klienta, aby dowiedzieć się, jak uzyskać dostęp do interfejsów API Google po stronie klienta. jak uzyskać dostęp do interfejsów API Google po stronie klienta.
Dostęp po stronie serwera (offline)
Poniższy przykład pokazuje, jak uzyskać dostęp do interfejsów API Google po stronie serwera, aby obsługiwać klienta iOS.GIDSignIn.sharedInstance.signIn(with: signInConfig, presenting: self) { user, error in guard error == nil else { return } guard let user = user else { return } // request a one-time authorization code that your server exchanges for // an access token and refresh token let authCode = user.serverAuthCode }
Zapoznaj się z przewodnikiem po dostępie po stronie serwera, aby dowiedzieć się, jak uzyskać dostęp do interfejsów API Google po stronie serwera.
Klient aplikacji Chrome
Jeśli okaże się, że aplikacja używa w kliencie aplikacji Chrome przepływu adresu IP typu pętli, musisz skorzystać z interfejsu Chrome Identity API.
Poniższy przykład pokazuje, jak pobrać wszystkie kontakty użytkownika bez użycia identyfikatora URI przekierowania adresu IP.
window.onload = function() { document.querySelector('button').addEventListener('click', function() { // retrieve access token chrome.identity.getAuthToken({interactive: true}, function(token) { // .......... // the example below shows how to use a retrieved access token with an appropriate scope // to call the Google People API contactGroups.get endpoint fetch( 'https://people.googleapis.com/v1/contactGroups/all?maxMembers=20&key=API_KEY', init) .then((response) => response.json()) .then(function(data) { console.log(data) }); }); }); };
Więcej informacji o uzyskiwaniu dostępu do uwierzytelniania użytkowników i wywoływaniu punktów końcowych Google przy użyciu interfejsu Chrome Identity API znajdziesz w przewodniku po interfejsie Chrome Identity API.