במדריך הזה מוסבר איך לפתור את הבעיות הנפוצות ביותר שנתקלים בהן מפתחים כשמכינים את האפליקציה לייצור.
סקירה כללית
כשמוכנים לפרוס את הפתרון שהוטמע מעבר לסביבת הפיתוח למשתמשי האפליקציה, יכול להיות שיהיה צורך לבצע שלבים נוספים כדי לעמוד בדרישות מדיניות OAuth 2.0 של Google. במדריך הזה נסביר איך לפעול בהתאם לדרישות ולפתור את הבעיות הנפוצות ביותר שנתקלים בהן מפתחים כשמכינים את האפליקציה לייצור. כך תוכלו להגיע לקהל הגדול ביותר האפשרי עם מספר שגיאות מוגבל.
- שימוש בפרויקטים נפרדים לבדיקה ולייצור
- ניהול רשימה של אנשי קשר רלוונטיים לפרויקט
- הצגה מדויקת של הזהות שלכם
- בקשו רק הרשאות ספציפיות שאתם צריכים
- שליחת אפליקציות בייצור שמשתמשות בהיקפי הרשאות לא רגישים או לא מוגבלים לצורך אימות
- שימוש רק בדומיינים שבבעלותכם
- אירוח דף הבית של אפליקציות בסביבת הייצור
- שימוש ב-URI מאובטח להפניה אוטומטית ובמקורות JavaScript
שימוש בפרויקטים נפרדים לבדיקה ולייצור
מדיניות OAuth של Google מחייבת להשתמש בפרויקטים נפרדים לבדיקות ולייצור. חלק מהמדיניות והדרישות חלות רק על אפליקציות בסביבת הייצור. יכול להיות שתצטרכו ליצור ולהגדיר פרויקט נפרד שכולל לקוחות OAuth שתואמים לגרסת הייצור של האפליקציה שזמינה לכל חשבונות Google.
לקוחות Google OAuth שמשמשים בסביבת ייצור עוזרים לספק סביבה יציבה, צפויה ומאובטחת יותר לאיסוף ולאחסון נתונים, בהשוואה ללקוחות OAuth דומים שבודקים או מנפים באגים באותה אפליקציה. פרויקט הייצור שלכם יכול להישלח לאימות, ולכן הוא כפוף לדרישות נוספות לגבי היקפי הרשאות ספציפיים של API, שעשויות לכלול הערכות אבטחה של צד שלישי.
- עוברים אל Google API Console. לוחצים על יצירת פרויקט, מזינים שם ולוחצים על יצירה.
- בודקים את לקוחות ה-OAuth בפרויקט הזה שאולי משויכים לרמת הבדיקה שלכם. אם רלוונטי, יוצרים לקוחות OAuth דומים ללקוחות הייצור בתוך פרויקט הייצור.
- מפעילים את כל ממשקי ה-API שהלקוחות משתמשים בהם.
- בודקים את הגדרת תצורה של מסך ההסכמה ל-OAuth עבור הפרויקט החדש בדף המיתוג ב-Cloud Console.
לקוחות Google OAuth שמשמשים בסביבת ייצור לא יכולים להכיל סביבות בדיקה, כתובות URI להפניה אוטומטית או מקורות JavaScript שזמינים רק לכם או לצוות הפיתוח שלכם. הנה כמה דוגמאות:
- שרתי הבדיקה של מפתחים ספציפיים
- בדיקת גרסאות טרום-השקה של האפליקציה
לשמור רשימה של אנשי קשר רלוונטיים לפרויקט
יכול להיות ש-Google וממשקי ה-API שאתם מפעילים יצטרכו ליצור איתכם קשר לגבי שינויים בשירותים שלה או לגבי הגדרות חדשות שנדרשות בפרויקט ובלקוחות שלו. כדאי לבדוק את רשימות IAM של הפרויקט כדי לוודא שלאנשים הרלוונטיים בצוות יש גישה לעריכה או לצפייה בהגדרות הפרויקט. יכול להיות שגם החשבונות האלה יקבלו אימיילים לגבי שינויים שנדרשים בפרויקט.
תפקיד מכיל קבוצה של הרשאות שמאפשרות לבצע פעולות ספציפיות במשאבי הפרויקט. לעורכי פרויקטים יש הרשאות לפעולות שמשנות מצבים, כמו היכולת לבצע שינויים במסך ההסכמה של OAuth בפרויקט. בעלי פרויקטים שיש להם את כל הרשאות העריכה יכולים להוסיף או להסיר חשבונות שמשויכים לפרויקט, או למחוק את הפרויקט. בעלי הפרויקט יכולים גם לספק הקשר לגבי הסיבה להגדרת פרטי החיוב. בעלי פרויקטים יכולים להגדיר פרטי חיוב לפרויקט שמשתמש בממשקי API בתשלום.
חשוב לעדכן את הבעלים והעורכים של הפרויקט. כדי להבטיח גישה רציפה לפרויקט ולתחזוקה שלו, אפשר להוסיף לפרויקט כמה חשבונות רלוונטיים. אנחנו שולחים אימיילים לחשבונות האלה כשיש התראות לגבי הפרויקט או עדכונים בשירותים שלנו. אדמינים בארגון ב-Google Cloud צריכים לוודא שכל פרויקט בארגון משויך לאיש קשר שאפשר להגיע אליו. אם לא יהיו לנו פרטים עדכניים ליצירת קשר לגבי הפרויקט, יכול להיות שתפספסו הודעות חשובות שדורשות פעולה מצדכם.
לייצג את הזהות שלכם בצורה מדויקת
צריך לספק שם אפליקציה תקין, ואפשר גם לוגו שיוצג למשתמשים. פרטי המותג האלה צריכים לייצג בצורה מדויקת את הזהות של האפליקציה. פרטי המיתוג של האפליקציה מוגדרים בדף המיתוג של OAuth.
באפליקציות שמוכנות להפצה, פרטי המותג שמוגדרים במסך ההסכמה ל-OAuth חייבים לעבור אימות לפני שהם מוצגים למשתמשים. יכול להיות שמשתמשים יסכימו להעניק גישה לאפליקציה שלכם אחרי שהיא תעבור אימות מותג. המשתמשים יכולים לראות את פרטי האפליקציה הבסיסיים, כולל שם האפליקציה, דף הבית, התנאים וההגבלות ומדיניות הפרטיות, במסך ההרשאות, כשהם בודקים את ההרשאות הקיימות שלהם או כשמנהלי Google Workspace בודקים את השימוש באפליקציה בארגון שלהם.
Google יכולה לבטל או להשעות את הגישה לשירותי Google API ולמוצרים ולשירותים אחרים של Google לאפליקציות שמציגות זהות שקרית או שמנסות להטעות משתמשים.
שולחים בקשות רק להרשאות ספציפיות שנדרשות
במהלך פיתוח האפליקציה, יכול להיות שהשתמשתם בהיקף לדוגמה שסופק על ידי ה-API כדי ליצור הוכחת היתכנות באפליקציה, כדי לקבל מידע נוסף על התכונות והפונקציונליות של ה-API. היקפי הגישה לדוגמה האלה מבקשים לעיתים קרובות יותר מידע ממה שנדרש להטמעה הסופית של האפליקציה, כי הם מספקים כיסוי מקיף של כל הפעולות האפשריות עבור API מסוים. לדוגמה, יכול להיות שהיקף ההרשאות לדוגמה יבקש הרשאות קריאה, כתיבה ומחיקה, בזמן שהאפליקציה שלכם דורשת רק הרשאות קריאה. מבקשים הרשאות רלוונטיות שמוגבלות למידע הקריטי שנדרש להטמעת האפליקציה.
בודקים את מסמכי העזר של נקודות הקצה של ה-API שאליהן האפליקציה מתקשרת, ורושמים את ההיקפים שנדרשים כדי לגשת לנתונים הרלוונטיים שהאפליקציה צריכה. צריך לעיין במדריכי ההרשאות שמוצעים על ידי ה-API ולתאר את ההיקפים שלהם בפירוט רב יותר, כדי לכלול את השימוש הנפוץ ביותר. צריך לבחור את הגישה המינימלית לנתונים שהאפליקציה צריכה כדי להפעיל את התכונות הרלוונטיות.
מידע נוסף על הדרישה הזו זמין בקטע בקשת היקפי הרשאות שדרושים בלבד במדיניות בנושא OAuth 2.0, וגם בקטע בקשת הרשאות רלוונטיות במדיניות בנושא נתוני משתמשים של שירותי Google API.
שליחת אפליקציות לייצור שמשתמשות בהיקפי הרשאות לא רגישים או לא מוגבלים לצורך אימות
במהלך אימות המשתמש, התכונה 'כניסה באמצעות חשבון Google' לא מבקשת היקפי הרשאות רגישים ומוגבלים. אם האפליקציה שלך משתמשת בכניסה באמצעות חשבון Google רק לצורך אימות, עליך לשלוח את האפליקציה לאימות המותג. אפשר לשלוח בקשה לאימות במסוף Google Cloud מדף המיתוג. האימות הזה נדרש כדי להציג במסך ההסכמה רכיבי מיתוג של האפליקציה, כולל השם, הלוגו, מדיניות הפרטיות, התנאים וההגבלות וההיקפים.
מומלץ מאוד לוודא שהאפליקציה פועלת בהתאם להנחיות הרשמיות למיתוג בנוגע למיקום לחצן הכניסה.
שימוש רק בדומיינים שבבעלותכם
תהליך האימות של מסך ההסכמה ל-OAuth של Google מחייב אימות של כל הדומיינים שמשויכים לדף הבית של הפרויקט, למדיניות הפרטיות, לתנאים ולהגבלות, לכתובות ה-URI המורשות להפניה או למקורות ה-JavaScript המורשים. מעיינים ברשימת הדומיינים שבהם האפליקציה משתמשת, שמופיעה בסיכום בקטע דומיינים מורשים בכלי לעריכת מסך ההסכמה של OAuth, ומזהים דומיינים שאינם בבעלותכם ולכן לא תוכלו לאמת אותם. כדי לאמת את הבעלות על הדומיינים המורשים של הפרויקט, משתמשים ב-Google Search Console. משתמשים בחשבון Google שמקושר לפרויקט ב-קונסולה לממשקי API בתור בעלים או עורך.
אם בפרויקט שלכם נעשה שימוש בספק שירותים עם דומיין משותף, מומלץ להפעיל הגדרות שיאפשרו שימוש בדומיין שלכם. חלק מהספקים מציעים למפות את השירותים שלהם לתת-דומיין של דומיין שכבר בבעלותכם.
אירוח דף בית לאפליקציות בסביבת הייצור
לכל אפליקציית ייצור שמשתמשת ב-OAuth 2.0 צריך להיות דף בית שנגיש לכולם. משתמשים פוטנציאליים של האפליקציה שלכם עשויים להיכנס לדף הבית כדי לקבל מידע נוסף על התכונות והפונקציונליות שהאפליקציה מציעה. משתמשים קיימים יכולים לעיין ברשימת ההרשאות הקיימות שלהם ולעבור לדף הבית של האפליקציה כדי להיזכר שהם ממשיכים להשתמש במוצר שלכם.
דף הבית של האפליקציה צריך לכלול תיאור של הפונקציונליות של האפליקציה, וגם קישורים למדיניות הפרטיות ולתנאים ולהגבלות (אם יש). דף הבית צריך להתקיים בדומיין מאומת שנמצא בבעלותכם.
שימוש ב-URI מאובטח להפניה אוטומטית ובמקורות JavaScript
לקוחות OAuth 2.0 לאפליקציות אינטרנט חייבים לאבטח את הנתונים שלהם באמצעות מזהי URI להפניה אוטומטית של HTTPS ומקורות JavaScript, ולא באמצעות HTTP רגיל. Google יכולה לדחות בקשות OAuth שלא מגיעות מהקשר בטוח או שלא נפתרות בהקשר בטוח.
כדאי לחשוב אילו אפליקציות וסקריפטים של צד שלישי עשויים לקבל גישה לטוקנים ולפרטי כניסה אחרים של משתמשים שמוחזרים לדף שלכם. הגבלת הגישה למידע אישי רגיש באמצעות מיקומי URI להפניה אוטומטית שמוגבלים לאימות ולאחסון של נתוני טוקן.
השלבים הבאים
אחרי שמוודאים שהאפליקציה עומדת בדרישות המדיניות בנושא OAuth 2.0 שמופיעות בדף הזה, אפשר לעיין במאמר שליחת בקשה לאימות המותג כדי לקבל פרטים על תהליך האימות.