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