כל אפליקציה שמשתמשת ב-Google APIs חייבת לאמת שהן מייצגות באופן מדויק את הזהות ואת הכוונה שלהן, כפי שצוין במדיניות של Google בנושא נתוני משתמשים בשירותי API. כדי להגן עליך ועל המשתמשים המשותפים של Google ושל האפליקציה שלך, ייתכן שיהיה צורך לאמת את מסך ההסכמה ואת הבקשה שלך על ידי Google.
האפליקציה שלך דורשת אימות אם היא עומדת בכל הקריטריונים הבאים:
- ב Google API Console, ההגדרות של האפליקציה נקבעות לסוג המשתמש חיצוני. המשמעות היא שהאפליקציה שלך זמינה לכל משתמש עם חשבון Google.
- אתם רוצים שהאפליקציה תציג לוגו או שם מוצג במסך ההסכמה של OAuth.
אם כוללים פרטי מותג מאומתים, אפשר להגדיל את הסיכוי שהמשתמשים יזהו את המותג ויחליטו להעניק גישה לאפליקציה. פרטים מאומתים על המותג יכולים גם להוביל לפחות ביטולים במועד מאוחר יותר, כשהמשתמש או האדמין ב-Google Workspace בודקים אפליקציות ושירותים של צדדים שלישיים שיש להם גישה לחשבון. בדרך כלל, תהליך אימות המותג על ידי מסך ההסכמה ל-OAuth נמשך 2-3 ימי עסקים אחרי ששולחים אותו לאימות.
אם הבקשה שלך לאימות המותג לא תישלח, עלולה להיות ירידה באמון המשתמשים בבקשה לגבי הנתונים שלהם, מה שעלול להוביל לירידה במספר ההרשאות של משתמשים וליותר ביטולים מאוחר יותר.
מסך הסכמה ל-OAuth
מסך ההסכמה מציין למשתמשים מי מבקש גישה לנתונים שלהם ולאילו סוגים של נתונים האפליקציה צריכה לגשת בשמם, כפי שמפורט בתיבה 2 בסעיף 1.
כשהאפליקציה עוברת את תהליך אימות המותג ומקבלת אישור, יש יותר סיכויים שהמדיניות בנושא זהות ונתוני משתמשים תהיה ברורה יותר לחשבון שנותן את ההרשאה. ההבנה הברורה הזו יכולה להגדיל את הסיכוי שבעלי חשבון יאשרו את הבקשות שלך וימשיכו לגשת אליהם כשהם בודקים ביטולים אפשריים בדף חשבון Google שלהם. התוכן שמגדירים ב-OAuth Consent Screen page ב- API Console מאכלס את הרכיבים הבאים:
- השם והלוגו של האפליקציה (כפי שמוצג בתיבה 1 באיור 1)
- כתובת האימייל של תמיכת המשתמשים, שמופיעה אחרי הבחירה בשם האפליקציה (תיבה 2 באיור 1)
- קישורים למדיניות הפרטיות ולתנאים ולהגבלות שלכם (תיבה 3 באיור 1)
דומיינים מורשים
כחלק מתהליך אימות המותג, Google דורשת אימות של כל הדומיינים שמשויכים למסך ההסכמה ל-OAuth ולפרטי הכניסה של האפליקציה. אנחנו מבקשים ממך לאמת את רכיב הדומיין שזמין לרישום בסיומת ציבורית: "הדומיין הפרטי המוביל". לדוגמה, במסך הסכמה ל-OAuth שהוגדר באמצעות דף הבית של אפליקציה של https://sub.example.com/product, בעלי החשבון יבקשו לאמת את הבעלות על הדומיין example.com.
הקטע דומיינים מורשים בעורך מסך ההסכמה של OAuth צריך לכלול את הדומיינים הפרטיים המובילים שנמצאים בשימוש במזהי ה-URI של הקטע דומיין האפליקציה. הדומיינים האלה כוללים את דף הבית של האפליקציה, את מדיניות הפרטיות ואת התנאים וההגבלות. הקטע דומיינים מורשים צריך גם לכלול את מזהי ה-URI של ההפניה האוטומטית ו/או את מקורות ה-JavaScript המורשים בסוגי לקוחות ה-OAuth "אפליקציית האינטרנט".
מאמתים את הבעלות על הדומיינים המורשים באמצעות Google Search Console. חשבון Google עם הרשאות של בעלים לדומיין חייב להיות משויך לפרויקט API Console שבו נעשה שימוש בדומיין המורשה. מידע נוסף על אימות דומיינים ב-Google Search Console זמין במאמר אימות הבעלות על האתר.
איך מתכוננים לאימות
כל האפליקציות שמשתמשות ב-Google APIs כדי לבקש גישה לנתונים חייבות לבצע את השלבים הבאים כדי להשלים את אימות המותג:
- מוודאים שהאפליקציה לא משתייכת לאף אחד ממקרי השימוש בקטע חריגים לדרישות האימות.
- יש לוודא שהאפליקציה עומדת בדרישות המיתוג של ממשקי ה-API או המוצר המשויכים. לדוגמה, כדאי לעיין בהנחיות המיתוג להיקפים של כניסה באמצעות חשבון Google.
- מאמתים את הבעלות על הדומיינים המורשים של הפרויקט ב-Google Search Console. צריך להשתמש בחשבון Google שמשויך לפרויקט API Console בתור בעלים או עורך.
- יש לוודא שכל פרטי המיתוג במסך ההסכמה של OAuth, כמו שם האפליקציה, אימייל תמיכה, URI של דף הבית, URI של מדיניות הפרטיות וכו', מייצגים את הזהות של האפליקציה באופן מדויק.
דרישות לגבי דף הבית של האפליקציה
צריך לוודא שדף הבית עומד בדרישות הבאות:
- דף הבית שלך חייב להיות נגיש לציבור, ולא נגיש רק למשתמשים שמחוברים לאתר שלך.
- הרלוונטיות של דף הבית לאפליקציה שנמצאת בבדיקה חייבת להיות ברורה.
- קישורים לדף האפליקציה בחנות Google Play או בדף ה-Facebook שלה לא נחשבים לדפי בית חוקיים של האפליקציה.
דרישות לגבי קישור למדיניות הפרטיות של אפליקציות
ודאו שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות חייבת להיות גלויה למשתמשים, שמתארחת באותו דומיין שבו מתארח דף הבית של האפליקציה שלך, ומקושרת אליו במסך ההסכמה של OAuth של Google API Console. לתשומת ליבך, דף הבית חייב לכלול תיאור של פונקציונליות האפליקציה, כמו גם קישורים למדיניות הפרטיות ולתנאים והגבלות אופציונליים.
- מדיניות הפרטיות חייבת לכלול גילוי נאות לגבי האופן שבו האפליקציה ניגשת לנתוני משתמש ב-Google, משתמשת בהם, מאחסנת או משתפת אותם. חובה להגביל את השימוש בנתוני המשתמשים ב-Google רק לשיטות המפורטות במדיניות הפרטיות שפורסמה.
איך לשלוח את האפליקציה לאימות
בGoogle API Console פרויקט מאורגנים כל API Console המשאבים. פרויקט מורכב מקבוצה של חשבונות Google משויכים שיש להם הרשאה לבצע פעולות בפרויקט, קבוצה של ממשקי API שמופעלים, והגדרות חיוב, אימות ומעקב עבור ממשקי ה-API האלה. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש הלקוחות האלה ולהגדיר מסך הסכמה ל-OAuth שמוצג למשתמשים לפני שהם מאשרים את הגישה לאפליקציה.
אם אחד מלקוחות OAuth שלך לא מוכן לסביבת הייצור, מומלץ למחוק אותו מהפרויקט שעבורו נשלחה בקשת האימות. אפשר לעשות זאת ב Google API Console.
כך שולחים בקשה לאימות:
- יש לוודא שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs והמדיניות בנושא נתוני משתמשים בשירותי Google API.
- צריך לוודא שתפקידי הבעלים והעריכה של החשבונות המשויכים לפרויקט יהיו עדכניים, כמו גם האימייל לגבי תמיכת המשתמשים במסך ההסכמה ל-OAuth והפרטים ליצירת קשר עם המפתח, במסגרת API Console. כך החברים הנכונים בצוות שלך יקבלו הודעה על כל דרישה חדשה.
- עוברים אל API Console OAuth Consent Screen page.
- לוחצים על הלחצן בורר הפרויקטים.
-
בתיבת הדו-שיח בחירה מתוך שמופיעה, בוחרים את הפרויקט הרלוונטי. אם לא הצלחת למצוא את הפרויקט אבל מזהה הפרויקט ידוע לך, אפשר ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שבו רוצים להשתמש.
- לוחצים על הלחצן עריכת האפליקציה.
- מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth ולוחצים על הלחצן Save and continue (שמירה והמשך).
- יש ללחוץ על הלחצן הוספה או הסרה של היקפי הרשאות כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. בקטע היקפים לא רגישים, המערכת תמלא מראש קבוצה של היקפים שנחוצים לכניסה באמצעות חשבון Google. היקפי הרשאות שנוספו מסווגים כלא רגישים, sensitive, or restricted.
- יש לספק עד שלושה קישורים לכל תיעוד רלוונטי לגבי תכונות קשורות באפליקציה.
-
בשלבים הבאים, צריך לספק כל מידע נוסף שנדרש לגבי האפליקציה.
- אם הגדרת האפליקציה שסיפקת דורשת אימות, יש לך אפשרות לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על Submit כדי להתחיל את תהליך האימות.
אחרי שליחת האפליקציה, הצוות של Google לנושאי מהימנות ובטיחות יחזור אליך באימייל עם כל מידע נוסף שנדרש לו או השלבים שעליך לבצע. אפשר לבדוק את כתובות האימייל שלך בקטע פרטים ליצירת קשר עם המפתח. ניתן לבדוק את כתובת האימייל לתמיכה במסך ההסכמה של OAuth כדי לראות בקשות למידע נוסף. אפשר גם לעיין בדף מסך ההסכמה ל-OAuth של הפרויקט כדי לאשר את סטטוס הבדיקה הנוכחי של הפרויקט, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו ממתינים לתשובה.
חריגים לדרישות האימות
אם בכוונתך להשתמש באפליקציה באחד מהתרחישים המתוארים בסעיפים הבאים, אין צורך לשלוח אותה לבדיקה.
שימוש אישי
תרחיש לדוגמה אחד הוא אם אתם המשתמשים היחידים באפליקציה, או אם רק מעט משתמשים משתמשים באפליקציה, כולם מוכרים לכם באופן אישי. ייתכן שאתה ומספר המשתמשים המוגבלים תרגישו בנוח להתקדם אל מסך האפליקציה הלא מאומתת ולהעניק לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שנעשה בהם שימוש ברמות של פיתוח, בדיקה או סביבת Staging
כדי לציית למדיניות OAuth 2.0 של Google, מומלץ ליצור פרויקטים שונים לסביבות בדיקה וייצור. מומלץ לשלוח את האפליקציה לאימות רק אם ברצונך שהאפליקציה תהיה זמינה לכל משתמש שיש לו חשבון Google. לכן, אם האפליקציה שלך בשלבי פיתוח, בדיקה או Staging, לא נדרש אימות.
אם האפליקציה בשלבי פיתוח או בדיקה, אפשר להשאיר את סטטוס הפרסום בהגדרת ברירת המחדל בדיקה. משמעות ההגדרה הזו היא שהאפליקציה שלך עדיין בפיתוח וזמינה רק למשתמשים שהוספת לרשימת המשתמשים לבדיקה. צריך לנהל את הרשימה של חשבונות Google שמעורבים בפיתוח או בבדיקה של האפליקציה.
נתונים בבעלות השירות בלבד
אם האפליקציה משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ואין לה גישה לנתוני משתמש (המקושרים לחשבון Google), אין צורך לשלוח בקשה לאימות.
כדי להבין מהם חשבונות שירות, קראו את המאמר חשבונות שירות במאמרי העזרה של Google Cloud. ההוראות לשימוש בחשבון שירות מפורטות במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת.
שימוש פנימי בלבד
כלומר, רק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity יכולים להשתמש באפליקציה. הפרויקט צריך להיות בבעלות הארגון, וצריך להגדיר את מסך ההסכמה ל-OAuth כסוג משתמש פנימי. במקרה כזה, יכול להיות שצריך לקבל אישור ממנהל מערכת בארגון. למידע נוסף, ראו שיקולים נוספים לגבי Google Workspace.
- למידע נוסף על אפליקציות ציבוריות ופנימיות.
- כדי ללמוד איך לסמן את האפליקציה כאפליקציה פנימית, אפשר לעיין בשאלות הנפוצות איך מסמנים את האפליקציה כאפליקציה לשימוש פנימי בלבד?
התקנה ברמת הדומיין
אם אתם מתכננים לטרגט את האפליקציה רק למשתמשים של ארגונים ב-Google Workspace או ב-Cloud Identity, ולהשתמש תמיד בהתקנה ברמת הדומיין, לא יהיה צורך באימות האפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת למנהל הדומיין להעניק לאפליקציות של צד שלישי ולאפליקציות פנימיות גישה לנתוני המשתמשים. אדמינים ארגוניים הם החשבונות היחידים שיכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.
בשאלות הנפוצות באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר ב-Google Workspace מוסבר איך להגדיר את האפליקציה כ'התקנה בכל הדומיין'.