כשתהיו מוכנים לפרוס את הפתרון שהטמעתם מעבר לסביבת הפיתוח למשתמשים של האפליקציה, יכול להיות שתצטרכו לבצע פעולות נוספות כדי לעמוד בדרישות של מדיניות OAuth 2.0 של Google. במדריך הזה נסביר איך לעמוד בדרישות של הבעיות הנפוצות ביותר שמפתחים נתקלים בהן כשהם מכינים את האפליקציה לייצור. כך אפשר להגיע לקהל רחב ככל האפשר עם שגיאות מוגבלות.
- שימוש בפרויקטים נפרדים לבדיקה ולייצור
- ניהול רשימה של אנשי קשר רלוונטיים לפרויקט
- ייצוג מדויק של הזהות שלכם
- אפשר לבקש רק היקפי הרשאות שדרושים לכם
- שליחת אפליקציות ייצור שמשתמשות בהיקפים רגישים או מוגבלים לאימות
- שימוש רק בדומיינים שבבעלותכם
- אירוח דף בית לאפליקציות בסביבת הייצור
- שימוש במזהי URI מאובטחים להפניה אוטומטית ובמקורות JavaScript
שימוש בפרויקטים נפרדים לבדיקה ולייצור
לפי מדיניות OAuth של Google, נדרשים פרויקטים נפרדים לבדיקה ולייצור. חלק מהמדיניות והדרישות חלות רק על אפליקציות שפועלות בסביבת הייצור. יכול להיות שתצטרכו ליצור ולהגדיר פרויקט נפרד שכולל לקוחות OAuth שתואמים לגרסה בסביבת הייצור של האפליקציה שזמינה לכל חשבונות Google.
לקוחות Google OAuth שמשמשים בסביבת הייצור עוזרים לספק סביבה יציבה, צפויה ומאובטחת יותר לאיסוף ולאחסון נתונים, בהשוואה ללקוחות OAuth דומים שבהם בודקים או מתקנים באגים באותה אפליקציה. אפשר לשלוח את פרויקט הייצור לאימות, ולכן הוא כפוף לדרישות נוספות להיקפי API ספציפיים, שעשויות לכלול הערכות אבטחה של צד שלישי.
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- בודקים את לקוחות ה-OAuth בפרויקט הזה שעשויים להיות משויכים לרמת הבדיקה שלכם. אם רלוונטי, יוצרים לקוחות OAuth דומים ללקוחות הייצור בתוך הפרויקט בסביבת הייצור.
- מפעילים את כל ממשקי ה-API שבהם הלקוחות שלכם משתמשים.
- בודקים את ההגדרות של OAuth Consent Screen בפרויקט החדש.
לקוחות OAuth של Google שנמצאים בשימוש בסביבת הייצור לא יכולים להכיל סביבות בדיקה, מזהי URI להפניה אוטומטית או מקורות JavaScript שזמינים רק לכם או לצוות הפיתוח. הנה כמה דוגמאות:
- שרתי הבדיקה של מפתחים ספציפיים
- בדיקה או גרסאות טרום-השקה של האפליקציה
לנהל רשימה של אנשי קשר רלוונטיים לפרויקט.
יכול להיות ש-Google וממשקי ה-API הנפרדים שתפעילו יצטרכו ליצור איתכם קשר לגבי שינויים בשירותים או הגדרות חדשות שנדרשות לפרויקט וללקוחות שלו. בודקים את הרשומות של IAM בפרויקט כדי לוודא שלאנשים הרלוונטיים בצוות יש גישה לעריכת ההגדרות של הפרויקט או לצפייה בהן. יכול להיות שהחשבונות האלה יקבלו גם אימיילים לגבי שינויים נדרשים בפרויקט.
תפקיד מכיל קבוצה של הרשאות שמאפשרות לבצע פעולות ספציפיות במשאבי הפרויקט. לעורכים של הפרויקט יש הרשאות לביצוע פעולות שמשנות את המצב, כמו היכולת לבצע שינויים במסך ההסכמה של OAuth בפרויקט. בעלי פרויקטים שיש להם את כל הרשאות העריכה יכולים להוסיף או להסיר חשבונות שמשויכים לפרויקט, או למחוק את הפרויקט. בעלי הפרויקט יכולים גם לספק הקשר לגבי הסיבה להגדרת פרטי החיוב. בעלי פרויקטים יכולים להגדיר את פרטי החיוב של פרויקט שמשתמש בממשקי API בתשלום.
חשוב לעדכן את הבעלים והעורכים של הפרויקט. כדי להבטיח גישה מתמשכת לפרויקט ולתחזוקה הקשורה, אפשר להוסיף לפרויקט כמה חשבונות רלוונטיים. אנחנו שולחים אימיילים לחשבונות האלה כשיש התראות לגבי הפרויקט או עדכונים בשירותים שלנו. אדמינים ארגוניים ב-Google Cloud צריכים לוודא שכל פרויקט בארגון משויך לאיש קשר שאפשר ליצור איתו קשר. אם לא נקבל פרטים מעודכנים ליצירת קשר לגבי הפרויקט, יכול להיות שנפספס הודעות חשובות שדורשות פעולה מצידכם.
להציג את הזהות שלכם באופן מדויק
נותנים שם תקין לאפליקציה, ואם רוצים, גם לוגו שיוצג למשתמשים. פרטי המותג האלה חייבים לייצג במדויק את הזהות של האפליקציה. פרטי המיתוג של האפליקציה מוגדרים דרך OAuth Consent Screen page.
באפליקציות ייצור, צריך לאמת את פרטי המותג שמוגדרים במסך ההסכמה ל-OAuth לפני שהם מוצגים למשתמשים. יכול להיות שיהיו יותר משתמשים שיעניקו גישה לאפליקציה שלכם אחרי שהיא תשלים את תהליך אימות המותג. מידע בסיסי על האפליקציה, כולל שם האפליקציה, דף הבית, התנאים וההגבלות ומדיניות הפרטיות, מוצגים למשתמשים במסך הזכאות, כשהם יבחנו את ההרשאות הקיימות שלהם או לאדמינים ב-Google Workspace שבודקים את השימוש באפליקציה על ידי הארגון.
Google יכולה לבטל או להשעות את הגישה לשירותי Google API ולמוצרים ולשירותים אחרים של Google לאפליקציות שמציגות את הזהות שלהן בצורה שגויה או שמנסות להטעות משתמשים.
מבקשים רק את היקפי ההרשאות הנחוצים
במהלך פיתוח האפליקציה, יכול להיות שהשתמשתם בהיקף לדוגמה שמסופק על ידי ה-API כדי ליצור הוכחת היתכנות בתוך האפליקציה, כדי לקבל מידע נוסף על התכונות והפונקציונליות של ה-API. לרוב, היקפי הגישה לדוגמה מבקשים מידע רב יותר ממה שנחוץ להטמעה הסופית של האפליקציה, כי הם מספקים כיסוי מקיף של כל הפעולות האפשריות ב-API מסוים. לדוגמה, יכול להיות שההיקף לדוגמה יבקש הרשאות קריאה, כתיבה ומחיקה, בעוד שהאפליקציה שלכם זקוקה רק להרשאות קריאה. לבקש הרשאות רלוונטיות שמתמקדות במידע החיוני להטמעת האפליקציה.
בודקים את מאמרי העזרה של נקודות הקצה של ה-API שהאפליקציה שלכם קוראת אליהן, ומציינים את ההיקפים שנדרשים להן כדי לגשת לנתונים הרלוונטיים שהאפליקציה שלכם זקוקה להם. כדאי לעיין במדריכים להרשאות שמציע ה-API ולתאר את ההיקפים שלהם בפירוט רב יותר, כך שיכללו את השימושים הנפוצים ביותר. בוחרים את הגישה המינימלית ביותר לנתונים שהאפליקציה צריכה כדי להפעיל את התכונות הקשורות.
מידע נוסף על הדרישה הזו זמין בקטע בקשה להיקפי הרשאות שנחוצים לך בלבד במדיניות OAuth 2.0, ובקטע בקשה להרשאות רלוונטיות במדיניות בנושא נתוני משתמשים בשירותי Google API.
שליחת אפליקציות ייצור שמשתמשות בהיקפים רגישים או מוגבלים לאימות
היקפי גישה מסוימים מסווגים כ'רגישים' או כ'מוגבלים', ואי אפשר להשתמש בהם באפליקציות ייצור בלי בדיקה. מזינים את כל ההיקפים שבהם האפליקציה בסביבת הייצור משתמשת בהגדרה של מסך ההסכמה ל-OAuth. אם באפליקציה בסביבת הייצור נעשה שימוש בהיקפים רגישים או מוגבלים, צריך לשלוח את השימוש בהיקפים האלה לאימות לפני שכוללים את ההיקפים בבקשת ההרשאה.
שימוש רק בדומיינים שבבעלותך
תהליך האימות של מסך ההסכמה ל-OAuth ב-Google מחייב אימות של כל הדומיינים שמשויכים לדף הבית, למדיניות הפרטיות, לתנאי השירות, למזהי URI להפניה אוטומטית מורשית או למקורות JavaScript מורשים של הפרויקט. בודקים את רשימת הדומיינים שבהם האפליקציה שלכם משתמשת, שמפורטת בקטע Authorized domains (דומיינים מורשים) בכלי לעריכת מסך ההסכמה של OAuth, ומזהים דומיינים שלא בבעלותכם ולכן לא תוכלו לאמת אותם. כדי לאמת את הבעלות על הדומיינים המורשים של הפרויקט, משתמשים ב-Google Search Console. משתמשים בחשבון Google שמשויך לפרויקט API Console בתור בעלים או עורך.
אם בפרויקט שלכם נעשה שימוש בספק שירות עם דומיין משותף, מומלץ להפעיל הגדרות שיאפשרו שימוש בדומיין שלכם. ספקים מסוימים מציעים למפות את השירותים שלהם לתת-דומיין של דומיין שכבר בבעלותכם.
אירוח דף בית לאפליקציות בסביבת הייצור
לכל אפליקציית ייצור שמשתמשת ב-OAuth 2.0 חייב להיות דף בית שגלוי לכולם. משתמשים פוטנציאליים של האפליקציה עשויים להיכנס לדף הבית כדי לקבל מידע נוסף על התכונות והפונקציונליות שהאפליקציה מציעה. משתמשים קיימים יכולים לבדוק את רשימת האישורים הקיימים שלהם ולהיכנס לדף הבית של האפליקציה כדי להזכיר להם להמשיך להשתמש בהצעה שלך.
דף הבית של האפליקציה חייב לכלול תיאור של הפונקציונליות של האפליקציה, וכן קישורים למדיניות הפרטיות ולתנאים וההגבלות האופציונליים. דף הבית צריך להתקיים בדומיין מאומת שבבעלותכם.
שימוש במקור JavaScript וב-URI מאובטחים להפניה אוטומטית
לקוחות OAuth 2.0 לאפליקציות אינטרנט חייבים לאבטח את הנתונים שלהם באמצעות מזהי URI להפניה אוטומטית מסוג HTTPS ומקורות JavaScript, ולא באמצעות HTTP רגיל. Google יכולה לדחות בקשות OAuth שלא מגיעות מהקשר מאובטח או שלא טופלו.
כדאי לבדוק לאילו אפליקציות ולסקריפטים של צד שלישי עשויה להיות גישה לאסימונים ולפרטי כניסה אחרים של משתמשים שמוחזרים לדף. הגבלת הגישה למידע רגיש באמצעות מיקומי URI להפניה אוטומטית שמתמקדים באימות ובאחסון של נתוני אסימונים.
השלבים הבאים
אחרי שתבדקו שהאפליקציה עומדת בדרישות המדיניות של OAuth 2.0 שמפורטות בדף הזה, תוכלו לקרוא את המאמר שליחת בקשה לאימות המותג כדי לקבל פרטים על תהליך האימות.