بهترین شیوه ها

این صفحه برخی از بهترین شیوه‌های کلی برای ادغام با OAuth 2.0 را پوشش می‌دهد. این بهترین شیوه‌ها را علاوه بر هرگونه راهنمایی خاص برای نوع برنامه و پلتفرم توسعه خود در نظر بگیرید. همچنین به توصیه‌های مربوط به آماده‌سازی برنامه خود برای تولید و سیاست‌های OAuth 2.0 گوگل مراجعه کنید.

مدیریت ایمن اعتبارنامه‌های مشتری

اعتبارنامه‌های کلاینت OAuth هویت برنامه شما را مشخص می‌کنند و باید با دقت مدیریت شوند. این اعتبارنامه‌ها را فقط در یک فضای ذخیره‌سازی امن، مثلاً با استفاده از یک مدیر مخفی مانند Google Cloud Secret Manager ، ذخیره کنید. اعتبارنامه‌ها را به صورت کد ثابت (hardcode) ذخیره نکنید، آنها را به یک مخزن کد اختصاص ندهید یا به صورت عمومی منتشر نکنید.

توکن‌های کاربر را به صورت ایمن مدیریت کنید

توکن‌های کاربر شامل توکن‌های به‌روزرسانی و توکن‌های دسترسی مورد استفاده توسط برنامه شما می‌شوند. توکن‌ها را به صورت ایمن در حالت سکون ذخیره کنید و هرگز آنها را به صورت متن ساده ارسال نکنید. از یک سیستم ذخیره‌سازی امن مناسب برای پلتفرم خود، مانند Keystore در اندروید، Keychain Services در iOS و macOS یا Credential Locker در ویندوز استفاده کنید.

به محض اینکه دیگر نیازی به توکن‌ها ندارید، آنها را لغو کنید و برای همیشه از سیستم‌های خود حذف کنید.

علاوه بر این، این بهترین شیوه‌ها را نیز برای پلتفرم خود در نظر بگیرید:

• برای برنامه‌های سمت سرور که توکن‌های بسیاری از کاربران را ذخیره می‌کنند، آنها را در حالت استراحت رمزگذاری کنید و مطمئن شوید که مخزن داده‌های شما به صورت عمومی در اینترنت قابل دسترسی نیست.
• برای برنامه‌های دسکتاپ بومی، استفاده از پروتکل Proof Key for Code Exchange (PKCE) اکیداً توصیه می‌شود تا کدهای مجوزی را که می‌توانند با توکن‌های دسترسی مبادله شوند، دریافت کنید.

مدیریت ابطال و انقضای توکن تازه‌سازی

اگر برنامه شما برای دسترسی آفلاین، توکن به‌روزرسانی درخواست کرده است، باید نامعتبرسازی یا انقضای آنها را نیز مدیریت کنید. توکن‌ها می‌توانند به دلایل مختلف نامعتبر شوند، به عنوان مثال ممکن است منقضی شده باشند یا دسترسی برنامه‌های شما توسط کاربر یا یک فرآیند خودکار لغو شده باشد. در این حالت، به دقت در نظر بگیرید که برنامه شما چگونه باید پاسخ دهد، از جمله اینکه در ورود بعدی کاربر را مطلع کند یا داده‌های او را پاک کند. برای اطلاع از لغو توکن، با سرویس حفاظت از حساب‌های کاربری (Cross-Account Protection) ادغام شوید.

استفاده از مجوز افزایشی

از مجوزدهی افزایشی برای درخواست محدوده‌های مناسب OAuth در مواقعی که برنامه شما به این قابلیت نیاز دارد، استفاده کنید.

شما نباید هنگام احراز هویت کاربر، درخواست دسترسی به داده‌ها را بدهید، مگر اینکه این درخواست برای عملکرد اصلی برنامه شما ضروری باشد. در عوض، فقط محدوده‌های خاصی را که برای یک کار مورد نیاز هستند، درخواست کنید و از اصل انتخاب کوچکترین و محدودترین محدوده‌های ممکن پیروی کنید.

همیشه درخواست‌های دسترسی را در متن مربوطه مطرح کنید تا به کاربرانتان کمک کنید تا دلیل درخواست دسترسی توسط برنامه و نحوه استفاده از داده‌ها را درک کنند.

برای مثال، برنامه شما ممکن است از این مدل پیروی کند:

1. کاربر با برنامه شما احراز هویت می‌کند
   1. هیچ محدوده‌ی اضافی درخواست نشده است. این برنامه قابلیت‌های اساسی را فراهم می‌کند تا کاربر بتواند ویژگی‌هایی را که نیازی به داده یا دسترسی اضافی ندارند، بررسی و استفاده کند.
2. کاربر ویژگی‌ای را انتخاب می‌کند که نیاز به دسترسی به داده‌های اضافی دارد
   1. برنامه شما برای این محدوده OAuth خاص که برای این ویژگی لازم است، درخواست مجوز می‌دهد. اگر این ویژگی به چندین محدوده نیاز دارد، از بهترین شیوه‌های زیر پیروی کنید.
   2. اگر کاربر درخواست را رد کند، برنامه این ویژگی را غیرفعال می‌کند و زمینه‌ی بیشتری برای درخواست مجدد دسترسی به کاربر می‌دهد.

مدیریت رضایت برای چندین دامنه

هنگام درخواست چندین scope به طور همزمان، کاربران ممکن است به همه scopeهای OAuth که شما درخواست کرده‌اید، مجوز ندهند. برنامه شما باید با غیرفعال کردن عملکردهای مربوطه، عدم پذیرش scopeها را مدیریت کند.

اگر عملکرد اساسی برنامه شما به چندین حوزه نیاز دارد، قبل از درخواست رضایت، این موضوع را برای کاربر توضیح دهید.

شما فقط زمانی می‌توانید دوباره از کاربر درخواست کنید که به وضوح قصد استفاده از ویژگی خاصی را که به آن محدوده نیاز دارد، نشان داده باشد. برنامه شما باید قبل از درخواست محدوده‌های OAuth، زمینه و توجیه مربوطه را در اختیار کاربر قرار دهد.

شما باید تعداد scopeهایی که برنامه‌تان به طور همزمان درخواست می‌کند را به حداقل برسانید. در عوض، از مجوزدهی تدریجی برای درخواست scopeها در چارچوب ویژگی‌ها و عملکردها استفاده کنید .

از مرورگرهای امن استفاده کنید

در وب، درخواست‌های مجوز OAuth 2.0 فقط باید از مرورگرهای وب با امکانات کامل انجام شوند. در سایر پلتفرم‌ها، مطمئن شوید که نوع کلاینت OAuth صحیح را انتخاب کرده و OAuth را متناسب با پلتفرم خود ادغام کنید. درخواست را از طریق محیط‌های مرور تعبیه‌شده، از جمله webviewها در پلتفرم‌های تلفن همراه، مانند WebView در اندروید یا WKWebView در iOS، هدایت نکنید. در عوض، از کتابخانه‌های بومی OAuth یا Google Sign-in برای پلتفرم خود استفاده کنید.

ایجاد و پیکربندی دستی کلاینت‌های OAuth

برای جلوگیری از سوءاستفاده، کلاینت‌های OAuth را نمی‌توان از طریق برنامه‌نویسی ایجاد یا اصلاح کرد. شما باید از کنسول توسعه‌دهندگان گوگل برای تأیید صریح شرایط خدمات، پیکربندی کلاینت OAuth و آماده‌سازی برای تأیید OAuth استفاده کنید.

برای گردش‌های کاری خودکار، به جای آن، استفاده از حساب‌های سرویس را در نظر بگیرید.

کلاینت‌های OAuth استفاده نشده را حذف کنید

مرتباً کلاینت‌های OAuth 2.0 خود را بررسی کنید و هر کدام را که دیگر مورد نیاز برنامه شما نیستند یا منسوخ شده‌اند، به صورت پیشگیرانه حذف کنید. پیکربندی کلاینت‌های بلااستفاده، یک خطر امنیتی بالقوه است زیرا در صورت به خطر افتادن اعتبارنامه‌های کلاینت، کلاینت می‌تواند مورد سوءاستفاده قرار گیرد.

برای کاهش بیشتر خطرات ناشی از کلاینت‌های بلااستفاده، کلاینت‌های OAuth 2.0 که به مدت شش ماه غیرفعال بوده‌اند، به طور خودکار حذف می‌شوند.

بهترین روش توصیه شده این است که منتظر حذف خودکار نمانید، بلکه به صورت پیشگیرانه کلاینت‌های بلااستفاده را حذف کنید. این روش، سطح حمله به برنامه شما را به حداقل می‌رساند و بهداشت امنیتی خوبی را تضمین می‌کند.