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