Ta strona została przetłumaczona przez Cloud Translation API.

Przewodnik migracji przepływu adresu IP sprzężenia zwrotnego

Przegląd

16 lutego 2022 r. ogłosiliśmy, że planujemy zwiększyć bezpieczeństwo interakcji Google OAuth przy użyciu bezpieczniejszych przepływów OAuth. Ten przewodnik ułatwia zrozumienie niezbędnych zmian i kroków niezbędnych do przeprowadzenia migracji z przepływu adresów IP w pętli do obsługiwanych alternatywnych rozwiązań.

To środek ochronny przed atakami phishingowymi i podszywaniem się pod inne aplikacje podczas interakcji z punktami końcowymi autoryzacji OAuth 2.0 Google.

Na czym polega przepływ adresu IP sprzężenia zwrotnego?

Przepływ adresu IP w trybie sprzężenia zwrotnego obsługuje użycie adresu IP w trybie loopback lub localhost jako komponentu hosta w identyfikatorze URI przekierowania, do którego przesyłane są dane uwierzytelniające po zatwierdzeniu prośby o zgodę OAuth przez użytkownika. Ten przepływ jest podatny na ataki man in the middle, w których szkodliwa aplikacja korzystająca z tego samego interfejsu loopback w niektórych systemach operacyjnych może przechwycić odpowiedź z serwera autoryzacji na podany identyfikator URI przekierowania i uzyskać dostęp do kodu autoryzacji.

Proces zapętlenia adresów IP jest wycofywany w przypadku natywnych klientów OAuth na iOS, Androida i Chrome, ale nadal będzie obsługiwany w aplikacjach komputerowych.

Najważniejsze daty zapewnienia zgodności z zasadami

14 marca 2022 r. – zablokowano możliwość korzystania z adresu IP sprzężenia zwrotnego nowym klientom OAuth
1 sierpnia 2022 r. – w przypadku niezgodnych żądań OAuth może wyświetlić się komunikat ostrzegawczy dla użytkowników
31 sierpnia 2022 r. – przepływ adresu IP sprzężenia zwrotnego jest zablokowany w natywnych klientach OAuth na Androida, aplikacji Chrome oraz na iOS utworzonych przed 14 marca 2022 r.
21 października 2022 r. – wszyscy istniejący klienci są zablokowani (w tym klienci zwolnieni)

W przypadku niezgodnych żądań wyświetlany jest komunikat o błędzie. Wiadomość będzie informować użytkowników o zablokowaniu aplikacji i wyświetlić adres e-mail do zespołu pomocy zarejestrowany na ekranie zgody OAuth w Konsoli interfejsów API Google.

Aby przejść przez proces migracji, musisz wykonać 2 główne kroki:

Sprawdź, czy ten problem Cię dotyczy.
Jeśli Cię to dotyczy, przejdź na obsługiwaną opcję alternatywną.

Określ, czy ten problem Cię dotyczy

Sprawdź typ identyfikatora klienta OAuth

Otwórz Credentials page Google API Console i wyświetl typ identyfikatora klienta OAuth w sekcji Identyfikatory klienta OAuth 2.0. Może to być jedna z tych wartości: Aplikacja internetowa, Android, iOS, Uniwersalna platforma Windows (UWP), Aplikacja Chrome, Telewizory i urządzenia z ograniczonym dostępem, Aplikacja komputerowa.

Przejdź do następnego kroku, jeśli Twój typ klienta to Android, aplikacja Chrome lub iOS i używasz przepływu adresów IP w trybie loopback.

Jeśli korzystasz z procesu zapętlenia adresów IP w kliencie OAuth aplikacji na komputery, nie musisz nic robić w związku z wycofaniem, ponieważ korzystanie z tego typu klienta OAuth będzie nadal obsługiwane.

Jak sprawdzić, czy aplikacja korzysta z przepływu adresów IP w sieci typu loopback

Sprawdź kod aplikacji lub wychodzące wywołanie sieciowe (jeśli aplikacja korzysta z biblioteki OAuth), aby ustalić, czy żądanie autoryzacji Google OAuth przesyłana przez Twoją aplikację korzysta z wartości identyfikatora URI przekierowania typu loopback.

Sprawdzanie kodu aplikacji

Sprawdź sekcję kodu aplikacji, w której wywołujesz punkty końcowe autoryzacji Google OAuth, i określ, czy parametr redirect_uri ma którąś 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 adresu IP w trybie sprzężenia zwrotnego 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>

Uwaga: sprawdź też pliki konfiguracyjne aplikacji (takie jak pliki .env), ponieważ wartości redirect_uri zwykle się różnią w zależności od środowiska, w którym działa aplikacja.

Sprawdź wychodzące połączenie sieciowe

Metoda badania wywołań sieciowych różni się w zależności od typu klienta aplikacji.

Aplikacja internetowa – sprawdzaj aktywność w sieci w Chrome
Android – sprawdź ruch w sieci za pomocą inspektora sieci
Aplikacje Chrome
- Otwórz stronę rozszerzeń do Chrome.
- Zaznacz pole wyboru Tryb programisty w prawym górnym rogu strony rozszerzenia.
- Wybierz rozszerzenie, które chcesz monitorować
- Kliknij link strona w tle w sekcji Sprawdź widoki na stronie rozszerzenia.
- Pojawi się wyskakujące okienko Narzędzia dla programistów, w którym możesz monitorować ruch w sieci na karcie Sieć.
iOS – analizowanie ruchu HTTP przy użyciu Instruments
Universal Windows Platform (UWP) – sprawdzaj ruch sieciowy w Visual Studio
Aplikacje komputerowe – użyj narzędzia do przechwytywania ruchu sieciowego dostępnego w systemie operacyjnym, na który została opracowana aplikacja.

Podczas badania wywołań sieciowych szukaj żądań wysyłanych do punktów końcowych autoryzacji Google OAuth i określaj, czy parametr redirect_uri ma którąś 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 przekierowania adresu IP w trybie sprzężenia zwrotnego będzie wyglądać 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>

Migracja do obsługiwanej opcji alternatywnej

Klienty mobilne (Android / iOS)

Jeśli stwierdzisz, że Twoja aplikacja korzysta z przepływu adresów IP w pętli z klientem OAuth na Androida lub iOS, przeprowadź migrację do mobilnych pakietów SDK logowania przez Google (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 Google.

Poniższe linki do dokumentacji zawierają informacje o tym, jak korzystać z pakietów Google Sign-In SDK do uzyskiwania dostępu do interfejsów API Google bez korzystania z identyfikatora URI przekierowania adresu IP typu loopback.

Dostęp do interfejsów API Google na Androidzie

Dostęp po stronie serwera (offline)

Przykład poniżej pokazuje, jak uzyskać dostęp do interfejsów API Google po stronie serwera na 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

Przykład poniżej 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, aby wywołać interfejs API. Aby to zrobić, umieść token dostępu w nagłówku żądania REST lub gRPC (Authorization: Bearer ACCESS_TOKEN) albo za pomocą narzędzia do pobierania (GTMFetcherAuthorizationProtocol) z biblioteką klienta interfejsów API Google dla interfejsu Objective-C w REST.

Zapoznaj się z przewodnikiem dostępu po stronie klienta, aby dowiedzieć się, jak uzyskać dostęp do interfejsów API Google po stronie klienta. uzyskiwania dostępu do interfejsów API Google po stronie klienta.

Dostęp po stronie serwera (offline)

Przykład poniżej pokazuje, jak uzyskać dostęp do interfejsów API Google po stronie serwera w celu obsługi klienta na 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 stwierdzisz, że Twoja aplikacja korzysta z przepływu adresów IP w pętli w kliencie aplikacji Chrome, przeprowadź migrację do interfejsu Chrome Identity API.

Poniższy przykład pokazuje, jak pobrać wszystkie kontakty użytkownika bez korzystania z identyfikatora URI przekierowania adresu IP w trybie loopback.

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 za pomocą interfejsu Chrome Identity API znajdziesz w przewodniku po interfejsie Chrome Identity API.