OAuth

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

دادن مستقیم گذرواژه سرویس‌های دیگر دارای مشکلات زیر است:

• نیاز به وجود اعتماد قوی کاربر به نرم‌افزار درخواست‌کنندهٔ گذرواژه
• ایجاد مسئولیت سنگین برای توسعه‌دهندهٔ نرم‌افزار جهت حفظ و نگهداری امن گذرواژه و جلوگیری از لورفتن آن
• بالا بردن آسیب‌پذیری کاربران در مقابل حملات فیشینگ
• دادن دسترسی بیش از حد نیاز (در حالی که یک نرم‌افزار ممکن است تنها به بخش خاصی از اطلاعات حساب کاربری نیاز داشته باشد)
• از بین رفتن دسترسی نرم‌افزار پس از تغییر گذرواژهٔ حساب توسط کاربر
• عدم وجود راهی ساده برای گرفتن دسترسی یک نرم‌افزار خاص (با تغییر گذرواژه همهٔ نرم‌افزارهایی که از آن گذرواژه استفاده می‌کرده‌اند از کار خواهند افتاد)
• ایجاد دشواری در پیاده‌سازی روش‌های ایمن‌سازی دیگر مانند استفاده از کپچا یا اصالت‌سنجی چندعاملی

حتی در روش‌های اصالت‌سنجی همبسته مانند اپن‌آی‌دی نیز همچنان نیاز است که کاربر گذرواژهٔ حساب اپن‌آی‌دی خود را در وب‌گاه واسطه وارد کند.

• Campesato, O.; Nilson, K. (2011). Web 2.0 Fundamentals: With AJAX, Development Tools, and Mobile Platforms. Web 2.0 Fundamentals with Ajax, Development Tools, and Mobile Platforms (به انگلیسی). Jones & Bartlett Learning. Retrieved 2013-11-26.
• Lakshmiraghavan, B. (2013). Pro ASP.NET Web API Security: Securing ASP.NET Web API. The expert's voice in .NET (به فرانسوی). Apress. Retrieved 2013-11-26.
• Boyd, R. (2012). Getting Started with OAuth 2.0. Oreilly and Associate Series (به انگلیسی). O'Reilly Media, Incorporated. Retrieved 2013-11-26.