כל האפליקציות שיש להן גישה ל-Google APIs צריכות לאמת שהן מייצגות בצורה מדויקת את הזהות והכוונה שלהן, כפי שמפורט במדיניות של Google בנושא נתוני משתמשים בשירותי API. כדי להגן עליך ועל המשתמשים המשותפים של Google והאפליקציה שלך, יכול להיות ש-Google תצטרך לאמת את מסך ההסכמה והאפליקציה שלך.
האפליקציה שלך דורשת אימות אם היא עומדת בכל הקריטריונים הבאים:
- ב-Google API Console, ההגדרה של האפליקציה היא מסוג המשתמש External והסטטוס שלה הוא Published. המשמעות היא שהאפליקציה שלכם נמצאת בסביבת ייצור וזמינה לכל משתמש עם חשבון Google.
- אתם רוצים שהלוגו או השם המוצג של האפליקציה יופיעו במסך ההסכמה ל-OAuth.
אם תאמתו את פרטי המותג של האפליקציה, הסיכוי שמשתמש יזהה את המותג ויחליט להעניק לאפליקציה גישה יגדל. פרטי מותג מאומתים יכולים גם להפחית את מספר ביטולי הגישה בהמשך, כשמשתמש או אדמין ב-Google Workspace בודקים אפליקציות ושירותים של צד שלישי שיש להם גישה לחשבון. תהליך האימות האוטומטי של המיתוג בדרך כלל נמשך כמה דקות אחרי שלוחצים על הלחצן אימות המיתוג. במקרים מסוימים, אם לא ניתן לקבוע את התוצאה באופן אוטומטי, האפליקציה תעבור תהליך בדיקה ידני שנמשך בדרך כלל 2-3 ימי עסקים.
אם פרטי המיתוג של האפליקציה לא יאומתו, יכול להיות שהמשתמשים יתקשו לסמוך על הבקשה שלכם לקבל את הנתונים שלהם, וכתוצאה מכך פחות משתמשים יאשרו את הבקשה ויותר משתמשים יבטלו את האישור בהמשך.
מסך הסכמה ל-OAuth
במסך ההסכמה מוצג למשתמשים מי מבקש גישה לנתונים שלהם ואיזה סוג נתונים האפליקציה שלכם צריכה לגשת אליהם בשמם, כפי שמודגש בתיבה 2 באיור 1.
כשהאפליקציה עוברת את תהליך אימות המותג ומקבלת אישור, סביר יותר שהחשבון שמעניק הרשאה יבין בבירור את הזהות של האפליקציה ואת מדיניות נתוני המשתמשים שלה. ההסבר הברור הזה יכול להגדיל את הסיכוי שבעל החשבון יאשר את הבקשות שלכם וישמור על הגישה שלו כשהוא יבדוק את האפשרויות לביטול בדף חשבון Google. התוכן שאתם מגדירים בדף המיתוג של OAuth ב-Cloud Console מאכלס את הרכיבים הבאים:
- השם והלוגו של האפליקציה (כפי שמוצגים בתיבה 1 באיור 1)
- כתובת האימייל לתמיכה במשתמשים, שמופיעה אחרי בחירת שם האפליקציה (תיבה 2 באיור 1)
- קישורים למדיניות הפרטיות ולתנאים ולהגבלות (תיבה 3 באיור 1)
איור 1. מודל של מסך ההסכמה ל-OAuth.
דומיינים מורשים
כחלק מתהליך אימות המותג, Google דורשת אימות של כל הדומיינים שמשויכים למסך ההסכמה ל-OAuth ולאישורים של אפליקציה. אנחנו מבקשים לאמת את רכיב הדומיין שזמין לרישום בסיומת ציבורית: הדומיין הפרטי העליון. לדוגמה, במסך בקשת ההסכמה של OAuth שמוגדר עם דף הבית של האפליקציה https://sub.example.com/product, בעל החשבון מתבקש לאמת את הבעלות על הדומיין example.com.
בקטע Authorized domains (דומיינים מורשים) בכלי לעריכת מסך ההסכמה של OAuth צריכים להופיע הדומיינים הפרטיים ברמה העליונה שמשמשים ב-URI של הקטע App domain (דומיין האפליקציה). הדומיינים האלה כוללים את דף הבית של האפליקציה, מדיניות הפרטיות והתנאים וההגבלות. בקטע דומיינים מורשים צריך לכלול גם את כתובות ה-URI להפניה או את מקורות ה-JavaScript שמורשים בסוגי לקוחות OAuth של 'אפליקציית אינטרנט'.
כדי לאמת את הבעלות על הדומיינים המורשים, משתמשים ב-Google Search Console. צריך לשייך לחשבון Google הרשאות בעלים לדומיין, ולקשר אותו לפרויקט במסוף ממשקי ה-API שמשתמש בדומיין המורשה הזה. מידע נוסף על אימות דומיינים ב-Google Search Console זמין במאמר אימות הבעלות על האתר.
שלבים להכנה לאימות
כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים צריכות לבצע את השלבים הבאים כדי להשלים את אימות המותג:
- חשוב לוודא שהאפליקציה לא נכללת באף אחד מתרחישי השימוש שמפורטים בקטע חריגים לדרישות האימות.
- חשוב לוודא שהאפליקציה עומדת בדרישות המיתוג של ממשקי ה-API או המוצר המשויכים. לדוגמה, אפשר לעיין בהנחיות המיתוג לגבי היקפי ההרשאות של כניסה באמצעות חשבון Google.
- מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. משתמשים בחשבון Google שמקושר לפרויקט ב-קונסולה לממשקי API בתור בעלים או עורך.
- חשוב לוודא שכל פרטי המיתוג במסך ההסכמה ל-OAuth, כמו שם האפליקציה, כתובת האימייל לתמיכה, ה-URI של דף הבית, ה-URI של מדיניות הפרטיות וכו', מייצגים בצורה מדויקת את הזהות של האפליקציה.
הדרישות לגבי דף הבית של האפליקציה
צריך לוודא שדף הבית עומד בדרישות הבאות:
- דף הבית של האתר חייב להיות נגיש לכולם, ולא רק למשתמשים שמחוברים לאתר.
- הקשר בין דף הבית לבין האפליקציה שנמצאת בבדיקה צריך להיות ברור.
- קישורים לדף האפליקציה בחנות Google Play או לדף שלה בפייסבוק לא נחשבים לדפי בית תקפים של אפליקציה.
דרישות לגבי קישור למדיניות הפרטיות של האפליקציה
צריך לוודא שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות צריכה להיות גלויה למשתמשים, להתארח באותו דומיין כמו דף הבית של האפליקציה ולקשר למסך ההסכמה ל-OAuth ב-Google API Console. שימו לב שדף הבית צריך לכלול תיאור של הפונקציונליות של האפליקציה, וגם קישורים למדיניות הפרטיות ולתנאים ולהגבלות (אם יש).
- מדיניות הפרטיות חייבת לכלול גילוי נאות לגבי האופן שבו האפליקציה ניגשת לנתוני משתמשים ב-Google, משתמשת בהם, מאחסנת אותם או משתפת אותם. חובה להגביל את השימוש בנתוני משתמשים ב-Google לשיטות שמתוארות במדיניות הפרטיות שפרסמתם.
איך שולחים את האפליקציה לאימות מותג
פרויקט במסוף Google Cloud מארגן את כל המשאבים שלכם במסוף Cloud. פרויקט מורכב מקבוצה של חשבונות Google משויכים שיש להם הרשאה לבצע פעולות בפרויקט, מקבוצה של ממשקי API שמופעלים, ומחיוב, אימות והגדרות מעקב עבור ממשקי ה-API האלה. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש על ידי הלקוחות האלה ולהגדיר מסך הסכמה ל-OAuth שמוצג למשתמשים לפני שהם מאשרים גישה לאפליקציה שלכם.
אם יש לקוחות OAuth שלא מוכנים להפעלה בסביבת הייצור, מומלץ למחוק אותם מהפרויקט שבו מתבצעת הבקשה לאימות. אפשר לעשות זאת בדף הלקוחות.
כדי לשלוח את הבקשה לאימות, פועלים לפי השלבים הבאים:
- מוודאים שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs ושל המדיניות של Google בנושא נתוני משתמשים בשירותי API.
- ב-Cloud Console, חשוב לוודא שהתפקידים 'בעלים' ו'עריכה' בחשבונות המשויכים לפרויקט מעודכנים, וגם כתובת האימייל לתמיכה במשתמשים ופרטי הקשר של המפתח במסך בקשת ההסכמה של OAuth. כך אפשר לוודא שהחברים המתאימים בצוות יקבלו הודעה על דרישות חדשות.
- נכנסים לדף המיתוג של OAuth במסוף Cloud.
- לוחצים על הלחצן בורר הפרויקטים.
- בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים מה מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- בדף מיתוג, צריך לספק את פרטי המיתוג של האפליקציה, כולל שם האפליקציה, הלוגו, הפרטים ליצירת קשר עם המפתח וקישורים רלוונטיים. כל שינוי שתבצעו יישמר כטיוטה של מיתוג.
- כדי להתחיל בתהליך הבדיקה, לוחצים על הלחצן אימות המיתוג. הבדיקה האוטומטית מסתיימת בדרך כלל תוך כמה דקות.
- אחרי שההערכה מסתיימת, בודקים את הסטטוס. אם הפעולה תצליח, הסטטוס ישתנה למוכן לפרסום. אם האימות האוטומטי נכשל, תוכלו לראות את הבעיות שזוהו ולתקן אותן או לבקש בדיקה ידנית.
- לוחצים על הלחצן פרסום המיתוג כדי להפעיל את המיתוג החדש.
- אם האפליקציה שלכם דורשת גם אימות של היקפים רגישים או מוגבלים, אתם צריכים לעבור אל מרכז האימות של OAuth כדי לעקוב אחרי סטטוס הגישה לנתונים ולספק את כל המידע הנוסף שנדרש, כמו סרטון הדגמה. שימו לב: כדי לבקש אימות לגישה לנתונים, צריך שסטטוס המיתוג שלכם יהיה 'פורסם'.
- משתמשים בלחצן הוספה או הסרה של היקפי הרשאה כדי להצהיר על כל היקפי ההרשאה שהאפליקציה מבקשת. קבוצה ראשונית של היקפי הרשאה שנדרשים לכניסה באמצעות חשבון Google מאוכלסת מראש בקטע היקפי הרשאה לא רגישים. ההיקפים שנוספו מסווגים כלא רגישים, sensitive, or restricted.
- צריך לספק עד שלושה קישורים לתיעוד רלוונטי של תכונות קשורות באפליקציה.
- בשלבים הבאים תתבקשו לספק מידע נוסף על האפליקציה.
אחרי שתפרסמו את המיתוג או תשלחו בקשה לגישה לנתונים, יכול להיות שצוות לנושאי מהימנות ובטיחות של Google ייצור איתכם קשר באימייל כדי לבקש מידע נוסף או להנחות אתכם לגבי השלבים שצריך לבצע. כדאי לבדוק את כתובות האימייל שלכם בקטע פרטים ליצירת קשר עם המפתח ואת כתובת האימייל לתמיכה במסך ההסכמה של OAuth כדי לראות אם קיבלתם בקשות למידע נוסף. אפשר גם לעיין בדפים 'מיתוג' או 'מרכז האימות' של הפרויקט כדי לראות את סטטוס הבדיקה הנוכחי של הפרויקט, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו מחכים לתגובה שלכם.
חריגים לדרישות האימות
אם האפליקציה שלכם תשמש באחד מהתרחישים שמתוארים בקטעים הבאים, לא צריך לשלוח אותה לבדיקה.
שימוש אישי
תרחיש שימוש אחד הוא אם אתם המשתמשים היחידים באפליקציה שלכם או אם רק כמה משתמשים משתמשים באפליקציה, וכולם מוכרים לכם באופן אישי. יכול להיות שאתם ומספר המשתמשים המוגבל שלכם תרגישו בנוח להמשיך למסך האפליקציה שלא אומתה ולתת לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שמשמשים ברמות פיתוח, בדיקה או הכנה
כדי לפעול בהתאם למדיניות OAuth 2.0 של Google, מומלץ להשתמש בפרויקטים שונים לסביבות בדיקה וייצור. מומלץ לשלוח את האפליקציה לאימות רק אם רוצים שהיא תהיה זמינה לכל משתמש עם חשבון Google. לכן, אם האפליקציה נמצאת בשלבי פיתוח, בדיקה או הכנה להפצה, לא נדרש אימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את סטטוס הפרסום בהגדרת ברירת המחדל בדיקה. ההגדרה הזו מציינת שהאפליקציה עדיין בפיתוח וזמינה רק למשתמשים שאתם מוסיפים לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמשתתפים בפיתוח או בבדיקה של האפליקציה.
רק נתונים שבבעלות השירות
אם האפליקציה שלכם משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ולא ניגשת לנתוני משתמשים (שמקושרים לחשבון Google), אתם לא צריכים לשלוח אותה לאימות.
במאמר בנושא חשבונות שירות במאמרי העזרה של Google Cloud מוסבר מהם חשבונות שירות. הוראות לשימוש בחשבון שירות מופיעות במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת.
לשימוש פנימי בלבד
כלומר, רק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity יכולים להשתמש באפליקציה. הפרויקט צריך להיות בבעלות הארגון, ומסך ההסכמה ל-OAuth צריך להיות מוגדר עבור סוג המשתמש Internal. במקרה כזה, יכול להיות שהאדמין של הארגון יצטרך לאשר את האפליקציה. מידע נוסף זמין במאמר שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על אפליקציות ציבוריות ופנימיות
- במאמר בנושא שאלות נפוצות מוסבר איך מסמנים אפליקציה כפנימית בלבד
התקנה ברמת הדומיין
אם אתם מתכננים שהאפליקציה שלכם תפנה רק למשתמשים בארגון Google Workspace או Cloud Identity ותמיד תשתמשו בהתקנה בכל הדומיין, לא תצטרכו לאמת את המותג שלכם. עם זאת, אם האפליקציה משתמשת בהיקפים מוגבלים או רגישים, נדרש אימות האפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת לאדמין של הדומיין להעניק לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתונים של המשתמשים. רק אדמינים בארגון יכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.
במאמר בנושא שאלות נפוצות My application has users with enterprise accounts from another Google Workspace Domain (יש לאפליקציה שלי משתמשים עם חשבונות ארגוניים מדומיין אחר ב-Google Workspace) מוסבר איך להפוך את האפליקציה להתקנה בכל הדומיין.