Chapter 11 — Networks and protocols | Engineering Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Sign-in over the network"]
  N2["11.2 Redirects and codes"]
  N3["11.3 Name resolution and trust"]
  N4["11.4 Where tokens travel"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Sign-in over the network"]
  N2["11.2 Redirects and codes"]
  N3["11.3 Name resolution and trust"]
  N4["11.4 Where tokens travel"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Sign-in over the network]
    |
    v
[11.2 Redirects and codes]
    |
    v
[11.3 Name resolution and trust]
    |
    v
[11.4 Where tokens travel]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) trace how sign-in traffic crosses networks; (2) explain HTTPS redirects in federation; (3) identify where tokens travel.

11.1 Sign-in over the network

When a council employee opens an application, the browser is redirected to the identity provider, signs in there and is redirected back carrying proof of authentication. Every step travels over HTTPS, which protects the content with TLS. Sana traces this path for a typical application: browser to application, browser to provider, provider back to browser, browser to application. Understanding the path shows where tokens and codes appear, and therefore which links, logs and devices must protect them, since anything that captures a token may be able to replay it.

11.2 Redirects and codes

In OpenID Connect's authorisation code flow, the provider does not send the ID token through the browser directly. It sends a short-lived code, which the application exchanges with the provider over a direct back-channel connection for tokens. RFC 6749 defines this pattern for OAuth 2.0, and RFC 7636 adds Proof Key for Code Exchange so that a stolen code cannot be redeemed by someone else. RFC 9700 recommends these practices as current best practice. Sana requires them for every new integration at Linmouth.

Without PKCE, a malicious app that intercepted the code on the same device could exchange it for tokens itself.

11.3 Name resolution and trust

Browsers find the identity provider through DNS, then verify its TLS certificate. If DNS were tampered with and the certificate not checked, staff could be sent to a fake sign-in page. Proper certificate validation in browsers protects against this, and phishing-resistant authenticators add a second layer, because a passkey will not sign for a site whose origin differs from the one it was registered with. Sana documents the provider's domain names and certificate management as part of the identity design, not as a separate network matter.

11.4 Where tokens travel

Access tokens travel from applications to APIs on every request. If any hop uses plain HTTP, or if tokens are written to logs, they can be copied. Sana lists every place a token may appear: browser storage, application memory, API gateways, logs and monitoring tools. For each, she sets a rule, such as transport only over TLS and never logging full tokens. This inventory turns a vague worry about token theft into concrete checks that can be reviewed and tested in the verification laboratory.

Worked example

Sana traces an OpenID Connect code flow at Linmouth through four hops and lists five places tokens may appear, each with a protection rule.

Synthetic case. Hops, domains and applications are synthetic.

Errors and limits

Logging full access tokens for debugging creates a store of reusable credentials.

Exercises

EX031 — Code exchange. How does an application turn an authorisation code into tokens? Rubric: 3 = direct back-channel exchange with the provider;; 2 = back-channel;; 1 = browser;; 0 = none.
EX032 — PKCE purpose. What does Proof Key for Code Exchange prevent? Rubric: 3 = redemption of a stolen code by someone else;; 2 = stolen code use;; 1 = phishing;; 0 = none.
EX033 — Token log rule. What logging rule protects tokens? Rubric: 3 = never log full tokens;; 2 = no tokens in logs;; 1 = log all;; 0 = none.

Synthesis

Tracing sign-in across the network shows where codes and tokens travel and what must protect them.

Continue studying — chapter 11 of 50

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →