כשתהיו מוכנים לפרוס את הפתרון שהטמעתם מעבר לסביבת הפיתוח למשתמשים של האפליקציה, יכול להיות שתצטרכו לבצע פעולות נוספות כדי לעמוד בדרישות של מדיניות OAuth 2.0 של Google. במדריך הזה נסביר איך לעמוד בדרישות של הבעיות הנפוצות ביותר שמפתחים נתקלים בהן כשהם מכינים את האפליקציה לפריסה בסביבת הייצור. כך תוכלו להגיע לקהל הגדול ביותר האפשרי עם מספר מוגבל של שגיאות.
- שימוש בפרויקטים נפרדים לבדיקה ולייצור
- ניהול רשימה של אנשי קשר רלוונטיים לפרויקט
- ייצוג מדויק של הזהות שלכם
- בקשו רק את היקפי הגישה הנחוצים לכם
- שליחת אפליקציות ייצור שמשתמשות בהיקפים רגישים או מוגבלים לאימות
- שימוש רק בדומיינים שבבעלותכם
- אירוח דף בית לאפליקציות בסביבת הייצור
- שימוש במקורות JavaScript וב-URI להפניה אוטומטית מאובטחים
שימוש בפרויקטים נפרדים לבדיקה ולייצור
לפי מדיניות OAuth של Google, נדרשים פרויקטים נפרדים לבדיקה ולייצור. חלק מהמדיניות והדרישות חלות רק על אפליקציות שפועלות בסביבת הייצור. יכול להיות שתצטרכו ליצור ולהגדיר פרויקט נפרד שכולל לקוחות OAuth שתואמים לגרסה בסביבת הייצור של האפליקציה שזמינה לכל חשבונות Google.
לקוחות Google OAuth שמשמשים בסביבת הייצור עוזרים לספק סביבה יציבה, צפויה ומאובטחת יותר לאיסוף ולאחסון נתונים, בהשוואה ללקוחות OAuth דומים שבהם בודקים או מתקנים באגים באותה אפליקציה. אפשר לשלוח את פרויקט הייצור לאימות, ולכן הוא כפוף לדרישות נוספות להיקפי API ספציפיים, שעשויות לכלול הערכות אבטחה של צד שלישי.
- בודקים את לקוחות ה-OAuth בפרויקט הזה שעשויים להיות משויכים לרמת הבדיקה שלכם. אם רלוונטי, יוצרים לקוחות OAuth דומים ללקוחות הייצור בתוך הפרויקט בסביבת הייצור.
- מפעילים את כל ממשקי ה-API שבהם הלקוחות שלכם משתמשים.
- בודקים את ההגדרות של מסך ההסכמה ל-OAuth בפרויקט החדש ב של . .
לקוחות 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.
שליחת אפליקציות ייצור שמשתמשות בהיקפים רגישים או מוגבלים לאימות
היקפי גישה מסוימים מסווגים כ'רגישים' או כ'מוגבלים', ואי אפשר להשתמש בהם באפליקציות ייצור בלי בדיקה. מזינים את כל ההיקפים שבהם האפליקציה בסביבת הייצור משתמשת בהגדרה של מסך ההסכמה ל-OAuth. אם באפליקציה בסביבת הייצור נעשה שימוש בהיקפים רגישים או מוגבלים, צריך לשלוח את השימוש בהיקפים האלה לאימות לפני שכוללים את ההיקפים בבקשת ההרשאה.
להשתמש רק בדומיינים שבבעלותכם
תהליך האימות של מסך ההסכמה ב-OAuth של Google מחייב אימות של כל הדומיינים שמשויכים לדף הבית, למדיניות הפרטיות, לתנאי השירות, למזהי URI להפניה אוטומטית מורשית או למקורות JavaScript מורשים של הפרויקט. בודקים את רשימת הדומיינים שבהם האפליקציה משתמשת, שמפורטת בקטע Authorized domains (דומיינים מורשים) בעורך מסך ההסכמה של OAuth, ומזהים דומיינים שלא בבעלותכם ולכן לא תוכלו לאמת אותם. כדי לאמת את הבעלות על הדומיינים המורשים של הפרויקט, משתמשים ב-Google Search Console. משתמשים בחשבון Google שמשויך לפרויקט בתור בעלים או עורך.
אם בפרויקט שלכם נעשה שימוש בספק שירות עם דומיין משותף, מומלץ להפעיל הגדרות שיאפשרו שימוש בדומיין שלכם. ספקים מסוימים מציעים למפות את השירותים שלהם לתת-דומיין של דומיין שכבר בבעלותכם.
אירוח דף בית לאפליקציות בסביבת הייצור
לכל אפליקציית ייצור שמשתמשת ב-OAuth 2.0 חייב להיות דף בית שגלוי לכולם. משתמשים פוטנציאליים של האפליקציה עשויים להיכנס לדף הבית כדי לקבל מידע נוסף על התכונות והפונקציונליות שהאפליקציה מציעה. משתמשים קיימים עשויים לבדוק את רשימת המענקים הקיימים שלהם ולבקר בדף הבית של האפליקציה שלכם כתזכורת לשימוש המתמשך שלהם במוצר או בשירות שלכם.
דף הבית של האפליקציה חייב לכלול תיאור של הפונקציונליות של האפליקציה, וכן קישורים למדיניות הפרטיות ולתנאים וההגבלות האופציונליים. דף הבית צריך להתקיים בדומיין מאומת שבבעלותכם.
שימוש במקור JavaScript וב-URI מאובטחים להפניה אוטומטית
לקוחות OAuth 2.0 לאפליקציות אינטרנט חייבים לאבטח את הנתונים שלהם באמצעות מזהי URI להפניה אוטומטית מסוג HTTPS ומקורות JavaScript, ולא באמצעות HTTP רגיל. Google יכולה לדחות בקשות OAuth שלא מגיעות מהקשר מאובטח או לא מנותבות אליו.
כדאי לבדוק לאילו אפליקציות ולסקריפטים של צד שלישי עשויה להיות גישה לאסימונים ולפרטי כניסה אחרים של משתמשים שמוחזרים לדף. הגבלת הגישה למידע אישי רגיש באמצעות מיקומי URI להפניה אוטומטית שמתמקדים באימות ובאחסון של נתוני אסימונים.
השלבים הבאים
אחרי שתבדקו שהאפליקציה עומדת בדרישות המדיניות של OAuth 2.0 שמפורטות בדף הזה, תוכלו לקרוא את המאמר שליחת בקשה לאימות המותג כדי לקבל פרטים על תהליך האימות.