Before OAuth, APIs often used Basic Auth, requiring third-party apps to collect and store user passwords.
Mid-2000s providers created separate, incompatible delegation systems (e.g., FlickrAuth, AuthSub, BBAuth).
OAuth 1 emerged (2007) to standardize delegated API access without password sharing.
OAuth 1 became limiting for developer usability and mobile-era security/scalability needs.
OAuth 2 evolved to improve usability and architecture, including bearer tokens and separation of authorization server vs API server.
OAuth 2.0 finalized in 2012, then expanded via newer specs and best practices (native apps, device flow, security BCP).
Lecture 3 — How OAuth Improves Application Security
Traditional app login patterns often require apps to handle user passwords directly, which creates trust and security risks.
Password-sharing is especially dangerous for third-party apps: users give full-account power when the app only needs limited actions.
Revoking a single app is hard in password-based models; users often must change their password and break all other sessions/apps.
From API/operator perspective, password-based login makes app identity weak, abuse detection harder, and MFA rollout difficult to scale across many clients.
OAuth improves security by redirecting users to the authorization server for login, so apps never see passwords.
This model enables safer delegation, better control/revocation, and more scalable security evolution for both first-party and third-party ecosystems.