אימות של היקף רגיש

אם האפליקציה שלכם מבקשת הרשאה להשתמש ב-Google APIs כדי לגשת לנתונים של משתמשי Google, יכול להיות שתצטרכו להשלים תהליך אימות לפני שתהפכו את האפליקציה לזמינה לכולם בפעם הראשונה.

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

  1. סוג נתוני המשתמש שיש לכם גישה אליהם – פרטי פרופיל ציבוריים, רשומות ביומן, קבצים ב-Drive, נתוני בריאות וכושר מסוימים וכו'.
  2. רמת הגישה הנדרשת – קריאה בלבד, קריאה וכתיבה וכו'.

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

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

עליכם לבקש היקפי הרשאות עם רמת הגישה הנמוכה ביותר לנתוני המשתמשים הנדרשים כדי לספק את הפונקציונליות הזו. לדוגמה, אפליקציה שקוראת נתונים בלבד לא יכולה לבקש גישה לקריאה, לכתיבה ולמחיקה של תוכן כשיש היקף צר יותר ל-API ולנקודות הקצה הקשורות שלו. אסור להשתמש בנתונים שאתם מקבלים מ-Google API אלא בהתאם למדיניות של ה-API ובאופן שבו אתם מייצגים אותם למשתמשים שלכם בפעולות של האפליקציה ובמדיניות הפרטיות שלכם.

חשוב להביא בחשבון את הזמן הנדרש להשלמת האימות בתוכנית ההשקה של האפליקציה או של תכונות חדשות שדורשות היקף חדש. תהליך האימות של היקף המידע הרגיש נמשך בדרך כלל 3 עד 5 ימי עסקים. לתשומת ליבך: יכול להיות שהאפליקציה שלך עומדת בדרישות להשלמת אימות המותג כקבוצת משנה של בקשת האימות שלך לשימוש במידע אישי רגיש.

הסבר על היקפים רגישים

היקפים רגישים נדרשים לבדיקה על ידי Google לפני שחשבון Google יכול להעניק גישה אליהם. אדמינים ארגוניים ב-Google Workspace יכולים להגביל את הגישה להיקפים רגישים כדי למנוע גישה באמצעות מזהי לקוח של OAuth שהארגון לא סימן במפורש כמהימנים.

הסבר על השימוש בהיקף

  • בודקים את ההיקפים שבהם האפליקציה משתמשת או שבהם רוצים להשתמש. כדי לבדוק את השימוש הקיים בהיקפים, צריך לבדוק את קוד המקור של האפליקציה כדי למצוא היקפים שנשלחו עם בקשות הרשאה.
  • צריך לקבוע שכל היקף הרשאה מבוקש נדרש לפעולות המיועדות של תכונת האפליקציה, ולהשתמש בהרשאות המינימליות הנדרשות כדי לספק את התכונה. בדרך כלל, לממשקי Google API יש מסמכי עזרה לגבי נקודות הקצה שלהם ב דף המפתחים של המוצר ב-Google, שכוללים את ההיקף הנדרש כדי לבצע קריאה לנקודת הקצה או לנכסים ספציפיים בתוכה. למידע נוסף על היקפי הגישה הנדרשים לנקודות הקצה של ה-API שהאפליקציה שלכם קוראת אליהן, תוכלו לעיין במסמכי העזרה של נקודות הקצה האלה.
  • אסור להשתמש בנתונים שאתם מקבלים מ-Google API אלא בהתאם למדיניות של ה-API ובאופן שבו אתם מייצגים אותם למשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלכם.
  • במסמכי העזרה של ה-API מפורט מידע נוסף על כל היקף, כולל הסטטוס האפשרי שלו sensitive or restricted .
  • מגדירים את כל ההיקפים שבהם האפליקציה משתמשת ב של . ההיקפים שציינתם מקובצים בקטגוריות של מידע רגיש או מוגבל, כדי להדגיש את דרישות האימות הנוספות הנדרשות.
  • עליכם למצוא את ההיקף המתאים ביותר שמתאים לנתונים שבהם נעשה שימוש בשילוב, להבין את השימוש בו, לוודא שוב שכל מה שצריך עדיין פועל בסביבת הבדיקה ולאחר מכן להתכונן לשליחת הבקשה לאימות.
בטבלה מוצגים השם של ממשק API, אחד מההיקפים הרגישים שלו ותיאור של ההיקף.
איור 1. דוגמה להיקף רגיש שמוצג בדף ההגדרות של היקפי ההרשאות של מסך ההסכמה ל-OAuth.

שלבים להכנה לאימות

כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים צריכות לבצע את השלבים הבאים כדי להשלים את תהליך אימות המותג:

  1. מוודאים שהאפליקציה לא נכללת באף אחד מהתרחישים לדוגמה שמפורטים בקטע חריגים לדרישות האימות.
  2. מוודאים שהאפליקציה עומדת בדרישות המיתוג של המוצר או ממשקי ה-API המשויכים. לדוגמה, הנחיות למיתוג של היקפי הרשאה לכניסה באמצעות חשבון Google.
  3. מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. משתמשים בחשבון Google שמשויך לפרויקט בתור בעלים או עורך.
  4. חשוב לוודא שכל פרטי המיתוג במסך ההסכמה ל-OAuth, כמו שם האפליקציה, כתובת האימייל של התמיכה, ה-URI של דף הבית, ה-URI של מדיניות הפרטיות וכו', משקפים בצורה מדויקת את הזהות של האפליקציה.

הדרישות לגבי דף הבית של האפליקציה

חשוב לוודא שדף הבית עומד בדרישות הבאות:

  • דף הבית חייב להיות נגיש לכולם, ולא רק למשתמשים באתר שנכנסו לחשבון.
  • הרלוונטיות של דף הבית לאפליקציה שנמצאת בבדיקה צריכה להיות ברורה.
  • קישורים לדף האפליקציה בחנות Google Play או לדף שלה ב-Facebook לא נחשבים לדפי בית חוקיים של האפליקציה.

הדרישות לגבי קישור למדיניות הפרטיות של האפליקציה

צריך לוודא שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:

  • מדיניות הפרטיות חייבת להיות גלויה למשתמשים, להתארח באותו דומיין שבו מתארח דף הבית של האפליקציה, ולכלול קישור למסך ההסכמה של OAuth ב- . לתשומת ליבכם: דף הבית חייב לכלול תיאור של הפונקציונליות של האפליקציה, וכן קישורים למדיניות הפרטיות ולתנאים וההגבלות האופציונליים.
  • במדיניות הפרטיות צריך לפרט את האופן שבו האפליקציה ניגשת לנתוני המשתמשים ב-Google, משתמשת בהם, מאחסנת אותם או משתפת אותם. עליכם להגביל את השימוש בנתוני המשתמשים של Google לשיטות שמפורטות במדיניות הפרטיות שפורסמה.

איך שולחים את האפליקציה לאימות

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

אם אחד מלקוחות ה-OAuth שלכם עדיין לא מוכן לסביבת הייצור, מומלץ למחוק אותו מהפרויקט שבו מוגשת הבקשה לאימות. אפשר לעשות זאת ב .

כדי לשלוח את הבקשה לאימות, פועלים לפי השלבים הבאים:

  1. מוודאים שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs והמדיניות של Google בנושא נתוני משתמשים בשירותי API.
  2. חשוב לוודא שהתפקידים 'בעלים' ו'עריכה' בחשבונות המשויכים לפרויקט מעודכנים, וגם את כתובת האימייל של תמיכת המשתמשים במסך ההסכמה של OAuth ואת הפרטים ליצירת קשר עם המפתחים ב- . כך תוכלו לוודא שחברי הצוות המתאימים יקבלו התראה על דרישות חדשות.
  3. עוברים אל OAuth .
  4. לוחצים על הלחצן Project selector.

  5. בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים מהו מזהה הפרויקט, תוכלו ליצור כתובת URL בדפדפן בפורמט הבא:

    ?project=[PROJECT_ID]

    מחליפים את [PROJECT_ID] במזהה הפרויקט שבו רוצים להשתמש.

  6. לוחצים על הלחצן עריכת האפליקציה.
  7. מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth, ואז לוחצים על הלחצן שמירה והמשך.
  8. לוחצים על הלחצן Add or remove scopes (הוספה או הסרה של היקפים) כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. קבוצה ראשונית של היקפים שנדרשים לכניסה באמצעות חשבון Google מולאו מראש בקטע Non-sensitive scopes (היקפים לא רגישים). היקפים שנוספו מסווגים כ'לא רגישים', sensitive, or restricted.
  9. יש לספק עד שלושה קישורים למסמכי תיעוד רלוונטיים לגבי תכונות קשורות באפליקציה.

  10. בשלבים הבאים, עליכם לספק את כל המידע הנוסף שנדרש לגבי האפליקציה.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
  11. אם הגדרות האפליקציה שסיפקתם מחייבות אימות, תוכלו לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל את תהליך האימות.

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

חריגים לדרישות האימות

אם האפליקציה שלכם תשמש באחד מהתרחישים שמפורטים בקטעים הבאים, לא צריך לשלוח אותה לבדיקה.

שימוש אישי

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

פרויקטים שמשמשים בשכבות הפיתוח, הבדיקה או ההרצה

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

אם האפליקציה נמצאת בשלב הפיתוח או הבדיקה, אפשר להשאיר את סטטוס הפרסום בברירת המחדל בדיקה. ההגדרה הזו מציינת שהאפליקציה עדיין בפיתוח והיא זמינה רק למשתמשים שתוסיפו לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמעורבים בפיתוח או בבדיקה של האפליקציה.

הודעת אזהרה על כך ש-Google לא אימתה אפליקציה שנמצאת בבדיקה.
איור 2. מסך האזהרה לבודקים

נתונים בבעלות השירות בלבד

אם האפליקציה משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ולא לגשת לנתוני משתמשים (מקושרים לחשבון Google), אין צורך לשלוח אותה לאימות.

במאמר חשבונות שירות במסמכי העזרה של Google Cloud מוסבר מהם חשבונות שירות. להוראות לשימוש בחשבון שירות, ראו שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת.

לשימוש פנימי בלבד

כלומר, רק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity יכולים להשתמש באפליקציה. הפרויקט צריך להיות בבעלות הארגון, וצריך להגדיר את מסך ההסכמה של OAuth לסוג משתמש פנימי. במקרה כזה, יכול להיות שתצטרכו אישור מאדמין בארגון. למידע נוסף, ראו שיקולים נוספים לגבי Google Workspace.

התקנה ברמת הדומיין

אם אתם מתכננים שתהיה לאפליקציה שלכם טירגוט רק למשתמשים בארגון של Google Workspace או Cloud Identity, ותמיד תשתמשו בהתקנה ברמת הדומיין, לא תצטרכו לאמת את האפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת לאדמין הדומיין להעניק לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתונים של המשתמשים. רק חשבונות של אדמינים בארגון יכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.

במאמר השאלות הנפוצות באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace מוסבר איך להגדיר את האפליקציה כהתקנה ברמת הדומיין.