בדף הזה מפורטות כמה שיטות מומלצות כלליות לשילוב עם 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 שלא היו פעילים במשך שישה חודשים נמחקים באופן אוטומטי.
מומלץ לא להמתין למחיקה האוטומטית, אלא להסיר באופן יזום לקוחות שלא בשימוש. השיטה הזו מקטינה את שטח הפנים של האפליקציה להתקפה ומבטיחה סטנדרטים טובים של אבטחה.