אם האפליקציה מבקשת הרשאה להשתמש ב-Google APIs כדי לגשת לנתונים של משתמשי Google, ייתכן שיהיה עליך להשלים תהליך אימות לפני שתהפוך את האפליקציה לגלויה לכולם בפעם הראשונה.
השאלה אם הדרישה הזו חלה על האפליקציה תלויה בעיקר בשני גורמים:
- הסוג של נתוני המשתמש שיש לך גישה אליהם – פרטי פרופיל ציבורי, רשומות ביומן, קבצים ב-Drive, נתוני בריאות וכושר מסוימים וכו'
- רמת הגישה הדרושה לכם – קריאה בלבד, קריאה וכתיבה וכו'.
כשמשתמשים ב-OAuth 2.0 כדי לקבל הרשאה מחשבון Google לגשת לנתונים שלו, משתמשים במחרוזות שנקראות היקפים כדי לציין את סוג הנתונים שרוצים לגשת אליהם בשמו. אם האפליקציה שלך מבקשת היקפים שמסווגים כרגישים או מוגבל, כנראה שתצטרכו להשלים את תהליך האימות, אלא אם השימוש באפליקציה שלכם עומד בקריטריונים לחריגה.
דוגמאות להיקפים רגישים כוללות קריאת אירועים שמאוחסנים ביומן Google, אחסון איש קשר חדש ב'אנשי קשר מחשבון Google' או מחיקה של סרטון ב-YouTube. למידע נוסף על ההיקפים הזמינים והסיווגים שלהם, אפשר לעיין במסמכי התיעוד של נקודות הקצה של ה-API שהאפליקציה קריאות, וכן בכל מדריך הרשאה שקשור להרשאות של ה-API.
עליכם לבקש היקפים שדורשים את רמת הגישה המינימלית לנתוני משתמשים שנדרשים כדי לספק את הפונקציונליות הזו. לדוגמה, אפליקציה שקוראת רק נתונים לא יכולה לבקש גישה לקריאה, לכתיבה ולמחיקה של תוכן כאשר היקף מצומצם יותר זמין ל-API ולנקודות הקצה הקשורות אליו. יש להשתמש בנתונים שהתקבלו מ-Google API אך ורק בהתאם למדיניות של ה-API ובהתאם לאופן שבו את/ה מייצג/ת את המשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלך.
חשוב להביא בחשבון את הזמן הדרוש להשלמת תהליך האימות בתוכנית ההשקה של האפליקציה או עבור תכונות חדשות שדורשות היקף חדש. בדרך כלל, תהליך האימות של ההיקף הרגיש נמשך 3-5 ימי עסקים. לתשומת ליבך, יכול להיות שהאפליקציה שלך תוכל להשלים את אימות המותג בתור קבוצת משנה של בקשת האימות להיקף רגיש.
הסבר על היקפים רגישים
היקפי הרשאות רגישים מחייבים בדיקה על ידי Google לפני שחשבון Google כלשהו יוכל להעניק גישה. אדמינים ארגוניים ב-Google Workspace יכולים להגביל את הגישה להיקפים רגישים, כדי למנוע גישה לפי מזהי לקוח ב-OAuth שהארגון לא מסמן באופן מפורש כמהימן.
הסבר על השימוש בהיקף
- בודקים את ההיקפים שבהם האפליקציה משתמשת או שרוצים להשתמש בה. כדי לברר מהו השימוש הנוכחי שלך בהיקף, יש לבדוק את קוד המקור של האפליקציה ולחפש היקפים שנשלחו עם בקשות הרשאה.
- לוודא שכל היקף ההרשאות המבוקש נדרש עבור הפעולות הרצויות של התכונה באפליקציה, ושהוא משתמש בהרשאה המינימלית הנדרשת כדי לספק את התכונה. בדרך כלל, ב דף של Google Developers של המוצר ב-Google API מופיעים המסמכים שמתייחסים לנקודות הקצה של המוצר, שכוללים את ההיקף שנדרש כדי לקרוא לנקודת הקצה או לנכסים ספציפיים שכלולים בה. כדי לקבל מידע נוסף על היקפי הגישה הנדרשים לנקודות הקצה של ה-API שהאפליקציה שלך מפעילה, אפשר לקרוא את מסמכי התיעוד של נקודות הקצה האלה.
- יש להשתמש בנתונים שהתקבלו מ-Google API אך ורק בהתאם למדיניות של ה-API ובהתאם לאופן שבו את/ה מייצג/ת את המשתמשים בפעולות של האפליקציה ובמדיניות הפרטיות שלך.
- במסמכי התיעוד של ה-API ניתן לקבל מידע נוסף על כל היקף, כולל הסטטוס sensitive or restricted הפוטנציאלי שלו.
- יש להצהיר על כל ההיקפים שהאפליקציה משתמשת בהם בדף היקפי ההגדרות של API Console מסך ההסכמה של OAuth. היקפי ההרשאות שציינת מקובצים לפי קטגוריות רגישות או מוגבלות כדי להדגיש את הצורך לבצע אימות נוסף.
- צריך למצוא את ההיקף המתאים ביותר לנתונים המשמשים את השילוב, להבין את אופן השימוש בו, לוודא שהכול עדיין פועל בסביבת הבדיקה ולהתכונן לשליחה לאימות.
איך מתכוננים לאימות
כל האפליקציות שמשתמשות ב-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.
- יש לספק עד שלושה קישורים לכל תיעוד רלוונטי לגבי תכונות קשורות באפליקציה.
-
בשלבים הבאים, צריך לספק כל מידע נוסף שנדרש לגבי האפליקציה.
- Prepare a detailed justification for each requested sensitive scope, as well as an explanation
for why a narrower scope isn't sufficient. For example: "My app will use
https://www.googleapis.com/auth/calendarto show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar." -
Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.
- Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
- Show that the OAuth consent screen correctly displays the App Name.
- Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
- To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
- Prepare a detailed justification for each requested sensitive scope, as well as an explanation
for why a narrower scope isn't sufficient. For example: "My app will use
- אם הגדרת האפליקציה שסיפקת דורשת אימות, יש לך אפשרות לשלוח את האפליקציה לאימות. ממלאים את שדות החובה ולוחצים על 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 מוסבר איך להגדיר את האפליקציה כ'התקנה בכל הדומיין'.