What OAuth is and why passwords are not the answer

A photo-printing app asks you to “connect your Google Drive.” You type your Google password directly into their form. Now that app can read every file, email, and photo in your account — forever. One breach of PrintPic and every Google-linked service is compromised. OAuth exists because this is the wrong way to share access.

The three parties

Every OAuth flow involves three parties working together:

1. The client (your app, e.g. PrintPic). Wants limited access to a resource on behalf of the user. Never sees the user’s password.
2. The authorization server (the identity provider, e.g. Google). Authenticates the user, issues tokens. The only party that holds the password.
3. The resource server (the API, e.g. Google Drive). Accepts tokens to serve requests. Validates tokens against the authorization server.

The dog-walker metaphor

You hire a dog walker. You do not hand them your house key. Instead, you go to a key kiosk (the authorization server) and say “Frank can walk the dog Tuesdays 9–10am.” The kiosk prints Frank a single-use card that opens only the back gate, only on Tuesday, only for one hour. Frank loses the card — no problem, you revoke it at the kiosk. The card is the access token. The back gate is the resource API.

Two tokens, two jobs

A successful OAuth + OpenID Connect flow produces two distinct tokens:

• Access token — authorizes API calls. The client sends it in the Authorization: Bearer header. It says “the holder may do X.” The resource server accepts it without needing to know the user’s identity.
• ID token — proves who the user is (OpenID Connect layer). Always a JWT. Contains claims like sub (stable user ID), email, name. The client reads it to know who just signed in. Never sent to APIs.

The access token answers: “can this app do thing X?” The ID token answers: “who is the user?”