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

Opis

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

To zabezpieczenie przed atakami phishingowymi i atakami polegającymi na podszywaniu się pod inne aplikacje podczas interakcji z punktami końcowymi autoryzacji OAuth 2.0 Google.

Co to jest przepływ adresu IP sprzężenia zwrotnego?

Przepływ adresu IP w pętli umożliwia użycie adresu IP typu loopback lub localhost jako komponentu hosta identyfikatora URI przekierowania, na który wysył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 podstępna aplikacja korzystająca z tego samego interfejsu loopback w niektórych systemach operacyjnych może przechwycić odpowiedź 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 zgodności

  • 14 marca 2022 r. – nowi klienci OAuth zablokowali możliwość korzystania z przepływu adresów IP sprzężenia zwrotnego
  • 1 sierpnia 2022 r. – w przypadku niezgodnych żądań OAuth może pojawić 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, Chrome oraz iOS utworzonych przed 14 marca 2022 r.
  • 21 października 2022 r. – wszyscy istniejący klienci są blokowani (w tym klienci zwolnieni)

W przypadku niezgodnych żądań wyświetlany jest komunikat o błędzie. Użytkownicy zobaczą komunikat o zablokowaniu aplikacji wraz z adresem e-mail zespołu pomocy zarejestrowanym na ekranie zgody OAuth w konsoli interfejsów API Google.

Aby przejść przez proces migracji, musisz wykonać 2 główne kroki:
  1. Określ, czy ten problem Cię dotyczy.
  2. W razie potrzeby przejdź na obsługiwaną wersję alternatywną.

Określ, czy ten problem Cię dotyczy

Sprawdzanie typu 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ć jeden z tych elementów: Aplikacja internetowa, Android, iOS, Uniwersalna platforma Windows (UWP), Aplikacja Chrome, Telewizory i urządzenia z ograniczonymi wejściami, Aplikacja komputerowa.

Przejdź do następnego kroku, jeśli typ klienta to Android, aplikacja Chrome lub iOS i używasz przepływu adresu IP w pętli.

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

Jak sprawdzić, czy aplikacja korzysta z przepływu adresu IP typu loopback

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

Sprawdzanie kodu aplikacji

Przejrzyj sekcję kodu aplikacji, w której wywołujesz punkty końcowe autoryzacji Google OAuth, i sprawdź, 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 loopback 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>

Sprawdź wychodzące połączenia sieciowe

Metoda sprawdzania wywołań sieciowych różni się w zależności od typu klienta aplikacji.
Podczas sprawdzania wywołań sieciowych poszukaj żądań wysyłanych do punktów końcowych autoryzacji Google OAuth i ustal, 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 loopback 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 użyciem typu klienta OAuth na Androida lub iOS, przejdź na mobilne pakiety 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.

Linki do dokumentacji poniżej zawierają informacje o tym, jak korzystać z pakietów SDK Google Sign-In do uzyskiwania dostępu do interfejsów API Google bez używania 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 urządzeniu z Androidem.
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()
}

Do wywoływania interfejsu API użyj tokena dostępu. Aby to zrobić, umieść token dostępu w nagłówku żądania REST lub gRPC (Authorization: Bearer ACCESS_TOKEN) albo użyj narzędzia autoryzacyjnego pobierania (GTMFetcherAuthorizationProtocol) z biblioteką klienta interfejsów API Google na potrzeby interfejsu Objective-C w środowisku REST.

Zapoznaj się z przewodnikiem po dostępie po stronie klienta, by dowiedzieć się, jak uzyskać dostęp 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 aplikacja korzysta z przepływu adresów IP w pętli w kliencie aplikacji Chrome, przejdź na interfejs Chrome Identity API.

Poniższy przykład pokazuje, jak uzyskać wszystkie kontakty użytkownika bez korzystania z identyfikatora URI przekierowania adresu IP w pętli.

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.