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