בדף הזה מפורטות כמה שיטות מומלצות כלליות לשילוב עם OAuth 2.0. כדאי ליישם את השיטות המומלצות האלה בנוסף להנחיות הספציפיות לסוג האפליקציה ולפלטפורמת הפיתוח שלכם. כדאי לעיין גם בהמלצות להכנת האפליקציה לסביבת הייצור ובמדיניות של Google בנושא OAuth 2.0.
טיפול מאובטח בפרטי הכניסה של הלקוח
פרטי הכניסה של לקוח OAuth מזהים את הזהות של האפליקציה שלכם, ולכן חשוב לטפל בהם בזהירות. אחסנו את פרטי הכניסה האלה רק באחסון מאובטח, למשל באמצעות כלי לניהול סודות כמו Google Cloud Secret Manager. אל תקודדו את פרטי הכניסה באופן קשיח, אל תעלו אותם למאגר קוד ואל תפרסמו אותם באופן ציבורי.
טיפול מאובטח בטוקנים של משתמשים
אסימוני משתמשים כוללים גם אסימוני רענון וגם אסימוני גישה שבהם נעשה שימוש באפליקציה שלכם. אחסון אסימונים בצורה מאובטחת במנוחה, ולעולם לא להעביר אותם כטקסט פשוט. משתמשים במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם, כמו Keystore ב-Android, Keychain Services ב-iOS וב-macOS, או Credential Locker ב-Windows.
לבטל את האסימונים ברגע שאין בהם יותר צורך ולמחוק אותם באופן סופי מהמערכות.
בנוסף, כדאי להשתמש בשיטות המומלצות הבאות בפלטפורמה שלכם:
- באפליקציות בצד השרת שמאחסנות טוקנים של משתמשים רבים, צריך להצפין אותם במצב מנוחה ולוודא שמאגר הנתונים לא נגיש לציבור באינטרנט.
- באפליקציות מקומיות למחשב, מומלץ מאוד להשתמש בפרוטוקול Proof Key for Code Exchange (PKCE) כדי לקבל קודי הרשאה שאפשר להמיר לאסימוני גישה.
טיפול בביטול של טוקן רענון ובתפוגה שלו
אם האפליקציה שלכם ביקשה אסימון רענון לגישה אופליין, אתם צריכים לטפל גם בביטול או בפקיעת התוקף שלו. יכול להיות שאסימונים יבוטלו מסיבות שונות, למשל אם תוקפם פג או שהמשתמש או תהליך אוטומטי ביטלו את הגישה של האפליקציות שלכם. במקרה כזה, חשוב לחשוב היטב איך האפליקציה צריכה להגיב, כולל הצגת בקשה למשתמש בכניסה הבאה שלו או ניקוי הנתונים שלו. כדי לקבל הודעה על ביטול טוקן, צריך לבצע שילוב עם השירות הגנה על כל החשבונות.
שימוש בהרשאה מצטברת
כדי לבקש את היקפי ההרשאות המתאימים ל-OAuth כשנדרשת פונקציונליות מסוימת באפליקציה, צריך להשתמש בהרשאה מצטברת.
לא מומלץ לבקש גישה לנתונים כשהמשתמש מאמת את עצמו בפעם הראשונה, אלא אם זה חיוני לפונקציונליות העיקרית של האפליקציה. במקום זאת, כדאי לבקש רק את היקפי ההרשאות הספציפיים שנדרשים למשימה, בהתאם לעיקרון של בחירת היקפי ההרשאות הכי קטנים והכי מוגבלים שאפשר.
תמיד צריך לבקש היקפי הרשאות בהקשר כדי לעזור למשתמשים להבין למה האפליקציה מבקשת גישה ואיך הנתונים ישמשו.
לדוגמה, האפליקציה שלכם יכולה לפעול לפי המודל הבא:
- המשתמש מאומת באפליקציה שלכם
- לא נדרשים היקפי הרשאות נוספים. האפליקציה מספקת פונקציונליות בסיסית שמאפשרת למשתמש לחקור ולהשתמש בתכונות שלא דורשות נתונים נוספים או גישה נוספת.
- המשתמש בוחר תכונה שנדרשת גישה לנתונים נוספים
- האפליקציה שולחת בקשת הרשאה להיקף ה-OAuth הספציפי הזה שנדרש לתכונה הזו. אם התכונה הזו דורשת כמה היקפי הרשאה, כדאי לפעול לפי השיטות המומלצות שבהמשך.
- אם המשתמש ידחה את הבקשה, האפליקציה תשבית את התכונה ותספק למשתמש הקשר נוסף כדי לבקש גישה שוב.
איך מטפלים בהסכמה למספר היקפי גישה
כשמבקשים כמה היקפים בבת אחת, יכול להיות שהמשתמשים לא יאשרו את כל היקפי ה-OAuth שביקשתם. האפליקציה צריכה לטפל בדחייה של היקפי הרשאות על ידי השבתה של פונקציונליות רלוונטית.
אם הפונקציונליות הבסיסית של האפליקציה דורשת כמה היקפי הרשאות, צריך להסביר זאת למשתמש לפני שמבקשים ממנו להביע הסכמה.
אפשר להציג למשתמש את ההנחיה שוב רק אחרי שהוא מציין באופן ברור כוונה להשתמש בתכונה הספציפית שדורשת את ההיקף. האפליקציה צריכה לספק למשתמש הקשר רלוונטי והצדקה לפני בקשת היקפי OAuth.
מומלץ לצמצם את מספר ההיקפים שהאפליקציה מבקשת בבת אחת. במקום זאת, משתמשים בהרשאה מצטברת כדי לבקש היקפי גישה בהקשר של תכונות ופונקציונליות.
שימוש בדפדפנים מאובטחים
באינטרנט, בקשות הרשאה של OAuth 2.0 חייבות להישלח רק מדפדפני אינטרנט עם תכונות מלאות. בפלטפורמות אחרות, חשוב לבחור את סוג לקוח ה-OAuth הנכון ולשלב את OAuth בהתאם לפלטפורמה. אל תפנו את הבקשה דרך סביבות גלישה מוטמעות, כולל תצוגות אינטרנט בפלטפורמות לנייד, כמו WebView ב-Android או WKWebView ב-iOS. במקום זאת, צריך להשתמש בספריות OAuth מקוריות או בכניסה באמצעות חשבון Google בפלטפורמה.
יצירה והגדרה ידניות של לקוחות OAuth
כדי למנוע שימוש לרעה, אי אפשר ליצור או לשנות לקוחות OAuth באופן אוטומטי. אתם צריכים להשתמש במסוף Google Developers כדי לאשר באופן מפורש את התנאים וההגבלות, להגדיר את לקוח OAuth ולהתכונן לאימות OAuth.
לזרימות עבודה אוטומטיות, כדאי להשתמש במקום זאת בחשבונות שירות.
הסרה של לקוחות OAuth שלא בשימוש
מומלץ לבצע ביקורת באופן קבוע על לקוחות OAuth 2.0 ולמחוק באופן יזום לקוחות שכבר לא נדרשים על ידי האפליקציה או שהפכו ללא רלוונטיים. השארת לקוחות לא בשימוש מוגדרים מייצגת סיכון אבטחה פוטנציאלי, כי יכול להיות שייעשה שימוש לרעה בלקוח אם פרטי הכניסה של הלקוח ייפגעו.
כדי לצמצם עוד יותר את הסיכונים מלקוחות לא פעילים, לקוחות OAuth 2.0 שלא היו פעילים במשך שישה חודשים נמחקים אוטומטית.
השיטה המומלצת היא לא לחכות למחיקה אוטומטית, אלא להסיר באופן יזום לקוחות שלא נמצאים בשימוש. השיטה הזו מצמצמת את שטח הפנים של האפליקציה להתקפה ומבטיחה שמירה על היגיינת אבטחה טובה.