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