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

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

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

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

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

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

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

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

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

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

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

• בודקים את היקפי ההרשאות שהאפליקציה משתמשת בהם או שרוצים להשתמש בהם. כדי לראות את השימוש הקיים בהיקף ההרשאות, בודקים את קוד המקור של האפליקציה כדי לראות אילו היקפי הרשאות נשלחים עם בקשות הרשאה.
• צריך לוודא שכל היקף הרשאה שנדרש נחוץ לפעולות המיועדות של תכונת האפליקציה, ושהאפליקציה משתמשת בהרשאות המינימליות שנדרשות כדי לספק את התכונה. לכל Google API יש בדרך כלל מסמכי עזר ב דף המפתחים של Google לגבי נקודות הקצה שלו, כולל היקף ההרשאות שנדרש כדי לקרוא לנקודת הקצה או למאפיינים ספציפיים בתוכה. מידע נוסף על היקפי ההרשאות הנדרשים לנקודות הקצה (endpoint) של ה-API שאליהן האפליקציה מתקשרת מופיע במסמכי העיון של נקודות הקצה האלה.
• השימוש בנתונים שמתקבלים מ-Google API חייב להתבצע בהתאם למדיניות של ה-API, ובאופן שמוצג למשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלה.
• מידע נוסף על כל היקף, כולל ה סטטוס הפוטנציאלי שלו, מופיע במאמרי העזרה של ה-API.
• מצהירים על כל ההיקפים שבהם נעשה שימוש באפליקציה בדף גישה לנתונים ב-Cloud Console. ההיקפים שאתם מציינים מקובצים לקטגוריות רגישות או מוגבלות כדי להדגיש אם נדרש אימות נוסף.
• כדאי למצוא את ההיקף הכי מתאים לנתונים שמשמשים את השילוב, להבין איך הוא משמש אתכם, לוודא שהכול עדיין פועל בסביבת בדיקה ולהתכונן לשליחה לאימות.

איור 1. דוגמה להיקף רגיש שמוצג בדף ההיקפים של הגדרת מסך ההסכמה ל-OAuth.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

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

6. לוחצים על הלחצן עריכת האפליקציה.
7. מזינים את המידע הנדרש בדף מסך הסכמה ל-OAuth ולוחצים על הלחצן שמירה והמשך.
8. משתמשים בלחצן הוספה או הסרה של היקפי הרשאה כדי להצהיר על כל היקפי ההרשאה שהאפליקציה מבקשת. קבוצה ראשונית של היקפי הרשאה שנדרשים לכניסה באמצעות חשבון Google מאוכלסת מראש בקטע היקפי הרשאה לא רגישים. היקפי הרשאה שנוספים מסווגים כלא רגישים, sensitive, or <a href="/identity/protocols/oauth2/production-readiness/restricted-scope-verification"

   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 שיכולים להעניק גישה לאפליקציה הלא מאומתת שלכם.

פרויקטים שמשמשים בשכבות Development, ‏ Testing או Staging (פיתוח, בדיקה או הכנה להשקה)

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

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

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

איור 2. מסך האזהרה לבודקים

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

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

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

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

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

• מידע נוסף על אפליקציות ציבוריות ופנימיות
• במאמר השאלות הנפוצות מוסבר איך לסמן את האפליקציה כפנימית איך אפשר לסמן את האפליקציה כפנימית בלבד?

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

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

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