שיטות מומלצות

טיפול מאובטח בפרטי הכניסה של הלקוח

פרטי הכניסה של לקוח OAuth מזהים את האפליקציה שלכם, וצריך לטפל בהם בזהירות. אחסנו את פרטי הכניסה האלה רק באחסון מאובטח, למשל באמצעות מנהל סודות כמו Google Cloud Secret Manager. אל תטמיעו את פרטי הכניסה בקוד, אל תשלחו אותם למאגר המקורות של הקוד ואל תפרסמו אותם באופן ציבורי.

טיפול מאובטח בטוקנים של משתמשים

טוקנים של משתמשים כוללים גם טוקני רענון וגם טוקני גישה שמשמשים את האפליקציה. אחסנו את האסימונים באופן מאובטח במצב מנוחה ואל תעבירו אותם כטקסט פשוט. השתמשו במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם, כמו Keystore ב-Android,‏ Keychain Services ב-iOS וב-macOS או Credential Locker ב-Windows.

לבטל טוקנים ברגע שאין בהם יותר צורך ולמחוק אותם באופן סופי מהמערכות.

בנוסף, כדאי לפעול לפי השיטות המומלצות הבאות:

• באפליקציות בצד השרת שמאחסנות אסימונים של משתמשים רבים, צריך להצפין אותם במצב מנוחה ולוודא שמאגר הנתונים לא נגיש באופן ציבורי באינטרנט.
• באפליקציות למחשב, מומלץ מאוד להשתמש בפרוטוקול Proof Key for Code Exchange‏ (PKCE) כדי לקבל קודי הרשאה שאפשר להחליף בטוקני גישה.

אסימונים מוגבלים לשולח עם DPoP

כדי להגן על האפליקציה מפני גניבת טוקנים והתקפות של הפעלה חוזרת, כדאי להגביל את השולח של הטוקנים באמצעות DPoP (הוכחת בעלות). כל גורם שמיירט טוקנים רגילים למוכ"ז יכול להשתמש בהם, אבל טוקנים של DPoP קשורים באופן קריפטוגרפי לזוג מפתחות ייחודי שנוצר על ידי הלקוח ונמצא אצלו.

כשמשתמשים ב-DPoP, הלקוח מציג הוכחה (אסימון אינטרנט חתום ב-JSON) לנקודת הקצה של האסימון כשהוא מבקש או מרענן אסימונים. ההוכחה הזו מראה שהלקוח מחזיק במפתח הפרטי שתואם למפתח הציבורי שקשור לאסימון. אם טוקן רענון שקשור ל-DPoP דולף, תוקף לא יכול להפעיל אותו מחדש בלי המפתח הפרטי הזה.

‫DPoP פועל לצד PKCE כדי לספק הגנה מקיפה:

• ‫PKCE מגן על קוד ההרשאה במהלך תהליך ההפניה האוטומטית הראשוני.
• ‫DPoP מגן על טוקן הרענון לטווח ארוך, ומונע התקפות של הפעלה חוזרת אם הוא נחשף.

מומלץ מאוד להשתמש ב-DPoP אם האפליקציה שלכם:

• פועלת כאפליקציה מותקנת או כאפליקציה למחשב (או כאפליקציית דף יחיד שמשויכת לשרת Backend-for-Frontend), שבה טוקני הרענון עלולים להיות חשופים יותר לזליגת נתונים.
• גישה למידע אישי רגיש במיוחד או לממשקי API בעלי ערך גבוה, שבהם ההשפעה של דליפת טוקנים היא משמעותית.
• צריך לעמוד בתקני תאימות או אבטחה מחמירים שמחייבים שימוש בטוקנים שמוגבלים לשולח.

הוראות מפורטות ליצירת הוכחות DPoP ולבקשת אסימונים שקשורים ל-DPoP זמינות במדריך להטמעת DPoP.

שימוש בפרמטר state

לפני שמטפלים בתגובה של OAuth 2.0, צריך לוודא שהערך של state שהתקבל מ-Google תואם לערך של state שנשלח בבקשת ההרשאה. הפרמטר state צריך להיות ערך ייחודי שלא ניתן לנחש, שנוצר על ידי האפליקציה.

השימוש בפרמטר state עוזר לוודא שהמשתמש, ולא סקריפט זדוני, מבצע את הבקשה, ומפחית את הסיכון למתקפות זיוף של בקשות בין אתרים (CSRF).

טיפול בביטול ובתפוגה של טוקן רענון

אם האפליקציה ביקשה אסימון רענון לגישה אופליין, צריך גם לטפל במקרים שבהם האסימון לא תקף או שתוקפו פג. יכול להיות שהאסימונים בוטלו מסיבות שונות, למשל, יכול להיות שהתוקף שלהם פג או שהמשתמש או תהליך אוטומטי ביטלו את הגישה של האפליקציות. במקרה כזה, חשוב לשקול היטב איך האפליקציה צריכה להגיב, כולל הצגת בקשה למשתמש בכניסה הבאה שלו או ניקוי הנתונים שלו. כדי לקבל התראה על ביטול טוקן, צריך לשלב את השירות הגנה על כל החשבונות.

שימוש בהרשאה מצטברת

כדי לבקש היקפי הרשאות מתאימים של OAuth כשהאפליקציה צריכה את הפונקציונליות, השתמשו בהרשאה מצטברת.

אל תבקשו גישה לנתונים כשהמשתמש מאמת את הזהות שלו בפעם הראשונה, אלא אם הגישה הזו חיונית לפונקציונליות העיקרית של האפליקציה. במקום זאת, בקשו רק את ההיקפים הספציפיים שנדרשים למשימה, בהתאם לעיקרון של בחירת ההיקפים הקטנים והמוגבלים ביותר האפשריים.

תמיד צריך לבקש היקפי הרשאות בהקשר המתאים, כדי שהמשתמשים יבינו למה האפליקציה מבקשת גישה ואיך ייעשה שימוש בנתונים.

לדוגמה, האפליקציה שלכם יכולה לפעול לפי המודל הזה:

1. המשתמש מאמת את הזהות שלו באפליקציה
   1. לא נדרשים היקפי הרשאות נוספים. האפליקציה מספקת פונקציונליות בסיסית שמאפשרת למשתמשים לבדוק ולהשתמש בתכונות שלא דורשות נתונים או גישה נוספים.
2. המשתמש בוחר תכונה שדורשת גישה לנתונים נוספים
   1. האפליקציה שולחת בקשת הרשאה להיקף ההרשאות הספציפי הזה של OAuth שנדרש לתכונה הזו. אם התכונה הזו דורשת כמה היקפי הרשאות, צריך לפעול לפי השיטות המומלצות לשימוש בכמה היקפי הרשאות.
   2. אם המשתמש דוחה את הבקשה, האפליקציה משביתה את התכונה ומספקת למשתמש הקשר נוסף כדי לבקש גישה שוב.

טיפול בהסכמה לכמה היקפים

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

השיטה המומלצת היא לא להמתין למחיקה האוטומטית, אלא להסיר באופן יזום לקוחות שלא בשימוש. כך אפשר לצמצם את שטח המתקפה של האפליקציה ולשמור על אבטחה תקינה.