אם האפליקציה מטרגטת לסוג של משתמש חיצוני, מומלץ לטפל בקהל הרחב ביותר של חשבונות Google, כולל חשבונות Google שמנוהלים על ידי ארגון ב-Google Workspace.
אדמינים ב-Google Workspace יכולים להשתמש בבקרות גישה ל-API כדי להפעיל או להגביל את הגישה לממשקי ה-API של Google Workspace באפליקציות ובחשבונות שירות שבבעלות לקוחות או של צדדים שלישיים. התכונה הזו מאפשרת לאדמינים ב-Google Workspace להגביל את הגישה רק למזהי לקוחות ב-OAuth שנחשבים מהימנים על ידי הארגון, וכך מפחיתה את הסיכון לגישה של צד שלישי לשירותי Google.
כדי להגיע לקהל רחב ככל האפשר של חשבונות Google ולטפח אמון בקרב הלקוחות, מומלץ לבצע את הפעולות הבאות:
- שולחים את האפליקציה לאימות של Google. במקרים הרלוונטיים, צריך לשלוח את האפליקציה לאימות המותג, וגם לאימות בהיקפים רגישים ומוגבלים. אדמינים ב-Google Workspace יכולים לראות את הסטטוס המאומת של האפליקציה, והם עשויים לסמוך על אפליקציות ש-Google מאמתת יותר מאשר על אפליקציות בסטטוס לא מאומת או לא ידוע.
- האדמינים ב-Google Workspace יכולים לתת למזהי הלקוח ב-OAuth של האפליקציה גישה לשירותים מוגבלים ולהיקפי ההרשאות בסיכון גבוה. אם כוללים במסמכי העזרה את מזהה הלקוח ב-OAuth של האפליקציה, אפשר לספק לאדמינים ב-Google Workspace את המידע שנדרש כדי להעניק גישה לאפליקציה של האדמינים ב-Google Workspace, את המידע הדרוש להם כדי שהם יוכלו להבין אילו שינויים בהגדרות שלהם נחוצים כדי שהאפליקציה תוכל לגשת לנתוני הארגון.
- מומלץ לעקוב באופן סדיר אחר כתובת האימייל של תמיכת המשתמשים שסיפקת כשמגדירים את OAuth Consent Screen page. אדמינים ב-Google Workspace יכולים לראות את כתובת האימייל הזו כשהם בודקים את הרשאות הגישה לאפליקציה שלך, והם עשויים לפנות אליך אם יש לך שאלות או אם משהו לא ברור.
שיוך הפרויקט לארגון
אם אתם משתמשים ב-Google Workspace, מומלץ מאוד ליצור את פרויקט הפיתוח במשאב ארגוני בחשבון Google Workspace או בחשבון Cloud Identity. כך תוכלו להשתמש בתכונות לניהול הארגון, כמו התראות חשובות, בקרת גישה וניהול מחזור החיים של הפרויקט, בלי לקשר אותם לחשבון פיתוח ספציפי. אחרת, ייתכן שיהיה קשה (או בלתי אפשרי) להעביר לבעלים חדשים בעתיד.
כשמגדירים את פרויקט הפיתוח, צריך ליצור אותו בארגון או להעביר את הפרויקטים הקיימים לארגון.