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