כשמפתחים ומפעילים אפליקציות שמשתמשות ב-OAuth 2.0 של Google, חשוב להבין את המצבים השונים שבהם אפליקציה יכולה להיות ואת האינטראקציה בין המצבים האלה לבין אמצעי הבקרה של האדמין ב-Google Workspace. בדף הזה מופיעה סקירה כללית של סטטוסי הפרסום של אפליקציות OAuth, סוגי משתמשים ודרישות האימות.
זיהוי סוג האפליקציה
כדי להבין אילו מדיניות ואמצעי בקרה חלים על הפרויקט שלכם, קודם צריך לקבוע את קהל היעד:
- אפליקציות לשימוש בכל מקום: האפליקציות האלה מיועדות לקהל רחב ככל האפשר, כולל בעלי חשבונות Google ומשתמשים בארגונים חיצוניים של Google Workspace. הם מוגדרים כסוגי משתמשים חיצוניים במסוף Google Cloud. פרטים נוספים זמינים במאמר בנושא סוג משתמש: חיצוני.
- אפליקציות לשימוש רק בתוך ארגון Google Workspace: האפליקציות האלה הן פרטיות ומוגבלות למשתמשים בדומיין שלכם ב-Google Workspace. הם לא נגישים למשתמשים מחוץ לארגון. ההגדרות האלה מוגדרות כסוגי משתמשים פנימיים. האפליקציה והמשתמשים שלה כפופים למדיניות אדמיניסטרטיבית ברמת הארגון, שיכולה לבטל את התנהגות OAuth הרגילה. לפרטים נוספים, אפשר לעיין במאמר בנושא סוג משתמש: פנימי.
השוואה בין התנהגויות של פלטפורמות Google OAuth
בטבלה הבאה מפורטות ההשפעות של הגדרות שונות של סטטוס הפרסום, סוג המשתמש וסטטוס האימות על ההתנהגות והגישה של האפליקציה. ההתנהגויות האלה כפופות למדיניות האימות של OAuth ולכללים בנושא תפוגת אסימונים.
| סטטוס הפרסום | סוג המשתמש | האם רלוונטי למשתמשי בדיקה? | סטטוס אישור | הערות |
|---|---|---|---|---|
| לא רלוונטי | פנימי | לא | לא רלוונטי | כל המשתמשים בארגון יכולים לגשת. לא נדרש אימות. יכול להיות שהיקפי הגישה לא יופיעו במסך ההסכמה. האפשרות הזו שימושית לאפליקציות לשימוש פנימי בלבד. |
| בדיקה | חיצוני | כן | לא רלוונטי | רק משתמשים שנוספו באופן מפורש לרשימת ההיתרים של חשבונות למטרות בדיקה יכולים לגשת לאפליקציה (המספר מוגבל ל-100 חשבונות למטרות בדיקה). חריג: אם האפליקציה מבקשת רק הרשאות בסיסיות לזהות (openid, email, profile), כל משתמש יכול לגשת אליה בלי להיות ברשימת ההיתרים. המשתמשים רואים ממשק משתמש עם אזהרה שמציינת שהאפליקציה נמצאת בבדיקה, במקום המסך הרגיל של אפליקציה לא מאומתת. הערה: משתמשים בארגון לא פטורים מהדרישות האלה לבדיקה, אלא אם סוג המשתמש של האפליקציה מוגדר כפנימי. שימושי לפיתוח ולבדיקה. |
| פורסם | חיצוני | לא | לא מאומת | כל משתמש Google יכול לגשת. לא מומלץ בכלל. האפליקציה לא עברה אימות מותג, ולכן השם והלוגו שלה לא מוצגים במסך ההסכמה. בנוסף, באפליקציות שמבקשות היקפי הרשאות רגישים או מוגבלים, יוצגו למשתמשים אזהרות לגבי אפליקציות לא מאומתות (ממשק משתמש של סכנה), ויחול מכסה קשיחה של 100 משתמשים בסך הכול. |
| פורסם | חיצוני | לא | מאומת | כל משתמש Google יכול לגשת. נדרש עבור אפליקציות ציבוריות שמבקשות היקפי הרשאה רגישים ומוגבלים. השם, הלוגו וההיקפים של האפליקציה מוצגים במסך ההסכמה ללא אזהרות (אחרי אימות המותג וההיקפים). |
שינויים בהגדרות האדמין בסביבות Google Workspace
לאדמינים ב-Google Workspace יש שליטה משמעותית בגישה של אפליקציות OAuth לנתונים של הארגון, ללא קשר להגדרות האפליקציה במסוף Google Cloud. האמצעים האלה מנוהלים במסוף Admin של Google Workspace בקטע אמצעי בקרה של API.
- שליטה אוניברסלית: אדמינים ב-Google Workspace תמיד יכולים לחסום כל אפליקציית OAuth, בין אם היא פנימית או חיצונית, בבדיקה או בפרסום, מאומתת או לא מאומתת, ולמנוע מהמשתמשים שלהם לאשר אותה.
- אפליקציות פנימיות: לעיתים קרובות הן נחשבות מהימנות באופן מרומז בארגון Google Workspace, במיוחד אם האדמין מפעיל את האפשרות 'אפליקציות פנימיות או בבעלות הדומיין ייחשבו כבטוחות'. עם זאת, אדמינים עדיין יכולים להוסיף תוויות כמו 'מהימנה', 'מוגבלת' או 'חסומה' כדי לכוונן את הגישה. אפשר גם להגדיר הענקת גישה ברמת הדומיין (DWD) כדי לעקוף את הסכמת המשתמשים להיקפים ספציפיים.
- אפליקציות חיצוניות:
- לא מאומת: סביר להניח שאדמינים לא יסמכו על האפליקציות האלה, ויכול להיות שהם יחסמו או יגבילו אותן. אדמינים יכולים לסמן אפליקציה של צד שלישי לא מאומתת כ'מהימנה' בדומיין שלהם, אבל בדרך כלל לא מומלץ לעשות זאת.
- מאומת: האימות של Google מעורר אמון, אבל לאדמינים ב-Google Workspace עדיין יש שליטה מלאה. הסטטוס 'מאומת' לא מבטל את ההגדרות של האדמין ב-Google Workspace. אדמינים יכולים לסמן את האפליקציה כמהימנה (עוקפת חלק מהגבלות ההיקף שהוגדרו על ידי האדמין), מוגבלת (כפופה להגבלות השירות) או חסומה.
החלפת סטטוס ל'מהימן': כשמנהל/ת Google Workspace מסמנים אפליקציה כמהימנה, המערכת מתייחסת אליה כאפליקציה פנימית של הארגון. הסטטוס הזה מבטל מגבלות מסוימות של OAuth עבור משתמשי הארגון, כמו המגבלה של 100 משתמשי בדיקה והמגבלה של 7 ימים לתפוגה של אסימון רענון לאפליקציות בסטטוס בדיקה.
במילים אחרות, תהליך האימות של Google הוא אות לתאימות כללית למדיניות, אבל לאדמין של Google Workspace יש את הסמכות הסופית לקבוע אם אפליקציה יכולה לגשת לנתונים של הארגון.
השלבים הבאים
למידע מפורט יותר על הכנת האפליקציה לייצור ועל טיפול בשיקולים ספציפיים ל-Google Workspace, אפשר לעיין במקורות המידע הבאים: