OAuth 2.0: Access Without Sharing a Password

OAuth 2.0 is a framework for delegated access: a user lets one application act on their data held by another service, without giving the application their password. The service issues the application an access token limited to what the user approved and to a short time, and the application sends that token to the service's API. OAuth is about granting access; on its own it does not tell the application who the user is.

An access token works like a hotel key card: it opens some doors, for a while, and the front desk never hands over the master key. The comparison breaks on checking, since a door reads the card by itself, while an API may also ask the server that issued the token whether it is still valid.

What was wrong with sharing passwords. The application got everything the user could do, kept it until the password changed, and became one more place the password could leak from. The user had no way to see or limit what it did.

What a token adds. It is limited in scope, the actions it allows, and in time. It can be revoked for one application without affecting others. The user's password is typed only into the service that owns it.

What OAuth does not do. An access token says "the bearer may read photos", not "this is Maria". Using OAuth alone to sign users in leads to subtle mistakes; OpenID Connect is the layer built on OAuth for login.

So use OAuth when an application must act on a user's data held elsewhere, and never ask for the user's password to that service.