כל האפליקציות שניגשות ל-Google APIs צריכות לאמת שהן מייצגות בצורה מדויקת את הזהות והכוונה שלהן, כפי שמפורט במדיניות של Google בנושא נתוני משתמשים בשירותי API. כדי להגן עליך ועל המשתמשים המשותפים של Google והאפליקציה שלך, יכול להיות ש-Google תצטרך לאמת את מסך ההסכמה והאפליקציה שלך.
האפליקציה שלכם דורשת אימות אם היא עומדת בכל הקריטריונים הבאים:
- ב Google API Console, הגדרת האפליקציה מוגדרת לסוג משתמש External. כלומר, האפליקציה שלכם זמינה לכל משתמש שיש לו חשבון Google.
- אתם רוצים שהלוגו או השם המוצג של האפליקציה יופיעו במסך ההסכמה ל-OAuth.
אם תכללו מידע מאומת על המותג, הסיכוי שמשתמש יזהה את המותג שלכם ויחליט להעניק גישה לאפליקציה שלכם יגדל. מידע מאומת על המותג יכול גם להפחית את מספר הביטולים בהמשך, כשמשתמש או אדמין ב-Google Workspace בודקים אפליקציות ושירותים של צד שלישי שיש להם גישה לחשבון. תהליך אימות המותג במסך בקשת ההרשאה של OAuth נמשך בדרך כלל 2-3 ימי עסקים אחרי ששולחים את הבקשה לאימות.
אם לא תגישו בקשה לאימות המותג, יכול להיות שהמשתמשים יפחיתו את רמת האמון שלהם בבקשה שלכם לקבל את הנתונים שלהם, מה שעלול להוביל לכך שפחות משתמשים יאשרו את הבקשה שלכם, ויותר משתמשים יבטלו את האישור שלהם בהמשך.
מסך הסכמה ל-OAuth
במסך ההסכמה מוצג למשתמשים מי מבקש גישה לנתונים שלהם, ואיזה סוג נתונים האפליקציה שלכם צריכה כדי לגשת בשמם, כמו שמודגש בתיבה 2 באיור 1.
כשהאפליקציה עוברת את תהליך אימות המותג ומקבלת אישור, סביר יותר שהחשבון שמעניק הרשאה יבין בבירור את מדיניות הזהות ונתוני המשתמש של האפליקציה. ההסבר הברור הזה יכול להגדיל את הסיכוי שבעל החשבון יאשר את הבקשות שלכם וישמור על הגישה שלו כשהוא יבדוק את האפשרויות לביטול הגישה בדף חשבון Google שלו. התוכן שאתם מגדירים ב-OAuth Branding page ב Cloud Console מאכלס את הרכיבים הבאים:
- שם האפליקציה והלוגו שלה (כפי שמופיעים בתיבה 1 באיור 1)
- כתובת האימייל לתמיכה במשתמשים, שמופיעה אחרי שבוחרים את שם האפליקציה (תיבה 2 באיור 1)
- קישורים למדיניות הפרטיות ולתנאים ולהגבלות (תיבה 3 באיור 1)
דומיינים מורשים
כחלק מתהליך אימות המותג, Google דורשת אימות של כל הדומיינים שמקושרים למסך ההסכמה ל-OAuth ולאישורים של אפליקציה. אנחנו מבקשים לאמת את רכיב הדומיין שזמין לרישום בסיומת ציבורית: הדומיין הפרטי העליון. לדוגמה, במסך בקשת ההסכמה של OAuth שמוגדר עם דף הבית של האפליקציה https://sub.example.com/product, בעל החשבון מתבקש לאמת את הבעלות על הדומיין example.com.
בקטע דומיינים מורשים בכלי לעריכת מסך ההסכמה ל-OAuth צריכים להופיע הדומיינים הפרטיים ברמה העליונה שמשמשים במזהי ה-URI של הקטע דומיין האפליקציה. הדומיינים האלה כוללים את דף הבית של האפליקציה, מדיניות הפרטיות והתנאים וההגבלות. בקטע Authorized domains צריך לכלול גם את כתובות ה-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 או לדף שלה בפייסבוק לא נחשבים לדפי בית תקפים של אפליקציה.
דרישות לגבי קישור למדיניות הפרטיות של האפליקציה
צריך לוודא שמדיניות הפרטיות של האפליקציה עומדת בדרישות הבאות:
- מדיניות הפרטיות צריכה להיות גלויה למשתמשים, להתארח באותו דומיין כמו דף הבית של האפליקציה, ולהיות מקושרת למסך ההסכמה של OAuth של Google API Console. שימו לב: דף הבית חייב לכלול תיאור של הפונקציונליות של האפליקציה, וגם קישורים למדיניות הפרטיות ולתנאים ולהגבלות (אופציונלי).
- מדיניות הפרטיות חייבת לפרט את האופן שבו האפליקציה ניגשת לנתוני משתמשים ב-Google, משתמשת בהם, מאחסנת אותם או משתפת אותם. אתם חייבים להגביל את השימוש שלכם בנתוני משתמשים של Google לשיטות שמופיעות במדיניות הפרטיות שפרסמתם.
איך שולחים את האפליקציה לאימות
בGoogle Cloud Console פרויקט מאורגנים כל Cloud Console המשאבים שלכם. פרויקט מורכב מקבוצה של חשבונות Google משויכים שיש להם הרשאה לבצע פעולות בפרויקט, מקבוצה של ממשקי API מופעלים ומקבוצה של הגדרות חיוב, אימות ומעקב לאותם ממשקי API. לדוגמה, פרויקט יכול להכיל לקוח OAuth אחד או יותר, להגדיר ממשקי API לשימוש על ידי הלקוחות האלה ולהגדיר מסך הסכמה ל-OAuth שמוצג למשתמשים לפני שהם מאשרים גישה לאפליקציה שלכם.
אם יש לקוחות OAuth שלא מוכנים לסביבת הייצור, מומלץ למחוק אותם מהפרויקט שבו מתבצעת הבקשה לאימות. אפשר לעשות את זה ב Clients page.
כדי לשלוח בקשה לאימות, פועלים לפי השלבים הבאים:
- מוודאים שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs ושל המדיניות של Google בנושא נתוני משתמשים בשירותי API.
- חשוב לוודא שהתפקידים 'בעלים' ו'עריכה' בחשבונות המשויכים לפרויקט שלכם יהיו עדכניים, וגם כתובת האימייל לתמיכה במשתמשים ופרטי הקשר של המפתח במסך בקשת ההסכמה ל-OAuth ב- Cloud Console. כך אפשר לוודא שהחברים המתאימים בצוות שלכם יקבלו הודעה על כל דרישה חדשה.
- עוברים אל Cloud Console מרכז האימות של OAuth.
- לוחצים על הלחצן Project selector (בורר הפרויקטים).
-
בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים מה מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שרוצים להשתמש בו.
- לוחצים על הלחצן עריכת האפליקציה.
- מזינים את המידע הנדרש בדף מסך ההסכמה של OAuth ולוחצים על הלחצן שמירה והמשך.
- משתמשים בלחצן הוספה או הסרה של היקפים כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. קבוצה ראשונית של היקפים שנדרשים לכניסה באמצעות חשבון Google מאוכלסת מראש בקטע היקפים לא רגישים. ההיקפים שנוספו מסווגים כלא רגישים, sensitive, or restricted.
- צריך לספק עד שלושה קישורים לתיעוד רלוונטי של תכונות קשורות באפליקציה.
-
בשלבים הבאים תתבקשו לספק מידע נוסף על האפליקציה.
- אם הגדרת האפליקציה שסיפקתם דורשת אימות, תוכלו לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על שליחה כדי להתחיל את תהליך האימות.
אחרי ששולחים את האפליקציה, הצוות של Google לנושאי מהימנות ובטיחות שולח אימייל עם מידע נוסף שנדרש או עם שלבים שצריך לבצע. כדאי לבדוק את כתובות האימייל בקטע פרטים ליצירת קשר עם המפתח ואת כתובת האימייל לתמיכה במסך ההסכמה ל-OAuth כדי לראות אם יש בקשות למידע נוסף. אפשר גם להיכנס לדף של מסך ההסכמה של 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 ותמיד תשתמש בהתקנה בכל הדומיין, לא תצטרכו לאמת את המותג של האפליקציה. עם זאת, אם האפליקציה משתמשת ב היקפים מוגבלים או רגישים, נדרש אימות האפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת לאדמין בדומיין להעניק לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתוני המשתמשים. רק אדמינים של ארגונים יכולים להוסיף את האפליקציה לרשימת ההיתרים לשימוש בדומיינים שלהם.
במאמר בנושא שאלות נפוצות מוסבר איך להפוך את האפליקציה להתקנה בכל הדומיין. באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace.