מדריך להעברת כתובת IP מסוג הלולאה החוזרת (loopback)

סקירה כללית

ב-16 בפברואר 2022, הודענו על התוכניות שלנו להפוך את האינטראקציות של Google OAuth לבטוחות יותר באמצעות תהליכי OAuth מאובטחים יותר. המדריך הזה יעזור לכם להבין את השינויים והשלבים הנדרשים כדי לבצע מעבר מוצלח מכתובת ה-IP של ה-loopback לחלופות נתמכות.

המאמץ הזה הוא אמצעי הגנה מפני פישינג ומתקפות התחזות לאפליקציות במהלך אינטראקציות עם נקודות הקצה של Google למתן הרשאות OAuth 2.0.

מהו התהליך של כתובת IP מסוג הלולאה החוזרת (loop)?

תהליך ההרשאה באמצעות כתובת IP של ממשק לולאה חוזרת תומך בשימוש בכתובת IP של ממשק לולאה חוזרת או ב-localhost כרכיב המארח של ה-URI להפניה אוטומטית, שאליו נשלחים פרטי הכניסה אחרי שהמשתמש מאשר בקשת הסכמה של OAuth. התהליך הזה חשוף להתקפות מסוג Man-in-the-middle, שבהן אפליקציה זדונית, שמקבלת גישה לאותו ממשק של לולאת חזרה במערכות הפעלה מסוימות, עשויה ליירט את התגובה משרת ההרשאות ל-URI של ההפניה האוטומטית שצוין ולקבל גישה לקוד ההרשאה.

תהליך כתובת ה-IP של הלולאה החוזרת (loopback) יוצא משימוש בסוגי לקוחות ה-OAuth של אפליקציות נייטיב ל-iOS, ל-Android ול-Chrome, אבל הוא ימשיך להיות נתמך באפליקציות למחשב.

תאריכים חשובים שקשורים לתאימות

  • 14 במרץ 2022 – לקוחות OAuth חדשים נחסמים משימוש בתהליך של כתובת ה-IP של Loopback
  • 1 באוגוסט 2022 – יכול להיות שתוצג למשתמשים הודעת אזהרה לגבי בקשות OAuth שלא עומדות בדרישות
  • 31 באוגוסט 2022 – חסימת התהליך של כתובת ה-IP של הלולאה החוזרת (loopback) ללקוחות OAuth מקוריים של Android, אפליקציות Chrome ו-iOS שנוצרו לפני 14 במרץ 2022
  • ‫21 באוקטובר 2022 – כל הלקוחות הקיימים נחסמים (כולל לקוחות שקיבלו פטור)

לגבי בקשות שלא עומדות בדרישות, תוצג הודעת שגיאה למשתמשים. ההודעה תציין למשתמשים שהאפליקציה חסומה, ותציג את כתובת האימייל לתמיכה שרשמתם במסך ההסכמה ל-OAuth ב-Google API Console.

יש שני שלבים עיקריים שצריך לבצע כדי להשלים את תהליך ההעברה:
  1. בודקים אם אתם מושפעים מהשינוי.
  2. אם אתם מושפעים מהשינוי הזה, אתם צריכים לעבור לחלופה נתמכת.

איך יודעים אם השינוי משפיע עליכם

בדיקת סוג מזהה הלקוח ב-OAuth

עוברים אל הדף Clients (לקוחות) ב-מסוף Google Cloud ומציגים את סוג מזהה הלקוח ב-OAuth בקטע OAuth 2.0 Client IDs (מזהי לקוח ב-OAuth 2.0). הערך יהיה אחד מהבאים: אפליקציית אינטרנט, ‏ Android, ‏ iOS,‏ Universal Windows Platform (UWP), ‏ אפליקציות Chrome, ‏ TVs & Limited Input devices,‏ אפליקציה למחשב.

אם סוג הלקוח שלכם הוא Android, אפליקציית Chrome או iOS ואתם משתמשים בתהליך של כתובת ה-IP של הלולאה החוזרת, אתם יכולים להמשיך לשלב הבא.

אם אתם משתמשים בתהליך של כתובת IP מסוג loopback בלקוח OAuth של אפליקציה למחשב, לא צריך לעשות שום דבר בנוגע להוצאה משימוש הזו, כי השימוש בסוג הזה של לקוח OAuth ימשיך להיות נתמך.

איך בודקים אם האפליקציה משתמשת בתהליך של כתובת IP מסוג Loopback

בודקים את קוד האפליקציה או את הבקשה היוצאת לרשת (אם האפליקציה משתמשת בספריית OAuth) כדי לראות אם בקשת ההרשאה של Google OAuth שהאפליקציה שולחת משתמשת בערכי URI של הפניה חוזרת מסוג loopback.

בדיקת קוד האפליקציה

בודקים את הקטע בקוד האפליקציה שבו מתבצעות קריאות ל נקודות הקצה של ההרשאה של Google OAuth. בודקים אם הפרמטר redirect_uri מכיל אחד מהערכים הבאים:
  • redirect_uri=http://127.0.0.1:<port> למשל: redirect_uri=http://127.0.0.1:3000
  • redirect_uri=http://[::1]:<port> למשל: redirect_uri=http://[::1]:3000
  • redirect_uri=http://localhost:<port> למשל: redirect_uri=http://localhost:3000
בקשה לדוגמה של הפניה אוטומטית של כתובת IP מסוג loopback תיראה כמו הבקשה שמופיעה בהמשך:
https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

בדיקת שיחה יוצאת ברשת

השיטה לבדיקת קריאות לרשת משתנה בהתאם לסוג הלקוח של האפליקציה.
במהלך בדיקת קריאות הרשת, מחפשים בקשות שנשלחות אל נקודות הקצה של ההרשאה של Google OAuth וקובעים אם הפרמטר redirect_uri מכיל אחד מהערכים הבאים:
  • redirect_uri=http://127.0.0.1:<port> למשל: redirect_uri=http://127.0.0.1:3000
  • redirect_uri=http://[::1]:<port> למשל: redirect_uri=http://[::1]:3000
  • redirect_uri=http://localhost:<port> למשל: redirect_uri=http://localhost:3000
בקשה לדוגמה של הפניה אוטומטית של כתובת IP מסוג Loopback תיראה כמו הבקשה הבאה:
https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

מעבר לחלופה נתמכת

לקוחות לנייד (Android / iOS)

אם קבעתם שהאפליקציה שלכם משתמשת בתהליך של כתובת IP של Loopback עם סוג לקוח OAuth של Android או iOS, אתם צריכים לעבור לשימוש בערכות ה-SDK המומלצות (Android,‏ iOS).

ערכת ה-SDK מאפשרת גישה קלה ל-Google APIs ומטפלת בכל הקריאות לנקודות הקצה של הרשאות OAuth 2.0 של Google.

בקישורים למסמכי התיעוד שבהמשך מוסבר איך להשתמש בערכות ה-SDK המומלצות כדי לגשת לממשקי Google API בלי להשתמש בכתובת IP של לולאת חזרה או בכתובת URI להפניה אוטומטית.

גישה אל Google APIs ב-Android

גישה מצד הלקוח

בדוגמה הבאה מוסבר איך לגשת ל-Google APIs בצד הלקוח ב-Android באמצעות ספריית Google Identity Services Android המומלצת.

  List 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));

מעבירים את authorizationResult לשיטה שהגדרתם כדי לשמור את התוכן בתיקיית Drive של המשתמש. ל-authorizationResult יש את ה-method‏ getAccessToken() שמחזיר את טוקן הגישה.

גישה בצד השרת (אופליין)
בדוגמה הבאה מוצגות דרכים לגשת לממשקי Google API בצד השרת ב-Android.
  List 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 יש את ה-method‏ getServerAuthCode() שמחזירה את קוד ההרשאה שאפשר לשלוח לשרת העורפי כדי לקבל אסימון גישה ואסימון רענון.

גישה אל Google APIs באפליקציית iOS

גישה מצד הלקוח

בדוגמה הבאה אפשר לראות איך ניגשים ל-Google APIs בצד הלקוח ב-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()
}

משתמשים באסימון הגישה כדי לקרוא ל-API. אפשר לכלול את אסימון הגישה בכותרת של בקשת REST או gRPC ‏ (Authorization: Bearer ACCESS_TOKEN), או להשתמש במאשר האחזור (GTMFetcherAuthorizationProtocol) עם ספריית הלקוח של Google APIs ל-Objective-C ל-REST.

במאמר גישה בצד הלקוח מוסבר איך לגשת ל-Google APIs בצד הלקוח. איך לגשת ל-Google APIs בצד הלקוח.

גישה בצד השרת (אופליין)
בדוגמה הבאה אפשר לראות איך ניגשים ל-Google APIs בצד השרת כדי לתמוך בלקוח 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
}

במדריך בנושא גישה מצד השרת מוסבר איך לגשת לממשקי Google API מצד השרת.

לקוח: אפליקציית Chrome

אם תגלו שהאפליקציה שלכם משתמשת בתהליך של כתובת ה-IP של הלולאה החוזרת (loopback) בלקוח של אפליקציית Chrome, תצטרכו לעבור לשימוש ב- Chrome Identity API.

בדוגמה שלמטה אפשר לראות איך מקבלים את כל אנשי הקשר של המשתמש בלי להשתמש בכתובת IP של לולאה חוזרת לניתוב URI.

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)
    });
   });
 });
};

ב מדריך ל-Chrome Identity API יש מידע נוסף על גישה למשתמשים מאומתים ועל קריאה לנקודות קצה (endpoints) של Google באמצעות Chrome Identity API.