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

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

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

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

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

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

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

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

توکن‌های محدودکننده فرستنده با DPoP

برای محافظت از برنامه خود در برابر سرقت توکن و حملات بازپخش، محدود کردن توکن‌های خود توسط فرستنده با استفاده از DPoP (اثبات اثبات مالکیت) را در نظر بگیرید. در حالی که توکن‌های استاندارد Bearer می‌توانند توسط هر طرفی که آنها را رهگیری می‌کند، استفاده شوند، توکن‌های DPoP به صورت رمزنگاری به یک جفت کلید منحصر به فرد که توسط کلاینت تولید و نگهداری می‌شود، متصل هستند.

هنگام استفاده از DPoP، کلاینت هنگام درخواست یا به‌روزرسانی توکن‌ها، یک مدرک (یک JSON Web Token امضا شده) را به نقطه پایانی توکن ارائه می‌دهد. این مدرک نشان می‌دهد که کلاینت کلید خصوصی مربوط به کلید عمومی متصل به توکن را در اختیار دارد. اگر یک توکن به‌روزرسانی متصل به DPoP فاش شود، مهاجم بدون آن کلید خصوصی نمی‌تواند آن را دوباره اجرا کند.

DPoP در کنار PKCE برای ارائه حفاظت جامع کار می‌کند:

• PKCE از کد مجوز در طول جریان اولیه تغییر مسیر محافظت می‌کند.
• DPoP از توکن به‌روزرسانی با طول عمر بالا محافظت می‌کند و در صورت به خطر افتادن، از حملات بازپخش جلوگیری می‌کند.

اگر درخواست شما موارد زیر را داشته باشد، اتخاذ DPoP اکیداً توصیه می‌شود:

• به عنوان یک کلاینت عمومی (مانند یک برنامه تک صفحه‌ای یا برنامه نصب شده) عمل می‌کند که در آن توکن‌های به‌روزرسانی ممکن است بیشتر مستعد استخراج باشند.
• به داده‌های بسیار حساس یا APIهای با ارزش بالا دسترسی دارد، جایی که تأثیر نشت توکن قابل توجه است.
• نیاز به رعایت دقیق الزامات یا استانداردهای امنیتی دارد که توکن‌های محدود به فرستنده را الزامی می‌کند.

برای دستورالعمل‌های دقیق در مورد ساخت اثبات‌های DPoP و درخواست توکن‌های متصل به DPoP، به مستندات DPoP مراجعه کنید.

استفاده از پارامتر حالت

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

استفاده از پارامتر state به ما کمک می‌کند تا مطمئن شویم که کاربر، و نه یک اسکریپت مخرب، درخواست را ارسال می‌کند و خطر حملات جعل درخواست بین‌سایتی (CSRF) را کاهش می‌دهد.

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

اگر برنامه شما برای دسترسی آفلاین، توکن به‌روزرسانی درخواست کرده است، باید نامعتبرسازی یا انقضای آنها را نیز مدیریت کنید. توکن‌ها می‌توانند به دلایل مختلف نامعتبر شوند، به عنوان مثال، ممکن است منقضی شده باشند یا دسترسی برنامه‌های شما توسط کاربر یا یک فرآیند خودکار لغو شده باشد. در این حالت، به دقت در نظر بگیرید که برنامه شما چگونه باید پاسخ دهد، از جمله اینکه در ورود بعدی کاربر را مطلع کند یا داده‌های او را پاک کند. برای اطلاع از لغو توکن، با سرویس حفاظت از حساب‌های کاربری (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 را نمی‌توان از طریق برنامه‌نویسی ایجاد یا اصلاح کرد. شما باید از کنسول Google Cloud برای تأیید صریح شرایط خدمات، پیکربندی کلاینت OAuth و آماده‌سازی برای تأیید OAuth استفاده کنید.

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

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

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

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

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