בדף הזה מפורטות כמה שיטות מומלצות כלליות לשילוב עם OAuth 2.0. כדאי להשתמש בשיטות המומלצות האלה בנוסף להנחיות הספציפיות לסוג האפליקציה ולפלטפורמת הפיתוח שלכם. מומלץ גם לעיין בטיפים להכנת האפליקציה לסביבת הייצור ובמדיניות של Google בנושא OAuth 2.0.
טיפול בפרטי הכניסה של הלקוחות באופן מאובטח
פרטי הכניסה של לקוח OAuth מזהים את הזהות של האפליקציה, ויש לטפל בהם בזהירות. כדאי לאחסן את פרטי הכניסה האלה רק באחסון מאובטח, למשל באמצעות מנהל סודות כמו Google Cloud Secret Manager. אין להטמיע את פרטי הכניסה בקוד, לאשר אותם במאגר קוד או לפרסם אותם באופן ציבורי.
טיפול באסימוני משתמשים באופן מאובטח
אסימוני משתמשים כוללים גם אסימוני רענון וגם אסימוני גישה שבהם האפליקציה שלכם משתמשת. לשמור את האסימונים בצורה מאובטחת במצב מנוחה, ולעולם לא להעביר אותם בטקסט ללא הצפנה. כדאי להשתמש במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם, כמו Keystore ב-Android, שירותי Keychain ב-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.
לתהליכי עבודה אוטומטיים כדאי להשתמש בחשבונות שירות במקום זאת.