כל האפליקציות שמקבלות גישה ל-Google APIs צריכות לאמת שהן מייצגות בצורה מדויקת את הזהות והכוונה שלהן, כפי שמפורט במדיניות נתוני המשתמש של שירותי Google API. כדי להגן עליכם ועל המשתמשים המשותפים של Google והאפליקציה שלכם, יכול להיות ש-Google תצטרך לאמת את מסך ההסכמה ואת האפליקציה.
האפליקציה שלך דורשת אימות אם היא עומדת בכל הקריטריונים הבאים:
- בקובץ , הגדרת האפליקציה שלך מוגדרת למשתמש הסוג של חיצוני. כלומר האפליקציה זמינה לכל משתמש שיש לו חשבון Google חשבון.
- אתם רוצים שהאפליקציה תציג לוגו או שם מוצג מסך ההסכמה של OAuth
אם כוללים פרטים מאומתים של מותג, אפשר להגדיל את הסיכוי שהמשתמשים יזהו ומחליטה להעניק גישה לאפליקציה. אימות של פרטי מותג יכול גם להוביל פחות ביטולים בשל משתמש או אדמין ב-Google Workspace בהמשך בודק אפליקציות ושירותים של צד שלישי עם גישה לחשבון. תהליך האימות של מותגים באמצעות מסך ההסכמה של OAuth נמשך בדרך כלל 2-3 ימי עסקים אחרי שליחת הבקשה לאימות.
אם לא תשלחו את הבקשה לאימות המותג, זה עלול להוביל לירידה במספר המשתמשים אמון בבקשתך לקבלת הנתונים שלהם, מה שיכול להוביל לפחות הרשאות משתמשים ויותר לבטל אותן בשלב מאוחר יותר.
מסך ההסכמה ל-OAuth
במסך ההסכמה מוצג למשתמשים מי מבקש גישה לנתונים שלהם ואיזה סוג של נתונים האפליקציה שלכם צריכה לגשת אליהם בשמם, כפי שמודגש בתיבה 2 באיור 1.
כשהאפליקציה עוברת את תהליך אימות המותג ומקבלת אישור, שמדיניות הזהות ונתוני המשתמש של האפליקציה תהיה מובנת יותר, החשבון שמעניק הרשאה. הבנה ברורה זו יכולה להגדיל את הסבירות בעל החשבון מאשר את הבקשות שלך ושומר על הגישה בזמן שהוא בודק ביטולים אפשריים בדף חשבון Google. התוכן שאתם מגדירים ב-OAuth מאכלסת את הרכיבים הבאים:
- השם והלוגו של האפליקציה (כפי שמוצגים בתיבה 1 באיור 1)
- כתובת האימייל של תמיכת המשתמש, שמופיעה לאחר בחירת שם האפליקציה (תיבה 2 באיור 1)
- קישורים למדיניות הפרטיות ולתנאים ולהגבלות שלך (תיבה 3 מתוך איור 1)
דומיינים מורשים
כחלק מתהליך אימות המותג, Google דורשת אימות של כל הדומיינים שמשויך למסך ההסכמה ולפרטי הכניסה של אפליקציה. עליך לאמת את רכיב הדומיין הזמין לרישום בסיומת ציבורית: "למעלה private domain." לדוגמה, מסך הסכמה ל-OAuth שמוגדר באפליקציה דף הבית של https://sub.example.com/product מבקש מבעל החשבון לאמת בעלות על הדומיין example.com.
הקטע דומיינים מורשים בכלי לעריכת מסך ההסכמה של OAuth צריך להכיל את החלק העליון של המסך דומיינים פרטיים שנעשה בהם שימוש במזהי ה-URI של הקטע דומיין האפליקציה. הדומיינים האלה כוללים דף הבית, מדיניות הפרטיות והתנאים וההגבלות של האפליקציה. הקטע דומיינים מורשים צריך לכלול גם את מזהי ה-URI להפניה אוטומטית ו/או את מקורות JavaScript שאושרו ב' application" סוגים של לקוחות OAuth.
אימות הבעלות על הדומיינים המורשים שלך באמצעות Google Search Console. A Google חשבון עם הרשאות בעלים של דומיין חייב להיות משויך ל פרויקט שמשתמש בדומיין המורשה הזה. מידע נוסף על אימות דומיינים ב-Google Search Console זמין במאמר אימות הבעלות על האתר.
שלבים להכנה לאימות
כל אפליקציה שמשתמשת ב-Google APIs כדי לבקש גישה לנתונים חייבות לבצע את השלבים הבאים כדי כדי להשלים את תהליך אימות המותג:
- מוודאים שהאפליקציה לא עומדת באף אחד מהתרחישים לדוגמה הקטע יוצאים מן הכלל לדרישות האימות.
- לוודא שהאפליקציה עומדת בדרישות המיתוג של ממשקי ה-API המשויכים, או המוצר. לדוגמה, הנחיות למיתוג של היקפי הרשאה לכניסה באמצעות חשבון Google.
- אימות הבעלות על הפרויקט של דומיינים מורשים בתוך Google Search Console. שימוש ב-Google חשבון שמשויך לפרויקט שלך בתור בעלים או עריכה.
- לוודא שכל פרטי המיתוג במסך ההסכמה ל-OAuth, כמו שם האפליקציה, תמיכה האימייל, ה-URI של דף הבית, ה-URI של מדיניות הפרטיות וכו', מייצג במדויק את זהות האפליקציה.
דרישות לגבי דף הבית של האפליקציה
צריך לוודא שדף הבית עומד בדרישות הבאות:
- דף הבית חייב להיות נגיש לציבור, ולא נגיש רק למשתמשים מחוברים לאתר שלכם משתמשים.
- הרלוונטיות של דף הבית לאפליקציה שנמצאת בבדיקה צריכה להיות ברורה.
- לא נלקחים בחשבון קישורים לדף האפליקציה בחנות Google Play או לדף ה-Facebook שלה דפי בית חוקיים של אפליקציות.
דרישות הקישור למדיניות הפרטיות של אפליקציות
ודאו שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות חייבת להיות גלויה למשתמשים, שמתארחת באותו דומיין שבו מתארח דף הבית של האפליקציה, ובמסך ההסכמה ל-OAuth של האפליקציה לתשומת ליבכם: דף הבית חייב לכלול קישור תיאור של הפונקציונליות של האפליקציה, וגם קישורים למדיניות הפרטיות תנאים והגבלות אופציונליים.
- מדיניות הפרטיות חייבת לכלול גילוי נאות לגבי האופן שבו האפליקציה ניגשת לאפליקציה, משתמשת בה שומרת או משתפת את נתוני המשתמש ב-Google. עליך להגביל את השימוש בנתוני המשתמשים ב-Google בהתאם לשיטות הפרסום מדיניות הפרטיות שלנו.
איך שולחים את האפליקציה לאימות
פרויקט מארגן את כל המשאבים שלכם ב- . פרויקט מורכב מקבוצה של לחשבונות Google עם הרשאה לבצע פעולות בפרויקט, קבוצה של ממשקי API שמופעלים, הגדרות החיוב, האימות והמעקב לאותם ממשקי ה-API. לדוגמה, פרויקט יכול מכילים לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש הלקוחות האלה ולהגדיר מסך ההסכמה של OAuth שמוצג למשתמשים לפני שהם מאשרים גישה לאפליקציה.
אם יש לקוחות OAuth שלא מוכנים לייצור, מומלץ למחוק אותם מ: הפרויקט שמבקש את האימות. אפשר לעשות זאת
כדי לשלוח בקשה לאימות:
- מוודאים שהאפליקציה עומדת בתנאים ובהגבלות של Google APIs, המדיניות בנושא נתוני משתמשים בשירותי Google API.
- להקפיד שתפקידי הבעלים והעריכה של החשבונות המשויכים לפרויקט יהיו עדכניים, וגם כתובת האימייל לתמיכה במשתמשים ואת הפרטים ליצירת קשר עם המפתח, שמופיעים במסך ההסכמה של OAuth כך אפשר להבטיח שהחברים הנכונים מקבלים הודעות על דרישות חדשות.
- נכנסים אל OAuth .
- לוחצים על הלחצן Project selector (בורר הפרויקטים).
-
בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם לא מצאתם את אבל אתם יודעים את מזהה הפרויקט, תוכלו ליצור כתובת URL בדפדפן שלכם באופן הבא: פורמט:
?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שבו רוצים להשתמש.
- לוחצים על הלחצן עריכת האפליקציה.
- מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth, ואז לוחצים על הלחצן שמירה והמשך.
- כדי להצהיר על כל היקפי ההרשאות שהאפליקציה מבקשת, צריך להשתמש בלחצן הוספה או הסרה של היקפי הרשאות. הקבוצה הראשונית של היקפים הנדרשים לכניסה באמצעות חשבון Google, ממולאים מראש היקפים לא רגישים. היקפים שנוספו מסווגים כלא רגישים, sensitive, or restricted.
- צריך לספק עד שלושה קישורים לכל מסמך רלוונטי לגבי תכונות קשורות באפליקציה.
-
לספק את כל המידע הנוסף שביקשנו לגבי האפליקציה לבצע מיליון שלבים.
- אם הגדרות האפליקציה שסיפקתם מחייבות אימות, תוכלו לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל תהליך האימות.
אחרי שתשלחו את האפליקציה, צוות Trust & של Google צוות הבטיחות מטפל בבקשה באימייל מידע נוסף שנדרש להם או שלבים שעליכם להשלים. בודקים את כתובות האימייל הקטע פרטים ליצירת קשר עם המפתח וכתובת האימייל לתמיכה בנושא הסכמת ה-OAuth מסך לבקשות למידע נוסף. אפשר גם להציג את הסכמת ה-OAuth של הפרויקט דף מסך כדי לאשר את סטטוס הבדיקה הנוכחי של הפרויקט, כולל סטטוס הבדיקה. מושהה בזמן שאנו ממתינים לתשובה שלך.
יוצאים מן הכלל לדרישות האימות
אם ייעשה שימוש באפליקציה באחד מהתרחישים שמתוארים בקטעים הבאים, אין צורך לשלוח אותו לבדיקה.
שימוש אישי
תרחיש לדוגמה אחד הוא אם אתם המשתמשים היחידים באפליקציה או אם היא משמשת רק מעט משתמשים: וכולם מוכרים לך באופן אישי. לך ולמספר מוגבל של משתמשים כנראה שיהיה לך טוב להתקדם אפליקציה לא מאומתת ולהעניק לחשבונות האישיים גישה לאפליקציה.
פרויקטים שמשמשים לפיתוח, לבדיקה או ל-Staging רמות
כדי לעמוד בדרישות של מדיניות Google OAuth 2.0, מומלץ ליצור פרויקטים שונים לסביבות בדיקה וסביבות ייצור. מומלץ לשלוח את האפליקציה לאימות רק אם אתם רוצים שהיא תהיה זמינה לכל משתמש שיש לו חשבון Google. לכן, אם האפליקציה נמצא בשלבי פיתוח, בדיקה או Staging, אין צורך לבצע אימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את סטטוס פרסום בהגדרת ברירת המחדל בדיקות. ההגדרה הזו מציינת שהאפליקציה עדיין בפיתוח והיא זמינה רק למשתמשים שתוסיפו לרשימת המשתמשים לבדיקה. חובה לנהל את הרשימה של חשבונות Google מעורבים בפיתוח או בבדיקה של האפליקציה שלכם.
רק נתונים בבעלות השירות
אם האפליקציה משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, ואין לה גישה לאף משתמש (מקושרים לחשבון Google), לא צריך להגיש בקשה לאימות.
כדי להבין מהם חשבונות שירות, אפשר לעיין במאמר חשבונות שירות ב- משאבי העזר של Google Cloud. הוראות לשימוש בחשבון שירות זמינות במאמר שימוש ב-OAuth 2.0 לשרת לשרת .
לשימוש פנימי בלבד
כלומר, רק אנשים משתמשים ב-Google Workspace או ב-Cloud Identity שלך משתמשים באפליקציה ארגון. הפרויקט צריך להיות בבעלות הארגון ומסך ההסכמה ל-OAuth צריך להגדיר משתמש פנימי type. במקרה כזה, יכול להיות שתצטרכו אישור מאדמין בארגון. למידע נוסף, ראו שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על ציבוריים וגם לשימוש פנימי.
- בשאלות הנפוצות מוסבר איך לסמן את האפליקציה כפנימית איך מסמנים את האפליקציה בתור לשימוש פנימי בלבד?
התקנה ברמת הדומיין
אם האפליקציה שלך תטרגט רק משתמשים של Google Workspace או Cloud Identity את הארגון ולהשתמש תמיד בכל הדומיין , האפליקציה לא תדרוש אימות אפליקציה. הסיבה לכך היא שדומיין ברמת הדומיין מאפשרת למנהל דומיין להעניק לאפליקציות של צד שלישי ואפליקציות פנימיות גישה של המשתמשים שלך . מנהלי מערכת ארגוניים הם החשבונות היחידים שיכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.
בשאלות הנפוצות אפשר ללמוד איך להפוך את האפליקציה ל'התקנה ברמת הדומיין' באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין Google Workspace אחר.