Przewodnik po migracji adresów IP w pętli

Opis

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 mającymi na celu wyłudzenie informacji lub przejęcie tożsamości podczas interakcji z punktami końcowymi autoryzacji OAuth 2.0 w Google.

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 lub localhost 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.

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 wysyłasz żądania do 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_oob_shutdown=2022-08-31
Aby przeprowadzić proces migracji, musisz wykonać 2 czynności:
  1. Sprawdź, czy zmiana Cię dotyczy.
  2. 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

Przejrzyj sekcję kodu aplikacji, w której wykonujesz wywołania punktów końcowych autoryzacji Google OAuth, i określ, czy parametr 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
Przykładowe żądanie przepływu adresów IP przekierowania wygląda tak jak poniżej:
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

Metoda sprawdzania połączeń sieciowych różni się w zależności od typu klienta aplikacji.
Podczas sprawdzania połączeń sieciowych poszukaj żądań wysłanych do punktów końcowych autoryzacji Google OAuth i określ, czy parametr 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
Przykładowy przepływ przepływu w pętli adresu IP wygląda tak:
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 OAuth 2.0 protokołu OAuth 2.0.

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.