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