Guide de migration du flux d'adresses IP de rebouclage

Présentation

Le 16 février 2022, nous avons annoncé notre intention de renforcer la sécurité des interactions Google OAuth en utilisant des flux OAuth plus sécurisés. Ce guide vous explique les changements nécessaires et la marche à suivre pour passer du flux d'adresse IP de bouclage à des alternatives compatibles.

Cette mesure vise à protéger les utilisateurs contre les attaques par hameçonnage et usurpation d'identité d'applications lors des interactions avec les points de terminaison d'autorisation OAuth 2.0 de Google.

Qu'est-ce que le flux d'adresse IP de rebouclage ?

Le flux d'adresse IP de bouclage permet d'utiliser une adresse IP de bouclage ou localhost comme composant hôte de l'URI de redirection vers lequel les identifiants sont envoyés après qu'un utilisateur a approuvé une demande de consentement OAuth. Ce flux est vulnérable aux attaques de type man in the middle, dans lesquelles une application malveillante, accédant à la même interface de bouclage sur certains systèmes d'exploitation, peut intercepter la réponse du serveur d'autorisation à l'URI de redirection donné et accéder au code d'autorisation.

Le flux d'adresse IP de rebouclage est en cours d'abandon pour les types d'applications OAuth iOS, Android et Chrome, mais il continuera d'être accepté sur les applications de bureau.

Dates clés de conformité

  • 14 mars 2022 : les nouveaux clients OAuth ne peuvent plus utiliser le flux d'adresse IP de bouclage.
  • 1er août 2022 : un message d'avertissement visible par l'utilisateur peut s'afficher pour les requêtes OAuth non conformes.
  • 31 août 2022 : le flux d'adresse IP de rebouclage est bloqué pour les clients OAuth Android, Applications Chrome et iOS créés avant le 14 mars 2022.
  • 21 octobre 2022 : tous les clients existants sont bloqués (y compris les clients exemptés).

Un message d'erreur visible par l'utilisateur s'affiche pour les requêtes non conformes. Le message indiquera aux utilisateurs que l'application est bloquée, tout en affichant l'adresse e-mail d'assistance que vous avez enregistrée sur l'écran de consentement OAuth dans la console Google Cloud.

La migration se déroule en deux étapes principales :

  1. Déterminez si vous êtes concerné.
  2. Si vous êtes concerné, migrez vers une alternative compatible.

Déterminer si vous êtes concerné

Vérifier le type de votre application OAuth

Accédez à la page Clients de la console Google Cloud et affichez le type de votre application OAuth dans la section ID client OAuth 2.0. Il s'agit de l'un des types suivants : Application Web, Android, iOS, Plate-forme Windows universelle (UWP), Application Chrome, Téléviseurs et appareils à saisie limitée, Application de bureau.

Passez à l'étape suivante si votre type d'application est Android, Applications Chrome ou iOS, et que vous utilisez le flux d'adresse IP de rebouclage.

Vous n'avez rien à faire concernant l'abandon si vous utilisez le flux d'adresse IP de bouclage sur un client OAuth d'application de bureau, car l'utilisation de ce type d'application OAuth continuera d'être acceptée.

Déterminer si votre application utilise le flux d'adresse IP de bouclage

Inspectez le code de votre application ou l'appel réseau sortant (si votre application utilise une bibliothèque OAuth) pour déterminer si la demande d'autorisation Google OAuth effectuée par votre application utilise des valeurs d'URI de redirection de bouclage.

Inspecter le code de votre application

Examinez la section du code de votre application où vous effectuez des appels aux points de terminaison d'autorisation Google OAuth et déterminez si le paramètre redirect_uri comporte l'une des valeurs suivantes :

  • redirect_uri=http://127.0.0.1:<port> (par exemple, redirect_uri=http://127.0.0.1:3000)
  • redirect_uri=http://[::1]:<port> (par exemple, redirect_uri=http://[::1]:3000)
  • redirect_uri=http://localhost:<port> (par exemple, redirect_uri=http://localhost:3000)

Voici un exemple de requête de flux de redirection d'adresse IP de bouclage :

https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

Inspecter un appel réseau sortant

La méthode d'inspection des appels réseau varie en fonction du type d'application.

Lorsque vous inspectez les appels réseau, recherchez les requêtes envoyées aux points de terminaison d'autorisation Google OAuth et déterminez si le paramètre redirect_uri comporte l'une des valeurs suivantes :

  • redirect_uri=http://127.0.0.1:<port> (par exemple, redirect_uri=http://127.0.0.1:3000)
  • redirect_uri=http://[::1]:<port> (par exemple, redirect_uri=http://[::1]:3000)
  • redirect_uri=http://localhost:<port> (par exemple, redirect_uri=http://localhost:3000)

Voici un exemple de requête de flux de redirection d'adresse IP de bouclage :

https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

Migrer vers une alternative compatible

Clients mobiles (Android et iOS)

Si vous déterminez que votre application utilise le flux d'adresse IP de bouclage avec un type d'application OAuth Android ou iOS, vous devez migrer vers les SDK recommandés (Android, iOS).

Le SDK vous aide à accéder aux API Google et gère tous les appels aux points de terminaison d'autorisation OAuth 2.0 de Google.

Les liens vers la documentation suivants expliquent comment utiliser les SDK recommandés pour accéder aux API Google sans utiliser d'URI de redirection d'adresse IP de bouclage.

Accéder aux API Google sur Android

Accès côté client

L'exemple suivant montre comment accéder aux API Google côté client sur Android à l'aide de la bibliothèque Android Google Identity Services recommandée.

List<Scopes> requestedScopes = Arrays.asList(DriveScopes.DRIVE_APPDATA);
AuthorizationRequest authorizationRequest =
    AuthorizationRequest.builder()
        .setRequestedScopes(requestedScopes)
        .build();
Identity.getAuthorizationClient(activity)
    .authorize(authorizationRequest)
    .addOnSuccessListener(
        authorizationResult -> {
          if (authorizationResult.hasResolution()) {
            // Access needs to be granted by the user
            PendingIntent pendingIntent =
                authorizationResult.getPendingIntent();
            try {
              startIntentSenderForResult(
                  pendingIntent.getIntentSender(),
                  REQUEST_AUTHORIZE, null, 0, 0, 0, null);
            } catch (IntentSender.SendIntentException e) {
              Log.e(
                  TAG,
                  "Couldn't start Authorization UI: "
                      + e.getLocalizedMessage());
            }
          } else {
            // Access already granted, continue with user action
            saveToDriveAppFolder(authorizationResult);
          }
        })
    .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize", e));

Transmettez authorizationResult à la méthode définie pour enregistrer le contenu dans le dossier Drive de l'utilisateur. authorizationResult dispose de la méthode getAccessToken() qui renvoie le jeton d'accès.

Accès côté serveur (hors connexion)

L'exemple suivant montre comment accéder aux API Google côté serveur sur Android.

List<Scopes> requestedScopes = Arrays.asList(DriveScopes.DRIVE_APPDATA);
AuthorizationRequest authorizationRequest =
    AuthorizationRequest.builder()
        .requestOfflineAccess(webClientId)
        .setRequestedScopes(requestedScopes)
        .build();
Identity.getAuthorizationClient(activity)
    .authorize(authorizationRequest)
    .addOnSuccessListener(
        authorizationResult -> {
          if (authorizationResult.hasResolution()) {
            // Access needs to be granted by the user
            PendingIntent pendingIntent =
                authorizationResult.getPendingIntent();
            try {
              startIntentSenderForResult(
                  pendingIntent.getIntentSender(),
                  REQUEST_AUTHORIZE, null, 0, 0, 0, null);
            } catch (IntentSender.SendIntentException e) {
              Log.e(
                  TAG,
                  "Couldn't start Authorization UI: "
                      + e.getLocalizedMessage());
            }
          } else {
            String authCode =
                authorizationResult.getServerAuthCode();
          }
        })
    .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize", e));

authorizationResult dispose de la méthode getServerAuthCode() qui renvoie le code d'autorisation que vous pouvez envoyer à votre backend pour obtenir un jeton d'accès et un jeton d'actualisation.

Accéder aux API Google dans une application iOS

Accès côté client

L'exemple suivant montre comment accéder aux API Google côté client sur 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()
}

Utilisez le jeton d'accès pour appeler l'API, soit en l'incluant dans l'en-tête d'une requête REST ou gRPC (Authorization: Bearer <var>ACCESS_TOKEN</var>), soit en utilisant l'outil d'autorisation de récupération (GTMFetcherAuthorizationProtocol) avec la bibliothèque cliente des API Google pour Objective-C pour REST.

Consultez le guide d'accès côté client pour savoir comment accéder aux API Google côté client.

Accès côté serveur (hors connexion)

L'exemple suivant montre comment accéder aux API Google côté serveur pour prendre en charge un client 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
}

Consultez le guide d'accès côté serveur pour savoir comment accéder aux API Google côté serveur.

Client Application Chrome

Si vous déterminez que votre application utilise le flux d'adresse IP de bouclage sur le client de l'application Chrome, vous devez migrer vers l'API Chrome Identity.

L'exemple suivant montre comment obtenir tous les contacts d'un utilisateur sans utiliser d'URI de redirection d'adresse IP de bouclage.

window.onload = function() {
  document.querySelector('button').addEventListener('click', function() {

  
  // retrieve access token
  chrome.identity.getAuthToken({interactive: true}, function(token) {
  
  // ..........


  // the following example 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)
    });
   });
 });
};

Pour en savoir plus sur l'authentification des utilisateurs et l'appel de points de terminaison Google avec l'API Chrome Identity, consultez le guide de l'API Chrome Identity.