אם האפליקציה שלכם מבקשת הרשאה להשתמש ב-Google APIs כדי לגשת לנתוני המשתמשים של Google, יכול להיות שתצטרכו להשלים תהליך אימות לפני שתהפכו את האפליקציה לזמינה לציבור בפעם הראשונה.
השאלה אם הדרישה הזו חלה על האפליקציה שלכם תלויה בעיקר בשני גורמים:
- סוג נתוני המשתמש שאליהם אתם ניגשים – מידע מפרופיל ציבורי, פריטים ביומן, קבצים ב-Drive, נתונים מסוימים של אימוני כושר וכו'.
- רמת הגישה שאתם צריכים – קריאה בלבד, קריאה וכתיבה וכו'.
כשאתם משתמשים ב-OAuth 2.0 כדי לקבל הרשאה מחשבון Google לגשת לנתונים שלו, אתם משתמשים במחרוזות שנקראות היקפים כדי לציין את סוג הנתונים שאתם רוצים לגשת אליהם בשמו. אם האפליקציה מבקשת היקפים שמסווגים בתור רגישים או מוגבלים, כנראה שתצטרכו להשלים את תהליך האימות, אלא אם השימוש באפליקציה עומד בתנאים להחרגה.
דוגמאות להיקפים רגישים: קריאת אירועים ששמורים ביומן Google, שמירת איש קשר חדש באנשי הקשר בחשבון Google או מחיקת סרטון ב-YouTube. מידע נוסף על היקפי ההרשאות הזמינים והסיווגים שלהם זמין במאמרי העזרה של נקודות הקצה ל-API שהאפליקציה קוראת להן, ובכל מדריך הרשאות קשור שפורסם ל-API.
אתם צריכים לבקש היקפי הרשאות שדורשים את רמת הגישה המינימלית לנתוני המשתמשים שנדרשים כדי לספק את הפונקציונליות הזו. לדוגמה, אם אפליקציה רק קוראת נתונים, אסור לה לבקש גישה לקריאה, כתיבה ומחיקה של תוכן כשיש היקף הרשאות מצומצם יותר ל-API ולנקודות הקצה הקשורות אליו. מותר להשתמש בנתונים שמתקבלים מ-Google API רק בהתאם למדיניות של ה-API ובאופן שמוצג למשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלה.
חשוב להביא בחשבון את הזמן שנדרש להשלמת האימות בתוכנית ההשקה של האפליקציה או של תכונות חדשות שדורשות היקף חדש. תהליך האימות של היקף הרשאות רגיש יכול להימשך עד 10 ימים. שימו לב: יכול להיות שהאפליקציה שלכם עומדת בדרישות להשלמת אימות המותג כחלק מהבקשה לאימות ההיקף הרגיש.
הסבר על היקפים רגישים
היקפי הרשאות רגישים דורשים בדיקה של Google לפני שחשבון Google כלשהו יכול להעניק גישה. אדמינים של ארגונים ב-Google Workspace יכולים להגביל את הגישה להיקפים רגישים, כדי למנוע גישה של מזהי לקוח OAuth שהארגון לא סימן במפורש כמהימנים.
הסבר על השימוש בהיקפים
- בודקים את היקפי ההרשאות שהאפליקציה משתמשת בהם או שאתם רוצים להשתמש בהם. כדי למצוא את ההיקפים הקיימים, בודקים את קוד המקור של האפליקציה ומחפשים היקפים שנשלחו עם בקשות הרשאה.
- לוודא שכל היקף הרשאות שביקשתם נחוץ לפעולות המיועדות של התכונה באפליקציה, ושהוא משתמש בהרשאות המינימליות שנדרשות כדי לספק את התכונה. ל-Google API יש בדרך כלל מאמרי עזרה בדף Google Developer של המוצר, שכוללים את נקודות הקצה ואת ההיקף שנדרש כדי לקרוא לנקודת הקצה או למאפיינים ספציפיים בתוכה. למידע נוסף על היקפי הגישה הנדרשים לנקודות הקצה ל-API שהאפליקציה קוראת להן, קראו את מאמרי העזרה של נקודות הקצה האלה.
- מותר להשתמש בנתונים שמתקבלים מ-Google API רק בהתאם למדיניות של ה-API, ובאופן שמוצג למשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלה.
- במאמרי העזרה של ה-API מפורט מידע נוסף על כל היקף הרשאות, כולל הסטטוס שלו כרגיש או מוגבל.
- מצהירים על כל היקפי ההרשאות שבהם האפליקציה משתמשת בדף Data Access במסוף Cloud. היקפי ההרשאות שאתם מציינים מקובצים לקטגוריות רגישות או קטגוריות מוגבלות, כדי להדגיח אם נדרש אימות נוסף.
- מצאו את ההיקף שהכי מתאים לנתונים שבהם השילוב משתמש, הבינו את השימוש בו, ודאו שהכול עדיין פועל בסביבת בדיקה, ואז הכינו את הבקשה לאימות.
איך להתכונן לאימות
כל האפליקציות שמשתמשות בממשקי 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 שלא מוכנים לסביבת הייצור, מומלץ למחוק אותם מהפרויקט שביקשתם לאמת. אפשר לעשות את זה בדף Clients.
כדי לשלוח את החשבון לאימות, פועלים לפי השלבים הבאים:
- לוודא שהאפליקציה עומדת בדרישות של התנאים וההגבלות של Google APIs והמדיניות של Google בנושא נתוני משתמשים בשירותי API.
- במסוף Cloud, חשוב לעדכן את תפקידי הבעלים והעריכה של החשבונות שמשויכים לפרויקט, וגם את כתובת האימייל לתמיכה במשתמשים ואת פרטי הקשר של המפתחים במסך ההסכמה של OAuth. כך תוכלו לוודא שחברי הצוות הרלוונטיים יקבלו הודעה על כל דרישה חדשה.
- נכנסים לדף Branding של OAuth במסוף Cloud.
- לוחצים על הכפתור Project selector.
בתיבת הדו-שיח Select from שמופיעה, בוחרים את הפרויקט. אם אתם לא מוצאים את הפרויקט אבל אתם יודעים את מזהה הפרויקט, אתם יכולים ליצור כתובת URL בדפדפן בפורמט הבא:
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
מחליפים את [PROJECT_ID] במזהה הפרויקט שבו רוצים להשתמש.
בדף מיתוג, מזינים את פרטי המיתוג של האפליקציה, כולל שם האפליקציה, הלוגו, פרטים ליצירת קשר עם המפתח וקישורים רלוונטיים. כל שינוי שתבצעו יישמר בתור טיוטת מיתוג.
כדי להתחיל את תהליך ההערכה, לוחצים על הכפתור אימות המיתוג. הבדיקה האוטומטית מסתיימת בדרך כלל תוך כמה דקות.
אחרי שההערכה מסתיימת, בודקים את הסטטוס. אם הבדיקה תעבור בהצלחה, הסטטוס ישתנה ל-מוכן לפרסום. אם האימות האוטומטי נכשל, תוכלו לראות את הבעיות שזוהו ולתקן אותן או לבקש בדיקה ידנית.
לוחצים על הכפתור פרסום המיתוג כדי להפעיל את המיתוג החדש.
אם האפליקציה שלכם דורשת גם אימות של היקפים רגישים או מוגבלים, עברו אל מרכז האימות של OAuth כדי לעקוב אחרי סטטוס הגישה לנתונים ולספק את כל המידע הנוסף שנדרש, כמו סרטון הדגמה. שימו לב: כדי לבקש אימות לגישה לנתונים, סטטוס המיתוג שלכם צריך להיות "פורסם".
משתמשים בלחצן הוספה או הסרה של היקפים כדי להצהיר על כל ההיקפים שהאפליקציה מבקשת. קבוצה ראשונית של היקפים שנדרשים לכניסה באמצעות חשבון Google מולאה מראש בקטע היקפים לא רגישים. ההיקפים שמוסיפים מסווגים כלא רגישים, רגישים או מוגבלים.
צריך לספק עד שלושה קישורים למסמכים רלוונטיים לגבי תכונות קשורות באפליקציה.
בשלבים הבאים, מספקים את כל המידע הנוסף שנדרש לגבי האפליקציה.
- הכינו הצדקה מפורטת לכל היקף הרשאות רגיש שאתם מבקשים, והסבירו למה היקף הרשאות מצומצם יותר לא מספיק. לדוגמה: "האפליקציה שלי תשתמש ב-
https://www.googleapis.com/auth/calendarכדי להציג את נתוני יומן Google של המשתמש במסך התזמון של האפליקציה. כך המשתמשים יוכלו לנהל את לוחות הזמנים שלהם דרך האפליקציה שלי ולסנכרן את השינויים עם יומן Google שלהם". - מכינים סרטון שמדגים באופן מלא איך משתמשים יוזמים ומעניקים גישה להיקפי ההרשאות המבוקשים, ומציג בפירוט את השימוש בהיקפי ההרשאות הרגישים והמוגבלים שהוענקו באפליקציה. מעלים את הסרטון ל-YouTube Studio ומגדירים את החשיפה שלו כלא רשום. אתם צריכים לספק קישור לסרטון ההדגמה בשדה הקישור ל-YouTube.
- הציגו את תהליך הענקת הרשאת ה-OAuth שהמשתמשים יחוו, באנגלית. זה כולל את תהליך ההסכמה, ואם אתם משתמשים בכניסה באמצעות חשבון Google, גם את תהליך הכניסה.
- להראות שמסך ההסכמה של OAuth מציג את שם האפליקציה בצורה נכונה.
- מראים שסרגל הכתובות בדפדפן של מסך ההסכמה של OAuth כולל את מזהה הלקוח של OAuth של האפליקציה.
- כדי להראות איך ייעשה שימוש בנתונים, צריך להדגים את הפונקציונליות שמופעלת על ידי כל היקף הרשאות רגיש שאתם מבקשים.
- הכינו הצדקה מפורטת לכל היקף הרשאות רגיש שאתם מבקשים, והסבירו למה היקף הרשאות מצומצם יותר לא מספיק. לדוגמה: "האפליקציה שלי תשתמש ב-
אחרי שתפרסמו את המיתוג או תשלחו בקשה לגישה לנתונים, יכול להיות שצוות האמינות והבטיחות של Google יפנה אליכם באימייל כדי לבקש מידע נוסף או להנחות אתכם לגבי השלבים הבאים. כדי לבדוק אם קיבלתם בקשות למידע נוסף, חפשו את כתובות האימייל שלכם בקטע פרטים ליצירת קשר עם המפתח ובכתובת האימייל לתמיכה במסך ההסכמה ל-OAuth. אתם יכולים גם לבדוק את סטטוס הבדיקה הנוכחי של הפרויקט בדפים Branding או Verification Center, כולל אם תהליך הבדיקה מושהה בזמן שאנחנו ממתינים לתגובה שלכם.
חריגים לדרישות האימות
אם האפליקציה שלכם תשמש באחד מהתרחישים שמתוארים בקטעים הבאים, אתם לא צריכים לשלוח אותה לבדיקה.
שימוש אישי
תרחיש לדוגמה: אתם המשתמשים היחידים באפליקציה, או שמשתמשים בה רק כמה אנשים שאתם מכירים באופן אישי. יכול להיות שאתם ומספר המשתמשים המוגבל שלכם תרגישו בנוח להתקדם דרך מסך האפליקציה הלא מאומתת ולתת לחשבונות האישיים שלכם גישה לאפליקציה.
פרויקטים שמשמשים בשכבות פיתוח, בדיקה או Staging
כדי לעמוד בדרישות של מדיניות Google OAuth 2.0, מומלץ להשתמש בפרויקטים שונים לסביבות בדיקה וייצור. אנחנו ממליצים לשלוח את האפליקציה לאימות רק אם אתם רוצים שהיא תהיה זמינה לכל משתמש עם חשבון Google. לכן, אם האפליקציה נמצאת בשלבי פיתוח, בדיקה או Staging, אין צורך באימות.
אם האפליקציה נמצאת בשלבי פיתוח או בדיקה, אפשר להשאיר את Publishing Status בהגדרת ברירת המחדל Testing. ההגדרה הזו מציינת שהאפליקציה עדיין בשלבי פיתוח וזמינה רק למשתמשים שאתם מוסיפים לרשימת המשתמשים לבדיקה. אתם צריכים לנהל את רשימת חשבונות Google שמעורבים בפיתוח או בבדיקה של האפליקציה.
רק נתונים בבעלות השירות
אם האפליקציה שלכם משתמשת בחשבון שירות כדי לגשת רק לנתונים שלה, והיא לא ניגשת לנתוני משתמשים (שמקושרים לחשבון Google), אתם לא צריכים לשלוח אותה לאימות.
כדי להבין מהם חשבונות שירות, קראו את המאמר חשבונות שירות במסמכי התיעוד של Google Cloud. במאמר שימוש ב-OAuth 2.0 לאפליקציות שרת-אל-שרת מוסבר איך משתמשים בחשבון שירות.
לשימוש פנימי בלבד
המשמעות היא שרק אנשים בארגון שלכם ב-Google Workspace או ב-Cloud Identity משתמשים באפליקציה. הפרויקט צריך להיות בבעלות הארגון, ומסך ההסכמה ל-OAuth צריך להיות מוגדר לסוג משתמש פנימי. במקרה כזה, יכול להיות שהאפליקציה תצטרך אישור ממנהל החשבון הארגוני. למידע נוסף, ראו שיקולים נוספים לגבי Google Workspace.
- מידע נוסף על אפליקציות ציבוריות ופנימיות
- כדי ללמוד איך לסמן את האפליקציה כפנימית, אפשר לעיין בשאלות הנפוצות בנושא איך מסמנים את האפליקציה כפנימית בלבד?
התקנה ברמת הדומיין
אם אתם מתכננים שהאפליקציה תטרגט רק משתמשים של ארגון ב-Google Workspace או ב-Cloud Identity, ותמיד תשתמשו בהתקנה ברמת הדומיין, האפליקציה לא תדרוש אימות מותג. עם זאת, אם האפליקציה משתמשת בהיקפי הרשאות מוגבלים או רגישים, נדרש אימות אפליקציה. הסיבה לכך היא שהתקנה ברמת הדומיין מאפשרת למנהל הדומיין לתת לאפליקציות פנימיות ולאפליקציות של צד שלישי גישה לנתוני המשתמשים. רק מנהלי חשבונות ארגוניים יכולים להוסיף את האפליקציה לרשימת היתרים לשימוש בדומיינים שלהם.
בשאלה הנפוצה באפליקציה שלי יש משתמשים עם חשבונות ארגוניים מדומיין אחר של Google Workspace מוסבר איך להגדיר את האפליקציה להתקנה בכל הדומיין.