Chapter 2 — Authentication protocols in practice
Lesson map
Lesson 02 published. Map, example, EX005.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Sign-in flows"]
N2["2.2 Sessions and tokens"]
N3["2.3 Settings to watch"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX005"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Sign-in flows"]
N2["2.2 Sessions and tokens"]
N3["2.3 Settings to watch"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]
[Learning outcomes]
|
v
[2.1 Sign-in flows]
|
v
[2.2 Sessions and tokens]
|
v
[2.3 Settings to watch]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX005]
Learning outcomes
You will (1) explain how browsers and services authenticate; (2) describe sessions and tokens; (3) recognise protocol settings in admin consoles.
2.1 Sign-in flows
When a receptionist opens the appointment system, the browser is redirected to the directory, which asks for her password and second factor, then sends her back with proof of sign-in. This redirect pattern is used by OpenID Connect, built on OAuth 2.0 (RFC 6749), and by SAML 2.0. Tomas does not need to implement these protocols, but he must recognise them in admin consoles, because settings such as allowed redirect addresses and certificate expiry dates affect whether sign-in works and stays safe.
An expired signing certificate, for example, would stop every receptionist signing in at once even with correct passwords.
2.2 Sessions and tokens
After sign-in, the service keeps a session so staff are not asked again on every click. Tokens carry the proof and expire after a set time. Tomas finds the appointment system keeps sessions for 30 days, so a lost reception tablet would stay signed in for a month. He proposes eight hours, matching a working day, and the practice manager agrees after a one-week trial. Session length is a balance between convenience and how long a lost or shared device stays useful to someone else.
2.3 Settings to watch
Tomas makes a checklist of protocol settings to review each quarter: certificate expiry dates for SAML connections, allowed redirect addresses for OpenID Connect applications, session lengths and which applications are permitted to request access to mailboxes. RFC 9700 gives current security advice for OAuth deployments, which he summarises for the practice in plain words. A short, regular checklist catches expiring certificates before sign-in fails on a busy Monday morning. Tomas stores the checklist with his runbooks and records each quarterly result, including the date, any setting changed and who approved the change.
Worked example
Session length for the appointment system is cut from 30 days to 8 hours after a one-week trial; a quarterly protocol checklist is created.
Synthetic case. Systems and settings are synthetic; RFC 6749, RFC 9700, OpenID Connect Core and SAML 2.0 are real sources.
Errors and limits
Leaving long default session lengths on shared devices keeps lost tablets signed in for weeks.
Exercises
- EX005 — Redirect standard. Which standard is OpenID Connect built on? Rubric: 3 = OAuth 2.0, RFC 6749;; 2 = OAuth;; 1 = SAML;; 0 = none.
- EX006 — Session change. How was the session length changed? Rubric: 3 = 30 days to 8 hours;; 2 = shorter;; 1 = longer;; 0 = none.
- EX007 — Expiry risk. Why watch SAML certificate expiry? Rubric: 3 = expired certificates break sign-in;; 2 = outage;; 1 = cost;; 0 = none.
- EX008 — OAuth advice. Which RFC gives current OAuth security advice? Rubric: 3 = RFC 9700;; 2 = 9700;; 1 = 6749;; 0 = none.
Synthesis
Recognising protocol settings and reviewing them regularly keeps sign-in working and safe.
Continue studying — chapter 02 of 18
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →