כל האפליקציות שניגשות לממשקי Google API צריכות לאמת שהן מייצגות בצורה מדויקת את הזהות והמטרה שלהן, כפי שמפורט במדיניות של Google בנושא נתוני משתמשים בשירותי API. כדי להגן עליכם ועל המשתמשים המשותפים של Google ושל האפליקציה שלכם, יכול להיות ש-Google תצטרך לאמת את מסך ההסכמה ואת האפליקציה.
האפליקציה שלכם צריכה לעבור אימות אם היא עומדת בכל הקריטריונים הבאים:
- ב-Google API Console, הגדרת האפליקציה היא סוג משתמש חיצוני וסטטוס הפרסום הוא פורסמה. זה אומר שהאפליקציה נמצאת בסביבת הייצור וזמינה לכל משתמש עם חשבון Google.
- אתם רוצים שהלוגו או השם המוצג של האפליקציה יופיעו במסך ההסכמה של OAuth.
אם תאמתו את פרטי המותג של האפליקציה, תוכלו להגדיל את הסיכוי שהמשתמשים יזהו את המותג שלכם ויחליטו לתת לאפליקציה גישה. פרטי מותג מאומתים יכולים גם להוביל לפחות ביטולים בהמשך, כשמשתמש או אדמין ב-Google Workspace בודקים אפליקציות ושירותים של צד שלישי שיש להם גישה לחשבון. תהליך אימות המותג האוטומטי נמשך בדרך כלל כמה דקות אחרי שלוחצים על הכפתור אימות המיתוג. במקרים מסוימים, כשאי אפשר לקבוע את התוצאה באופן אוטומטי, האפליקציה עשויה לעבור תהליך בדיקה ידני שבדרך כלל נמשך 2-3 ימי עסקים.
אם פרטי המיתוג של האפליקציה לא יאומתו, יכול להיות שהמשתמשים יתנו פחות אמון בבקשה שלכם לקבל את הנתונים שלהם. כתוצאה מכך, יכול להיות שפחות משתמשים יאשרו את הבקשה ויותר משתמשים יבטלו את האישור בהמשך.
מסך ההסכמה של OAuth
במסך ההסכמה המשתמשים יכולים לראות מי מבקש גישה לנתונים שלהם ולאיזה סוג של נתונים האפליקציה צריכה לגשת בשמם, כפי שמודגש בתיבה 2 באיור 1.
כשהאפליקציה עוברת את תהליך אימות המותג ומקבלת אישור, סביר יותר שהמשתמשים בחשבון שמעניק את ההרשאה יבינו בבירור את המדיניות של האפליקציה בנושא זהות ונתוני משתמשים. ההסבר הברור הזה יכול להגדיל את הסבירות שבעל החשבון יאשר את הבקשות שלכם וישמור על הגישה כשהוא יבדוק את הביטולים האפשריים בדף חשבון Google שלו. התוכן שאתם מגדירים בדף המיתוג של OAuth במסוף Cloud מאכלס את הרכיבים הבאים:
- שם האפליקציה והלוגו שלה (כפי שמוצג בתיבה 1 באיור 1)
- כתובת האימייל לתמיכה במשתמשים, שמופיעה אחרי שבוחרים את שם האפליקציה (תיבה 2 באיור 1)
- קישורים למדיניות הפרטיות ולתנאים ולהגבלות (תיבה 3 באיור 1)
דומיינים מורשים
כחלק מתהליך אימות המותג, Google דורשת לאמת את כל הדומיינים שמשויכים למסך ההסכמה ל-OAuth ולפרטי הכניסה של האפליקציה. אנחנו מבקשים לאמת את רכיב הדומיין שזמין לרישום בסיומת ציבורית: הדומיין הפרטי ברמה העליונה. לדוגמה, אם במסך ההסכמה של OAuth מוגדר דף הבית של האפליקציה https://sub.example.com/product, בעל החשבון יתבקש לאמת את הבעלות על הדומיין example.com.
בקטע Authorized domains של עורך מסך ההסכמה של OAuth, צריך להזין את הדומיינים הפרטיים ברמה העליונה שמופיעים בכתובות ה-URI בקטע App domain. הדומיינים האלה כוללים את דף הבית של האפליקציה, מדיניות הפרטיות והתנאים וההגבלות. בקטע Authorized domains צריך לכלול גם את כתובות ה-URI להפניה אוטומטית או את מקורות ה-JavaScript המורשים בסוגי הלקוחות של OAuth ב-"Web application".
מאמתים את הבעלות על הדומיינים המורשים באמצעות Google Search Console. חשבון Google עם הרשאות בעלים לדומיין צריך להיות משויך לפרויקט ב-קונסולה לממשקי API שמשתמש בדומיין המורשה הזה. למידע נוסף על אימותי דומיינים ב-Google Search Console, קראו את המאמר אימות הבעלות על האתר.
איך להתכונן לאימות
כל האפליקציות שמשתמשות בממשקי Google API כדי לבקש גישה לנתונים צריכות לבצע את השלבים הבאים כדי להשלים את אימות המותג:
- מוודאים שהאפליקציה לא נכללת באף אחד מתרחישי השימוש שמפורטים בקטע חריגים לדרישות האימות.
- לוודא שהאפליקציה עומדת בדרישות לגבי מותגים של ממשקי ה-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, חשוב להקפיד לעדכן את תפקידי הבעלים והעריכה של החשבונות שמשויכים לפרויקט, וגם את כתובת האימייל לתמיכה במשתמשים ואת פרטי הקשר של המפתח במסך ההסכמה ל-OAuth. כך תוכלו לוודא שחברי הצוות הרלוונטיים יקבלו הודעה על דרישות חדשות.
- נכנסים לדף המיתוג של OAuth במסוף Cloud.
- לוחצים על הכפתור Project selector.
- בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים מה מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- בדף מיתוג, מספקים את פרטי המיתוג של האפליקציה, כולל שם האפליקציה, הלוגו, פרטים ליצירת קשר עם המפתח וקישורים רלוונטיים. כל שינוי שתבצעו יישמר בתור טיוטת מיתוג.
- כדי להתחיל את תהליך ההערכה, לוחצים על הכפתור אימות המיתוג. הבדיקה האוטומטית מסתיימת בדרך כלל תוך כמה דקות.
- אחרי שההערכה מסתיימת, בודקים את הסטטוס. אם הבדיקה תעבור בהצלחה, הסטטוס ישתנה למוכן לפרסום. אם האימות האוטומטי נכשל, אתם יכולים לראות את הבעיות שזוהו ולתקן אותן או לבקש בדיקה ידנית.
- לוחצים על הכפתור פרסום המיתוג כדי להפעיל את המיתוג החדש.
- אם האפליקציה שלכם דורשת גם אימות של היקפי הרשאות רגישים או מוגבלים, עברו אל מרכז האימות של OAuth כדי לעקוב אחרי סטטוס הגישה לנתונים ולספק את כל המידע הנוסף שנדרש, כמו סרטון הדגמה. שימו לב: כדי לבקש אימות לגישה לנתונים, סטטוס המיתוג שלכם צריך להיות "פורסם".
- משתמשים בלחצן הוספה או הסרה של היקפי הרשאות כדי להצהיר על כל היקפי ההרשאות שהאפליקציה מבקשת. קבוצה ראשונית של היקפי הרשאות שנדרשים לכניסה באמצעות חשבון Google מופיעה כבר במילוי אוטומטי מראש בקטע היקפי הרשאות לא רגישים. היקפי ההרשאות שנוספו מסווגים כלא רגישים, רגישים או מוגבלים.
- צריך לספק עד שלושה קישורים למסמכים רלוונטיים לגבי תכונות קשורות באפליקציה.
- בשלבים הבאים, מספקים את כל המידע הנוסף שנדרש לגבי האפליקציה.
אחרי שתפרסמו את המיתוג או תשלחו בקשה לגישה לנתונים, יכול להיות שהצוות לנושאי מהימנות ובטיחות של Google יפנה אליכם באימייל כדי לבקש מידע נוסף או להנחות אתכם לגבי השלבים הבאים. כדי לבדוק אם קיבלתם בקשות למידע נוסף, אתם יכולים לבדוק את כתובות האימייל בקטע פרטים ליצירת קשר עם המפתח ואת כתובת האימייל לתמיכה במסך ההסכמה של OAuth. אתם יכולים גם להיכנס לדפים "מיתוג" או "מרכז האימות" של הפרויקט כדי לבדוק את סטטוס הבדיקה הנוכחי של הפרויקט, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו ממתינים לתגובה שלכם.
חריגים לדרישות האימות
אם האפליקציה שלכם תשמש באחד מהתרחישים שמתוארים בקטעים הבאים, אתם לא צריכים לשלוח אותה לבדיקה.
שימוש אישי
תרחיש לדוגמה: אתם המשתמשים היחידים באפליקציה, או שיש לה רק כמה משתמשים שאתם מכירים באופן אישי. יכול להיות שאתם ומספר המשתמשים המוגבל שלכם תרגישו בנוח לעבור את מסך האפליקציה הלא מאומתת ולהעניק לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שמשמשים בשכבות פיתוח, בדיקה או Staging
כדי לעמוד בדרישות של מדיניות Google OAuth 2.0, מומלץ להשתמש בפרויקטים שונים לסביבות בדיקה וייצור. מומלץ לשלוח את האפליקציה לאימות רק אם רוצים שהיא תהיה זמינה לכל משתמש עם חשבון Google. לכן, אם האפליקציה שלכם נמצאת בשלבי פיתוח, בדיקה או Staging, אתם לא צריכים לבצע אימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את סטטוס הפרסום בהגדרת ברירת המחדל בדיקה. ההגדרה הזו מציינת שהאפליקציה עדיין בשלבי פיתוח והיא זמינה רק למשתמשים שאתם מוסיפים לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמעורבים בפיתוח או בבדיקה של האפליקציה.
רק נתונים בבעלות השירות
אם האפליקציה שלכם משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, והיא לא ניגשת לנתוני משתמשים (שמקושרים לחשבון Google), אתם לא צריכים לשלוח אותה לאימות.
כדי להבין מהם חשבונות שירות, קראו את המאמר חשבונות שירות במסמכי התיעוד של Google Cloud. במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת מוסבר איך משתמשים בחשבון שירות.
לשימוש פנימי בלבד
המשמעות היא שרק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity משתמשים באפליקציה. הפרויקט צריך להיות בבעלות הארגון, ומסך ההסכמה ל-OAuth צריך להיות מוגדר לסוג משתמש פנימי. במקרה כזה, יכול להיות שהאפליקציה תצטרך אישור ממנהל החשבון הארגוני. מידע נוסף זמין במאמר שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על אפליקציות ציבוריות ופנימיות
- כדי ללמוד איך לסמן את האפליקציה כפנימית, אפשר לעיין בשאלות הנפוצות בנושא איך מסמנים את האפליקציה כפנימית בלבד?
התקנה ברמת הדומיין
אם אתם מתכננים שהאפליקציה תטרגט רק משתמשים של ארגון ב-Google Workspace או ב-Cloud Identity, ותמיד תשתמשו בהתקנה ברמת הדומיין, האפליקציה לא תדרוש אימות מותג. עם זאת, אם האפליקציה משתמשת בהיקפי הרשאות מוגבלים או רגישים, נדרש אימות אפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת למנהל הדומיין לתת לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתוני המשתמשים. רק מנהלי חשבון ארגוני יכולים להוסיף את האפליקציה לרשימת היתרים לשימוש בדומיינים שלהם.
בשאלה הנפוצה באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace מוסבר איך להגדיר את האפליקציה כהתקנה ברמת הדומיין.