The problem OAuth solves
Connecting two services
Imagine you have a collection of photos stored with an online photo service. You want to use a separate printing application to turn some of them into a photo book.
The printing application needs to retrieve those photos. You could download them yourself and upload them to the printer, but you would prefer to connect the two services and choose the photos directly.
How should the printing application get access?
Giving it your photo account's password would create a much larger relationship than the task requires. You want it to read some photos. Your password might also let it delete albums, change account settings, or access information unrelated to your order.
It would also leave you with another copy of your password to protect. If several applications used that password, changing it could disrupt all of them.
What you need is a way to authorize a particular application to do a particular kind of work.
Delegated access
Delegated access means allowing another party to act with some of your authority. In this example, you authorize the printing application to retrieve photos from a service where you already have an account.
OAuth 2.0 provides a framework for arranging that access. In the flow we will study first, you interact with the photo service to authorize the connection. The printing application receives an access token, which it presents when requesting photos. Your photo account's password stays out of the printing application.
The token is a credential, so it still needs protection. Its purpose is to represent access that the service has granted to the application. The service can limit that access and decide how long the token remains usable. A common type is a bearer token: whoever possesses it can use the access it represents, subject to the resource server's checks.
That gives the photo service a way to distinguish the printing application's access from your own sign-in credentials. However, the useful limits depend on how the service implements authorization. Using OAuth does not automatically mean the printer can see only the photos you selected.
For example, a service might support access to a single album. Another might offer permission to read the entire photo library. Both could use OAuth, but the authority you are granting would be different.
Access and sign-in
The distinction between access and sign-in also matters.
You may sign in to the photo service while authorizing the connection. That allows the photo service to establish whose account is involved. It does not, by itself, give the printing application a standardized result it can use to sign you in to the printer's own account system.
OpenID Connect adds an authentication layer to OAuth 2.0. We will reach it after following the OAuth exchange and understanding the different purposes of its messages and tokens.
For now, our task is specific: allow the printing application to retrieve authorized photos without collecting your photo account's password.