Info
Content

Introduction

Password Antipattern

scenario_gmail_authentication.png

Joe wants to access his emails on Gmail server.

third_party_app_gmail.png

He found a cool app on the App Store that he likes to use to schedule sending his emails on Gmail. The app needs access Joe's emails on Gmail.

password_antipattern.png

If Joe gave Gmail password to the app then the app could probably use Joe's password to access his other Google services or his password might be leaked to someone else if not properly managed.

OAuth 2.0

oauth20_solution.png

Actors

Joe is the Resource Owner who want to access his emails (i.e. Resources) on the the Gmail server (i.e. Resource Server) via the Third-party App (a.k.a. Client). Here, the OAuth Server comes in so Joe doesn't give his password to the app.

A Flow

  1. The client contacts OAuth server requesting access to the resource
  2. OAuth server shows a login screen for Resource Owner to enter credential i.e. username and password
  3. OAuth server validates the credential with a Login Server and send a Token back to the client
  4. The client sends request to the resource server with the token
  5. Resource server validate the token with the OAuth server before it sends the response back to the client

OAuth server is just a Delegation. The actual Authentication happens on the login server. The actual Authorization happens on the resource server

References

Back to top