אימות לקוח OAuth

פרויקטים של Apps Script שמבקשים היקפי הרשאות רגישים של OAuth.

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

לא נדרש אימות לפרויקטים של Google Apps Script שהבעלים והמשתמשים שלהם שייכים לאותו דומיין או לאותו לקוח של Google Workspace.

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

למידע נוסף, ראה הסעיפים הבאים:

 

מסך האזהרה לגבי אפליקציה לא מאומתת.
איור 1: מסך של אפליקציה לא מאומתת
קובץ GIF מונפש שמציג את תהליך ההרשאה של אפליקציה לא מאומתת.
איור 2: תהליך ההרשאה של אפליקציה לא מאומתת

 

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

אפליקציות לא מאומתות

יכול להיות שיהיה צורך באימות של תוספים ל-Google Workspace, אפליקציות אינטרנט ופריסות אחרות (כמו אפליקציות שמשתמשות ב-Apps Script API).

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

הישימות

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

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

הלקוח מאומת המוציא לאור הוא חשבון Google Workspace של לקוח א' הסקריפט נמצא באחסון שיתופי של לקוח א' החשבון של אתר החדשות הוא חשבון Gmail
המשתמש הוא חשבון Google Workspace של לקוח א' תהליך אימות רגיל תהליך אימות רגיל תהליך אימות רגיל תהליך אימות לא מאומת
המשתמש הוא חשבון Google Workspace שלא שייך ללקוח א' תהליך אימות רגיל תהליך אימות לא מאומת תהליך אימות לא מאומת תהליך אימות לא מאומת
המשתמש הוא חשבון Gmail1 תהליך אימות רגיל תהליך אימות לא מאומת תהליך אימות לא מאומת תהליך אימות לא מאומת

1כל חשבון Gmail, כולל החשבון שבו השתמשתם כדי לפרסם את האפליקציה.

מכסת משתמשים

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

שליחת בקשת אימות

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

דרישות

כדי לשלוח את לקוח ה-OAuth לאימות, צריך לעמוד בדרישות הבאות:

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

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

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

בנוסף, אתם צריכים לספק את הנכסים הדיגיטליים הנדרשים הבאים:

  • שם האפליקציה. שם האפליקציה שמוצג במסך בקשת ההסכמה. השם צריך להיות זהה לשם שבו משתמשים עבור האפליקציה במקומות אחרים, כמו בדף הרישום של אפליקציות שפורסמו ב-Google Workspace Marketplace.
  • לוגו האפליקציה. לוגו של האפליקציה בפורמט JPEG,‏ PNG או BMP לשימוש במסך הסכמה. גודל הקובץ צריך להיות עד 1MB.
  • כתובת אימייל לתמיכה. זו כתובת אימייל שמוצגת במסך בקשת ההסכמה כדי שהמשתמשים יוכלו לפנות אליה אם הם צריכים תמיכה באפליקציה. אפשר להשתמש בכתובת האימייל שלכם או בקבוצת Google שבבעלותכם או בניהולכם.
  • היקפים. רשימה של כל ההיקפים שבהם האפליקציה משתמשת. אפשר לראות את ההיקפים בכלי לעריכת סקריפטים של Apps Script.
  • דומיינים מורשים. זוהי רשימה של דומיינים שמכילים מידע על האפליקציה שלך. כל הקישורים של האפליקציה (כמו הקישור לדף מדיניות הפרטיות הנדרש) צריכים להיות מאוחסנים בדומיינים מורשים.
  • כתובת ה-URL של דף הבית של האפליקציה. המיקום של דף הבית שבו מתואר האפליקציה. המיקום הזה צריך להתארח בדומיין מורשה.
  • כתובת ה-URL של מדיניות הפרטיות של האפליקציה. המיקום של דף שמתאר את מדיניות הפרטיות של האפליקציה. המיקום הזה צריך להתארח בדומיין מורשה.

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

שלבים

  1. אם עדיין לא עשיתם זאת, עליכם לאמת את הבעלות על כל הדומיינים המורשים שבהם אתם משתמשים כדי לארח את מדיניות הפרטיות ומידע נוסף של פרויקט הסקריפט. הבעלים המאומתים של הדומיינים צריכים להיות עורכים או הבעלים של פרויקט הסקריפט.
  2. בפרויקט Apps Script, לוחצים על סקירה כללית . בקטע Project OAuth Scopes (היקפי OAuth של הפרויקט), מעתיקים את ההיקפים שבהם נעשה שימוש בפרויקט הסקריפט.

  3. משלימים את מסך ההסכמה ל-OAuth עבור פרויקט בענן של האפליקציה ב-Google Cloud באמצעות נכסי הטקסט וכתובות ה-URL שאספתם.

    1. מפרטים את הדומיינים המורשים שבהם מתארח המידע על האפליקציה (למשל מדיניות הפרטיות שלה).

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

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

      בסיום, לוחצים על עדכון.

  4. אחרי שמזינים את כל הפרטים הנדרשים, לוחצים על שמירה.

  5. לוחצים על שליחה לאימות כדי לשלוח בקשת אימות.

רוב בקשות האימות נענות תוך 24 עד 72 שעות. אפשר לבדוק את סטטוס האימות בחלק העליון של הטופס במסך ההסכמה ל-OAuth. אחרי שנקבל אישור לאימות לקוח OAuth, האפליקציה שלכם תאומת.

אם האפליקציה מאומתת ואחר כך מחליטים לעבור לפרויקט אחר ב-Google Cloud, צריך לחזור על השלבים האלה כדי שהאפליקציה תישאר מאומתת.