Which problem does OAuth solve, and how does it decouple authentication from authorisation?

"How can I let an application access my data without giving it my password?" The user authenticates only at the authorisation server and delegates a limited, revocable token to the application instead.

* The password stays between the user and the authorization server; the client only ever holds a scoped token. *

Before OAuth, a photo-printing site that wanted your pictures from another service would ask for your username and password there (the password anti-pattern). That gave the printing site full, permanent access to everything, and the only way to revoke it was to change your password everywhere.

OAuth splits the two concerns:

1. The application (client) asks the user for authorisation.
2. The user authorises it, after authenticating at the authorisation server, never at the client.
3. The application presents that authorisation to the server and receives a token.
4. The token ensures that only this application gets access, and only to the data the user released for it (the scopes).

So authentication (proving who you are, with your password) happens in one place, while authorisation (what a particular app may do) is expressed as a token that can be narrow, short-lived and revoked on its own.

Go deeper:

• Okta Developer: What the Heck is OAuth? — the delegation problem and the password anti-pattern, explained with examples.
• RFC 6749, Introduction — the specification's own statement of the problems with sharing passwords.