این صفحه برخی‌از روال‌های مطلوب عمومی را برای ادغام با OAuth 2.0 پوشش می‌دهد. علاوه‌بر هرگونه راهنمایی خاص برای نوع برنامه و پلاتفرم توسعه شما، این روال‌های مطلوب را نیز درنظر بگیرید. همچنین به توصیه‌های مربوط به آماده کردن برنامه برای تولید و خط‌مشی‌های OAuth 2.0 در Google مراجعه کنید.
مدیریت ایمن اطلاعات اعتباری کارخواه
اعتبارنامه کارخواه OAuth هویت برنامه‌تان را شناسایی می‌کند و باید با دقت با آن رفتار شود. این اعتبارنامه‌ها را فقط در فضای ذخیره‌سازی امن ذخیره کنید، برای مثال بااستفاده از مدیر رمز مانند Google Cloud Secret Manager. اعتبارنامه‌ها را کدگذاری سخت نکنید، آن‌ها را به مخزن کد ارسال نکنید، یا آن‌ها را به‌طور عمومی منتشر نکنید.
مدیریت ایمن نشان‌های کاربر
ژتون‌های کاربر شامل ژتون‌های بازآوری و ژتون‌های دسترسی مورداستفاده برنامه‌تان می‌شود. نشان‌ها را به‌طور ایمن در حالت استراحت ذخیره کنید و هرگز آن‌ها را به‌صورت نوشتار ساده ارسال نکنید. از سیستم ذخیره‌سازی امنی استفاده کنید که برای پلاتفرم شما مناسب باشد، مثلاً Keystore در Android، Keychain Services در iOS و macOS، یا Credential Locker در Windows.
به‌محض اینکه دیگر به کدهای امنیتی نیاز نداشتید، آن‌ها را باطل کنید و برای همیشه از سیستم‌هایتان حذف کنید.
علاوه‌براین، این روال‌های مطلوب را نیز برای پلاتفرم خود درنظر بگیرید:
- برای برنامه‌های سمت سرور که نشان‌های بسیاری از کاربران را ذخیره می‌کنند، آن‌ها را در حالت غیرفعال رمزگذاری کنید و مطمئن شوید که پایگاه داده شما به‌طور عمومی در اینترنت قابل‌دسترسی نیست.
- برای برنامه‌های رایانه‌ای، استفاده از پروتکل کلید اثبات برای تبادل کد (PKCE) برای دریافت کدهای مجوزی که می‌توانند با کدهای دسترسی معاوضه شوند قویاً توصیه می‌شود.
کدهای محدودشده به فرستنده با DPoP
برای محافظت از برنامه‌تان دربرابر سرقت کد و حملات بازپخش، محدود کردن فرستنده کدهایتان را بااستفاده از DPoP (اثبات مالکیت) درنظر بگیرید. درحالی‌که هر طرفی که رمزیاب‌های استاندارد Bearer را رهگیری کند می‌تواند از آن‌ها استفاده کند، رمزیاب‌های DPoP به‌صورت رمزنگاری‌شده به جفت کلید منحصربه‌فردی که توسط کارخواه تولید و نگهداری می‌شود محدود شده‌اند.
هنگام استفاده از DPoP، کارخواه هنگام درخواست یا بازآوری ژتون‌ها، مدرکی (یک «ژتون وب JSON» امضاشده) به نقطه پایانی ژتون ارائه می‌دهد. این مدرک نشان می‌دهد که کارخواه کلید خصوصی‌ای را دراختیار دارد که با کلید عمومی متصل به توکن مطابقت دارد. اگر یک ژتون بازآوری محدودشده با DPoP لو برود، مهاجم نمی‌تواند بدون آن کلید خصوصی آن را بازپخش کند.
DPoP در کنار PKCE کار می‌کند تا محافظت جامعی ارائه دهد:
- PKCE از کد مجوز درطول جریان تغییر مسیر اولیه محافظت می‌کند.
- DPoP از ژتون بازآوری بلندمدت محافظت می‌کند و درصورت به‌خطر افتادن آن، از حملات بازپخش جلوگیری می‌کند.
اگر برنامه شما شرایط زیر را دارد، اکیداً توصیه می‌شود از DPoP استفاده کنید:
- به‌عنوان برنامه نصب‌شده یا رایانه‌ای (یا برنامه تک‌صفحه‌ای جفت‌شده با سرور Backend-for-Frontend) عمل می‌کند که در آن ژتون‌های بازآوری ممکن است بیشتر درمعرض استخراج باشند.
- به داده‌های بسیار حساس یا میاناهای برنامه‌سازی کاربردی باارزش دسترسی دارد، جایی که تأثیر نشت کد بسیار قابل‌توجه است.
- باید استانداردهای امنیتی یا رعایت مقررات سخت‌گیرانه‌ای را که توکن‌های محدودشده به فرستنده را الزامی می‌کنند برآورده کند.
برای دستورالعمل‌های دقیق درباره ساختن اثبات‌های DPoP و درخواست کردن توکن‌های محدود به DPoP، به راهنمای پذیرش DPoP مراجعه کنید.
استفاده از پارامتر state
قبل‌از رسیدگی به پاسخ OAuth 2.0، تأیید کنید که state دریافتی از
Google با state ارسال‌شده در درخواست مجوز شما مطابقت داشته باشد. پارامتر
state باید مقداری منحصربه‌فرد و غیرقابل حدس زدن باشد که توسط
برنامه شما تولید شده است.
استفاده از پارامتر state کمک می‌کند تا اطمینان حاصل شود که کاربر، و نه یک اسکریپت مخرب، درخواست را ارسال می‌کند و خطر حملات جعل درخواست بین‌سایتی (CSRF) را کاهش می‌دهد.
رسیدگی به ابطال و انقضای ژتون بازآوری
اگر برنامه‌تان ژتون بازآوری برای دسترسی آفلاین درخواست کرده است، باید باطل شدن یا انقضای آن‌ها را نیز مدیریت کنید. نشان‌ها ممکن است به دلایل مختلفی باطل شوند، برای مثال ممکن است منقضی شده باشند یا دسترسی برنامه‌هایتان توسط کاربر یا فرایندی خودکار لغو شده باشد. در این حالت، به‌دقت بررسی کنید که برنامه‌تان چگونه باید پاسخ دهد، ازجمله درخواست از کاربر در ورود بعدی به سیستم یا پاک کردن داده‌های او. برای مطلع شدن از لغو کد، با سرویس محافظت بین‌حسابی ادغام کنید.
استفاده از مجوز افزایشی
از مجوز افزایشی برای درخواست کردن دامنه‌های OAuth مناسب در زمانی که برنامه شما به این عملکرد نیاز دارد استفاده کنید.
هنگامی که کاربر برای اولین‌بار اصالت‌سنجی می‌کند، نباید درخواست دسترسی به داده‌ها را ارسال کنید، مگراینکه این دسترسی برای عملکرد اصلی برنامه‌تان ضروری باشد. درعوض، فقط دامنه‌های خاصی را که برای یک وظیفه لازم است درخواست کنید و از اصل انتخاب کوچک‌ترین و محدودترین دامنه‌های ممکن پیروی کنید.
همیشه دامنه‌ها را در بافت درخواست کنید تا به کاربران کمک کنید متوجه شوند چرا برنامه‌تان درخواست دسترسی می‌کند و چگونه از داده‌ها استفاده خواهد شد.
برای مثال، ممکن است برنامه شما از این مدل پیروی کند:
- کاربر با برنامه شما اصالت‌سنجی می‌کند
- هیچ دامنه دیگری درخواست نشده است. برنامه عملکردی پایه ارائه می‌دهد تا کاربر بتواند ویژگی‌هایی را که به داده یا دسترسی اضافی نیاز ندارند کاوش و استفاده کند.
- کاربر ویژگی‌ای را انتخاب می‌کند که به دسترسی به داده‌های اضافی نیاز دارد
- برنامه شما درخواست مجوز برای این دامنه OAuth خاص موردنیاز برای این ویژگی را ارائه می‌دهد. اگر این ویژگی به چندین گستره نیاز دارد، روال‌های مطلوب برای چندین گستره را دنبال کنید.
- اگر کاربر درخواست را رد کند، برنامه ویژگی را غیرفعال می‌کند و بافت بیشتری به کاربر ارائه می‌دهد تا دوباره درخواست دسترسی کند.
مدیریت رضایت برای چند دامنه
وقتی چندین دامنه را به‌طور هم‌زمان درخواست می‌کنید، ممکن است کاربران همه دامنه‌های OAuth درخواستی شما را اعطا نکنند. برنامه شما باید با غیرفعال کردن عملکرد مربوطه، رد شدن دامنه‌ها را مدیریت کند.
اگر عملکرد اصلی برنامه‌تان به چند دامنه نیاز دارد، قبل‌از درخواست رضایت، این موضوع را برای کاربر توضیح دهید.
فقط زمانی می‌توانید دوباره از کاربر درخواست کنید که به‌وضوح نشان داده باشد قصد دارد از ویژگی خاصی که به آن گستره نیاز دارد استفاده کند. برنامه شما باید قبل‌از درخواست کردن دامنه‌های OAuth، زمینه و توجیه مربوطه را به کاربر ارائه دهد.
باید تعداد دامنه‌هایی را که برنامه‌تان به‌طور هم‌زمان درخواست می‌کند به حداقل برسانید. درعوض، از مجوزدهی افزایشی استفاده کنید تا دامنه‌ها را در بافت ویژگی‌ها و عملکردها درخواست کنید.
استفاده از مرورگرهای امن
در وب، درخواست‌های مجوز OAuth 2.0 فقط باید از مرورگرهای وب با ویژگی‌های کامل انجام شود. در پلاتفرم‌های دیگر، حتماً نوع کارخواه OAuth صحیح را انتخاب کنید و OAuth را به‌طور مناسب برای پلاتفرمتان ادغام کنید. درخواست را ازطریق محیط‌های مرور جاسازی‌شده، ازجمله وب‌نماها در پلاتفرم‌های تلفن همراه، مانند «وب‌نما» در Android یا WKWebView در iOS، هدایت نکنید. درعوض، از کتابخانه‌های OAuth توصیه‌شده یا ورود به سیستم Google برای پلاتفرم خود استفاده کنید.
ایجاد و پیکربندی دستی کارخواه‌های OAuth
برای جلوگیری از سوءاستفاده، کارخواه‌های OAuth را نمی‌توان به‌صورت برنامه‌نویسی‌شده ایجاد یا اصلاح کرد. باید از کنسول Google Cloud برای تأیید صریح شرایط خدمات، پیکربندی کارخواه OAuth، و آماده‌سازی برای درستی‌سنجی OAuth استفاده کنید.
برای گردش‌های کار خودکارشده، بهتر است از حساب‌های سرویس استفاده کنید.
برداشتن کارخواه‌های OAuth استفاده‌نشده
به‌طور منظم کارخواه‌های OAuth 2.0 خود را ممیزی کنید و هرکدام را که دیگر برای برنامه‌تان لازم نیست یا منسوخ شده است به‌طور پیش‌گیرانه حذف کنید. رها کردن کارخواه‌های پیکربندی‌شده بلااستفاده نشان‌دهنده خطر امنیتی بالقوه است زیرا اگر اعتبارنامه‌های کارخواه شما لو برود، ممکن است از کارخواه سوءاستفاده شود.
برای کاهش بیشتر خطرات ناشی از کارخواه‌های استفاده‌نشده، کارخواه‌های OAuth 2.0 که به‌مدت شش ماه غیرفعال بوده‌اند به‌طور خودکار حذف می‌شوند.
روال مطلوب توصیه‌شده این است که منتظر حذف خودکار نمانید، بلکه به‌طور پیش‌گیرانه کارخواه‌های استفاده‌نشده را بردارید. این کار سطح حمله برنامه‌تان را به‌حداقل می‌رساند و بهداشت امنیتی خوبی را تضمین می‌کند.