OAUTH HISTORY: FROM PASSWORDS TO GLOBAL STANDARDS

You see it every day. You click "Login with Google" or "Login with GitHub." You do not type a password. You enter the site instantly.

This works because of OAuth. It is the global standard for security. But it did not start this way. It evolved to solve massive problems.

The Problem with Passwords

In the early days, you created a new password for every website. This caused three big issues:

  • People used the same password everywhere. If one site leaked, every account was at risk.
  • People forgot passwords. They spent more time clicking "forgot password" than using the web.
  • Websites saw your raw password. If a site was hacked, your password was gone.

The Evolution of Security

  1. Basic Auth: You sent your username and password with every request. If you did not use HTTPS, hackers could see everything.

  2. Session Cookies: You logged in once and got a session ID. It was better, but cookies can be stolen through attacks like XSS or CSRF. Also, one site could not use your login to talk to another site.

  3. API Keys: You gave a website a special key. This was better because you did not send your password. However, API keys often have too much power. If you give an API key to an app, that app might have power to read your emails, send messages, and delete your account. It is like giving a hotel valet your car key, but that key also opens your house.

The OAuth Solution: The Valet Key

OAuth changed the game. Instead of giving your password, you give a "token." Think of it as a valet key. A valet key lets a driver park your car, but it does not let them open your trunk or access your house.

How OAuth Works in Practice:

  • You want to use Canva and pull photos from Google.
  • Canva asks Google for permission.
  • Google asks you: "Can Canva view your photos?"
  • You say: "Yes, but only view. Do not let them delete anything."
  • Google gives Canva a specific token.

Canva never sees your Google password. Even if a hacker steals that token, they can only view photos for a short time. They cannot change your password or move your money.

Modern Security: PKCE

Mobile apps and web apps have a weakness. They cannot hide secrets well. To fix this, we use PKCE (Proof Key for Code Exchange).

It works like a reservation system:

  • The app creates a secret code (the verifier).
  • The app sends a hashed version of that code (the challenge) to Google.
  • When the app asks for the token, it sends the original secret code.
  • Google checks if the code matches the challenge.

If they match, Google knows it is the same app. If they do not match, Google blocks the request. This stops hackers from stealing your authorization code.

The Roadmap of OAuth

  • 2007 (OAuth 1.0): Very complex and used heavy math.
  • 2012 (OAuth 2.0): Faster and easier. It used tokens and required HTTPS.
  • 2016 (OAuth 2.0 + PKCE): Added security for mobile and modern web apps.
  • 2023 (OAuth 2.1): The new gold standard. It removes old, insecure methods.

The Core Lesson: Never give your password to another app. Give them a limited ticket that expires. You stay in control.

Source: https://dev.to/gophernment/oauth-elaaaebbprawatisaastr-cchaakrhasphaan-suumaatrthaanolk-16b4