The authorization request
Selecting Connect does not immediately give the printer access to your photos. It first sends a request describing the access it wants and how the photo service should return its answer.
The request travels through your browser to the authorization endpoint. Here is the request used in our example, with its parameters on separate lines so we can read them:
https://auth.photos.example/authorize
?response_type=code
&client_id=photo-printer
&redirect_uri=https%3A%2F%2Fprinter.example%2Foauth%2Fcallback
&scope=photos.read
&state=demo-attempt-7
&code_challenge=qd-75t-gnweZAhIl6REjxxgFnPXGwvqYcxq3vlsaJYQ
&code_challenge_method=S256This is a fictional example, not a working connection. In particular, demo-attempt-7 is a readable stand-in for an unpredictable value generated for one attempt.
Describing the request
response_type=code asks the authorization server to return an authorization code if the request succeeds. It does not ask the server to put an access token in the return URL.
client_id identifies the printer's registration. It is visible in the request and is not a secret. Another application knowing this value does not thereby become an authenticated instance of the printer.
redirect_uri tells the authorization server where to return the browser. The value is URL-encoded because it appears inside another URL. Decoding it gives the printer's registered callback address.
scope describes the requested access. Here, photos.read is a permission name invented for our photo service. OAuth does not define that particular name. If the service used different permission names, the printer would need to request those instead. Multiple scopes are separated by spaces, encoded appropriately in the URL.
The request also includes two forms of protection. state helps the printer connect the returning response to the attempt it started. The PKCE challenge commits the client to a verifier it will provide later. S256 identifies how that challenge was derived. The next lessons explain their separate purposes.
Requesting is not receiving
The printer chooses what to request. The photo service controls what it will allow. The requested scope must make sense for the service and the client registration, and the resulting access may be narrower than requested or refused entirely.
For the photo book, read access is enough. Requesting deletion access merely because it is available would make the connection more powerful without helping you complete this task.
The URL should contain only what belongs in this browser-facing request. The printer's client secret and PKCE verifier stay on its backend. The photo service handles your authentication through its own interaction; the printer does not add your photo account password to this request.
The authorization endpoint is therefore a place to request and arrange access. Receiving a valid request there is the beginning of a decision, not evidence that the decision has already been made.