מידע על אימות והרשאה

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

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

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

סקירה כללית על התהליך

בתרשים הבא מוצגים השלבים הכלליים של האימות וההרשאות לממשקי ה-API של Google Workspace:

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

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

  3. בקשת משאבים: כשהאפליקציה צריכה גישה למשאבים של Google, היא מבקשת מ-Google להשתמש בהיקפי הגישה הרלוונטיים שרשמתם בעבר.

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

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

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

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

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

  9. בקשה למשאבים נוספים: אם נדרשת הרשאת גישה נוספת, האפליקציה תבקש מהמשתמש להעניק היקפי גישה חדשים, וכתוצאה מכך תישלח בקשה חדשה לקבלת אסימון גישה (שלבים 3 עד 6).

מונחים חשובים

לפניך רשימת מונחים הקשורים לאימות והרשאה:

אימות

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

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

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

פרטי כניסה

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

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

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

שרת הרשאות

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

קוד הרשאה

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

אסימון גישה

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

שרת משאבים

השרת שמארח את ה-API שהאפליקציה שלכם רוצה לקרוא.

מסגרת OAuth 2.0

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

חשבון משתמש

ישות שאפשר לקבל ממנה גישה למשאב. ממשקי Google Workspace API תומכים בשני סוגים של חשבונות: חשבונות משתמשים וחשבונות שירות. לפרטים נוספים קראו את המאמר Principals.

סוג הנתונים

בהקשר של אימות והרשאה, סוג הנתונים מתייחס לישות שבבעלותה הנתונים שהאפליקציה מנסה לגשת אליהם. יש שלושה סוגי נתונים:

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

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

סוג האפליקציה

סוג האפליקציה שאתם מתכוונים ליצור. כשיוצרים פרטי כניסה באמצעות מסוף Google Cloud, צריך לבחור את סוג האפליקציה. סוגי האפליקציות הם: אפליקציית אינטרנט (JavaScript), Android, אפליקציית Chrome, iOS, טלוויזיות ומכשירי קלט מוגבלים, אפליקציה למחשב (נקראת גם 'אפליקציה מותקנת') ו-Universal Windows Platform (UWP).

חשבון שירות

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

הענקת סמכויות ברמת הדומיין

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

השלב הבא

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