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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם יש לקוחות OAuth שלא מוכנים לייצור, מומלץ למחוק אותם מ: הפרויקט שמבקש את האימות. אפשר לעשות זאת Google API Console

כדי לשלוח בקשה לאימות:

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

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

   https://console.developers.google.com/apis/credentials/consent?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. אם הגדרת האפליקציה שסיפקת מחייבת אימות, יש לך אפשרות לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל תהליך האימות.

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

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

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

שימוש אישי

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

פרויקטים שמשמשים לפיתוח, לבדיקה או ל-Staging רמות

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

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

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

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

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

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

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

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

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

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

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