Trust boundaries

Crossing a boundary

The printing application, authorization server, and photo API each receive information from somewhere else. Before acting on that information, they need a reason to trust it.

The point where information passes between components with different control or authority is a trust boundary.

Consider the printing application receiving an authorization response through your browser. The application needs to determine whether that response belongs to an authorization attempt it actually started. Receiving a request at its callback address is not sufficient evidence.

The authorization server has its own questions. Is this client allowed to use the requested redirect URI? Is the code being exchanged valid for this client? Has it already been used? Have the required protections for this exchange been satisfied?

The photo API asks another set of questions. Does it recognize the authority that issued this access token? Was the token intended for this API? Is it still usable? Does the request fall within the access granted?

Protecting each request

Each participant performs checks relevant to its responsibility. The authorization server's decision to issue a token does not remove the API's responsibility to protect a particular album.

For example, suppose the printer has permission to read photos from your account. It requests an album belonging to someone else.

The API must still reject that request unless the authorization rules genuinely permit access to that album. A valid token is not permission to retrieve whichever resource identifier appears in a URL.

Transport protection and message validation also solve different parts of the problem.

HTTPS protects messages while they travel between endpoints. It does not establish that an application was entitled to request a particular photo, or that an authorization response matches the browser session receiving it.

Likewise, reading a token's contents does not establish that those contents are trustworthy.

Some access tokens are opaque values whose meaning is determined through the authorization server or associated server-side records. Others contain structured information, such as a signed JSON Web Token, or JWT.

For a JWT access token, signature verification is one part of validation. The API also needs to check the token's intended use, issuer, audience, lifetime, and other applicable requirements. A correctly signed token intended for another API should not be accepted simply because the signature is valid.

After access is granted

There is also a boundary after access has been granted. Once the printing application downloads a photo, it has a copy. Preventing future API requests cannot make that already downloaded copy disappear. You are trusting the printer to handle the data it receives appropriately.

These boundaries explain why an OAuth integration needs more than a successful demonstration of the happy path. Later lessons will examine request correlation, redirect validation, token handling, and attacks that exploit missing checks. We will introduce the relevant protections alongside the exchanges they protect.