The problem OAuth solves
Connecting two services
Giving another application limited access, in Fundamentals, introduced the situation this series follows: your photos are stored with an online photo service, and you want a separate printing application to turn some of them into a photo book. Before tracing OAuth's answer message by message, it helps to look more closely at the problem itself.
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
This is the delegated access problem from Fundamentals: you want the printing application to act with some of your authority, not all of it. 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. Most access tokens are bearer tokens, so whoever holds one 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
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 in From delegated access to sign-in, 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.