mosaicstack/stack
25
0
Fork 1
Code Issues 400 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

sage: Q175 SSO design r2 for #412, Filbert r1 B1-B6, rulings Q-B/Q-C/Q-D, config in config.json (mos-0973)

Browse Source
This commit is contained in:
jason.woltje
2026-10-20 13:32:26 -05:00
parent def2e79327
commit 1a268249e6
1 changed files with 211 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agents/sage/work/q175-sso/DESIGN.md
+211 -91
View File
@@ -1,8 +1,25 @@
# Q175 design: the Console verifies SSO itself (Vikunja #412)
Author Sage, 2026-10-20. Reviewer Filbert, and the review comes before any code. Line numbers are at refactor
4ca8d6e94. This replaces Part B (row 178 proxy proof, #385 comments 345 and 353). #385 stays open until the
Console stops trusting `X-authentik-username`.
Author Sage, 2026-10-20, r2. Reviewer Filbert, and the review comes before any code. Line numbers are at
refactor 4ca8d6e94 unless a line says otherwise. This replaces Part B (row 178 proxy proof, #385 comments 345
and 353). #385 stays open until the Console stops trusting `X-authentik-username`.
## Changes from r1 (Filbert's r1 review, CHANGES)
- B1: the provider config moves to `~/.config/mosaic-dev/config.json` (section 4). Mos agreed (mos-0973). The
Console prints provider ids, issuers and subject counts at start. The rehearse-strip follow-up is dropped.
- B2: one return-path rule, `new URL(ret, publicOrigin).origin === publicOrigin` (section 1 step 7), with
tests for `/\evil.example` and `/%09/evil.example`.
- B3: refusals log a fixed code and the provider id, never the error or its cause (section 1).
- B4: login records are capped at 32 (section 1 step 1), with a test.
- B5: test 9 splits into a forged payload under a real kid and a kid missing from the JWKS, and a try/catch
mutant joins the list. Test 2 no longer claims the signature mutant (section 9).
- B6: the phase 2 forged-header check runs on a scratch Console, or Mos or Jason runs it on live (section 5).
- Rulings: Q-B start degraded (section 4), Q-C only the public Host on 7332 (section 3), Q-D keep 1 h idle
but polls don't count as activity (section 3).
- Section 6: `startServer` throws on `tester && sso`, and `human` joins `tester` as a refused subject label.
- The missing tests and nits N1-N5 are in sections 1, 3, 7 and 9.
- Section 8: the human-cli statement stays as written (mos-0972). The recommendation is now Mos's ruling.
## The ruling this implements
@@ -22,7 +39,9 @@ trust with verification" and confirmed five points (mos-0970):
## What exists today
The live Console runs from copies/490e2771d3d0 with `--public-host mosaic.woltje.com --auth-header
X-authentik-username --allow-user jason.woltje --send --tester-port 7333`.
X-authentik-username --allow-user jason.woltje --send --tester-port 7333`. Row 189 (#1687, P19 #413) adds
`stack-release.sh activate --no-send`, and Mos's ruling mos-0972 takes `--send` off the live Console until
phase 2.
- `previewOptions` (packages/webui/src/serve.mjs:205) builds `{ host, header, user }`.
- A request is `named` when its Host equals the public name (:493). A named request passes sign-in when it
@@ -45,41 +64,62 @@ New module `packages/webui/src/sso.mjs`, used only by the human listener (7332).
| Route | Method | What it does |
|---|---|---|
| `/auth/login` | GET | One provider configured: start its flow. Several: a plain page listing them, each a link to `/auth/login?provider=ID`. |
| `/auth/login` | GET | One provider configured: start its flow. Several: a plain page listing them, each a link to `/auth/login?provider=ID`. A provider whose discovery hasn't succeeded gets 503 (section 4). |
| `/auth/callback` | GET | Finish the flow, create the session, 303 to the saved return path. |
| `/auth/logout` | POST | Same-origin checks, delete the session, 303 to the provider's `end_session_endpoint`. |
| `/auth/signed-out` | GET | Static "signed out" page with a sign-in link. |
Every URL the Console hands a provider is built from the configured `publicOrigin`: `redirect_uri` is
`publicOrigin + '/auth/callback'` and `post_logout_redirect_uri` is `publicOrigin + '/auth/signed-out'`. No
code path reads the request's Host to build them (N2).
The flow per provider:
1. Start. Generate a state, a nonce and a PKCE verifier (`generateRandomState`, `generateRandomNonce`,
`generateRandomCodeVerifier`), and a challenge with `calculatePKCECodeChallenge` (S256 only). Put them, the
provider id and the return path in a server-side login record keyed by a random id. Set
`__Host-mosaic_login` to that id. 303 to `authorization_endpoint` with `response_type=code`,
`scope=openid profile email`, `code_challenge_method=S256`, `redirect_uri`, `state` and `nonce`.
provider id, the return path and an expiry 10 minutes out in a server-side login record keyed by a random
id. The store holds at most 32 login records; a new one evicts the oldest (B4). Set `__Host-mosaic_login` to
that id. 303 to `authorization_endpoint` with `response_type=code`, `scope=openid profile email`,
`code_challenge_method=S256`, `redirect_uri`, `state` and `nonce`.
2. Callback. Read exactly one `__Host-mosaic_login` cookie, then take and delete its record (single use, so a
replayed callback finds nothing). Expire the cookie in the response. The provider comes from the record,
never from the query, which stops a mix-up between providers.
never from the query, which stops a mix-up between providers. Two tabs signing in at once each set the
cookie, so the later one wins and the earlier tab's callback finds no record and gets the 403 page with a
sign-in link (N5). That costs one retry and keeps one cookie per browser.
3. `validateAuthResponse(as, client, url, record.state)` checks state, refuses an error response, and checks
the `iss` parameter when the provider advertises RFC 9207.
4. `authorizationCodeGrantRequest(as, client, clientAuth, params, redirectUri, record.verifier)`, then
`processAuthorizationCodeResponse(as, client, response, { expectedNonce: record.nonce, requireIdToken: true })`.
That checks iss, aud (and azp when aud has several values), exp, iat and nonce, and checks `alg` against
`client.id_token_signed_response_alg`.
4. `authorizationCodeGrantRequest(as, client, clientAuth, params, redirectUri, record.verifier)` returns a
`Response`. Keep that object. `processAuthorizationCodeResponse(as, client, response, { expectedNonce:
record.nonce, requireIdToken: true })` checks iss, aud (and azp when aud has several values), exp, iat and
nonce, and checks `alg` against `client.id_token_signed_response_alg`. That field gets the provider's whole
`algs` array, which the library's `checkSigningAlgorithm` accepts, so a provider listing RS256 and ES256
takes either and nothing else (N1). Test 16 pins this.
5. Signature. oauth4webapi does not verify the signature of an ID token that came straight from the token
endpoint over TLS (OIDC Core 3.1.3.7 allows that, and the library docs for
`validateApplicationLevelSignature` say so). Point 2 asks for the JWKS check, so the callback always calls
`validateApplicationLevelSignature(as, response)` after step 4. It fetches the JWKS from the discovered
`jwks_uri`, picks the key by `kid` and `alg`, and refuses HS* outright.
6. Our own checks on top of the library: `header.alg` is in the provider's configured `algs`, the token's
`iss` equals the configured issuer exactly, and `(iss, sub)` is in the provider's `subjects` list. Anything
else is a 403 that logs `refused sign-in iss=... sub=...` (never a token, code or cookie).
7. Create the session (section 3) and 303 to the return path. The return path must start with one `/` and
is otherwise replaced with `/`.
`validateApplicationLevelSignature(as, response)` with the same `Response` object from step 4. It fetches
the JWKS from the discovered `jwks_uri`, picks the key by `kty`, `kid`, `alg` and `use`, and refuses HS*
outright. On a `kid` it doesn't have, it refetches the JWKS once if the cache is at least 60 s old, which
covers key rotation (test 18). The call is not wrapped in a catch that continues; its throw ends the
callback.
6. Our own checks on top of the library: `header.alg` is in the provider's `algs`, the token's `iss` equals
the configured issuer as a raw string compare, with no URL normalising (N3; the library's discovery check
compares normalised hrefs, so this one is stricter), and `(iss, sub)` is in the provider's `subjects` list.
7. Create the session (section 3), then 303 to the return path. The rule (B2): resolve
`u = new URL(ret, publicOrigin)`, and use `u.pathname + u.search` only when
`u.origin === publicOrigin`; otherwise use `/`. A missing or unparsable `ret` gives `/`.
Every refusal in steps 2-6 ends at a 403 page saying sign-in failed, with a link back to `/auth/login`. No
step falls back to a header.
Logging (B3). A refusal logs one line: a fixed code from a closed list (`login-record-missing`,
`state-mismatch`, `auth-error-response`, `grant-failed`, `id-token-invalid`, `signature-invalid`,
`alg-refused`, `issuer-mismatch`, `subject-unknown`, `discovery-failed`, `jwks-failed`) and the provider id.
It never logs the exception, its message or its `cause`. oauth4webapi's errors carry token bodies and claims
in `cause`, so even a message can leak. The one extra field is on `subject-unknown`: it logs `iss` and `sub`,
because Jason step 3 reads his `sub` from that line. Neither is a credential. Test 19 asserts that no log
line holds a token, code, state, nonce, verifier, client secret or session id.
### 2. Library: oauth4webapi 3.8.8, pinned exactly
Mos's steer (mos-0971) was to prefer oauth4webapi over hand-rolled verification on `node:crypto` unless I
@@ -103,34 +143,57 @@ entry. Root is right because `scripts/stack-copy.sh:23-31` copies only the root
webui's first runtime dependency. The root dependency rule (exact pins, never unversioned) applies to it.
Upgrades are reviewed commits.
### 3. Sessions, cookies and logout
### 3. Sessions, cookies, Host and logout
- Session id: 32 random bytes, base64url. The store keys on its sha256, so a heap dump doesn't hold usable ids.
- Cookie `__Host-mosaic_session=<id>; Secure; HttpOnly; SameSite=Lax; Path=/`, no Domain, no Max-Age (a
browser-session cookie). The `__Host-` prefix makes the browser refuse it unless it was set over https on
this exact host.
- Login cookie `__Host-mosaic_login`, same attributes plus `Max-Age=600`. The login record also expires at
10 minutes server-side.
- Session id: 32 random bytes, base64url. The store keys on its sha256 and holds no raw id, so a heap dump
doesn't hold usable ids. Test 20 checks that the store's keys and values never contain the cookie value.
- Cookie, exactly: `__Host-mosaic_session=<id>; Path=/; Secure; HttpOnly; SameSite=Lax`, no Domain, no
Max-Age (a browser-session cookie). The `__Host-` prefix makes the browser refuse it unless it was set over
https on this exact host. Test 21 asserts the whole Set-Cookie value, and a mutant drops `HttpOnly`.
- Login cookie `__Host-mosaic_login`, the same attributes plus `Max-Age=600`. The login record also expires
at 10 minutes server-side.
- Lax, not Strict, because the callback is a top-level navigation from the provider's site, and a Strict
cookie set there would be missing on the redirect to `/`. Lax still keeps the session off cross-site POSTs.
The write routes keep their exact `Origin` and `Sec-Fetch-Site: same-origin` checks (:171, :250, :297, :340,
:387, :425), so cross-site writes are refused twice.
- Lifetime: 8 h absolute, 1 h idle, both server-side. The store is in memory with a cap of 64 sessions
(oldest goes first), so a Console restart signs everyone out. That's acceptable for one human and keeps
sessions off disk.
- Lifetime: 8 h absolute, 1 h idle, both server-side (Q-D, Filbert's ruling). The store is in memory with a
cap of 64 sessions (oldest goes first), so a Console restart signs everyone out. That's acceptable for one
human and keeps sessions off disk.
- Activity (Q-D). Only a page load (a GET outside `/api/`) or a write (a POST) refreshes `seen`. The page's
background reads don't: `refresh` re-reads the board every 10 s (packages/webui/src/public/app.js:346) and
the 5 s timer at :301 redraws the age label. Without this rule an open tab would never go idle. Test 13
covers it.
- The session holds `{ provider, iss, sub, name, idToken, created, seen }`. `name` is the subject entry's
label. It goes where `preview.user` goes today (send logs, settings, seat routes), so the downstream writer
shape stays as it is. `idToken` is kept only as the logout hint and never leaves the server.
- Host (Q-C, Filbert's ruling). Under `--sso`, 7332 serves only requests whose Host is the public host.
Any other Host, loopback included, gets 403 `public Host required`, except `GET /healthz`. The loopback read
path at :509-512 is gone under `--sso`. Today's readers of 127.0.0.1:7332 and where they go:
- `scripts/webui-service.sh status` (:406), the stack-release gate (scripts/stack-release.sh:484) and the
rehearse gate (:1369) read only `/healthz`, which stays open on loopback.
- The webui README (:83) describes the loopback path. It changes in phase 1.
- Agent reads of the board go to the tester listener on 7333, which already serves reads. I found no other
code that reads 7332 on loopback. A person opening http://127.0.0.1:7332 in a local browser gets the 403
and uses the public URL instead.
Test 22 covers a loopback Host on `/`, `/api/board` and a write, and `/healthz` passing.
- Every request on 7332 except `/healthz` and `/auth/*` needs a valid session. Without one, `/api/*` gets
401 JSON and other GETs get a 303 to `/auth/login?return=<path>`.
- Logout: `POST /auth/logout` with the same-origin checks. It deletes the session, expires the cookie, and
303s to `end_session_endpoint?id_token_hint=...&post_logout_redirect_uri=https://mosaic.woltje.com/auth/signed-out&client_id=...`.
303s to `end_session_endpoint?id_token_hint=...&post_logout_redirect_uri=<publicOrigin>/auth/signed-out&client_id=...`.
If the provider has no `end_session_endpoint`, it goes straight to `/auth/signed-out`.
- Limit: signing out at the provider does not end a Console session until idle or absolute expiry. Back-channel
logout is a follow-up, not phase 1.
### 4. Provider config: shape and location
Location (B1, Filbert's ruling, Mos agreed in mos-0973): a `console.sso` key in
`~/.config/mosaic-dev/config.json`. The reason is who can write it. The business file is writable by agents
through `organizationWriter` (the tester verbs and the chief's `organization.set`), so a provider entry there
could be changed by the agents the Console is meant to keep out. config.json is user-authored and never
auto-written: `scripts/bootstrap.sh` creates it and nothing overwrites it. Adding the key is a Jason step
(section 10), and the config loader's schema gains an optional `console` key with a strict validator. Files
without it still load.
No secret value goes in this file. The client secret is a slot reference.
```json
@@ -151,38 +214,45 @@ No secret value goes in this file. The client secret is a slot reference.
}
```
Location: a new optional `console` key in the business file (`~/.config/mosaic-dev/businesses/<id>.json`). The
Console already serves one business (`--business`), the identities map to that business's human, and Q173
lets agents edit the test business with a backup first. Adding the key means adding `console` to `TOP_KEYS`
(packages/business/src/business.mjs:21) with a strict validator. It's additive, and existing files without
it still load. The alternative is `~/.config/mosaic-dev/config.json`, which is user-authored and never
auto-written. That fits a deployment setting well, but it puts per-business identity in system config.
**Filbert, rule on this one.**
At start, `--sso` prints one line per provider: its id, its issuer and the number of subjects. No client id
value beyond that, no secret, no `sub`.
The slot is `~/.config/mosaic-dev/secrets/mosaic-stack/<slot>`, read at start. The Console refuses to start if
the file isn't a regular file, isn't owned by the Console's uid, has any group or other mode bits, or
resolves under the repo or a stack copy. The value is never logged or put in a refusal message.
the file is a symlink, isn't a regular file, isn't owned by the Console's uid, has any group or other mode
bits (0640 refuses as well as 0644), or resolves under the repo or a stack copy. The value is never logged or
put in a refusal message.
`stack-release.sh rehearse` copies a backup onto a scratch root. A rehearsed Console must not use the live
redirect URI, so rehearse strips `console.sso` from the scratch business file and the rehearsed Console runs
without SSO (tester listener only). That's a row 163 follow-up, named in the build brief.
`stack-release.sh rehearse` starts its Console with `serve --port N --business B` and no `--sso`, so a
rehearsed Console never reads `console.sso` and never uses the live redirect URI. No rehearse change is
needed; r1's follow-up is dropped.
Startup checks for each provider, all fail-closed (the Console doesn't start, and the message names the
provider and the check):
Config checks, run at start without the network. Any failure refuses the start, and the message names the
provider and the check:
- `issuer` is https with no query or fragment. Discovery returns that issuer exactly.
- `id_token_signing_alg_values_supported` shares at least one alg with `algs`, and `algs` holds only
asymmetric algs from the library's list. mosaic-preview advertises HS256 only, so the Console refuses it at
start.
- `publicOrigin` is an https origin with no path, query or fragment.
- Provider ids are unique and `[a-z0-9-]{1,32}`.
- `issuer` is https with no query or fragment.
- `algs` is non-empty and holds only asymmetric algs from the library's list. `HS256`, any `HS*` and `none`
refuse.
- `subjects` is non-empty, each `sub` is 1..255 visible characters, and no `name` is `tester` or `human`.
- The client secret slot passes the file checks above.
Discovery checks, run per provider when its discovery succeeds:
- Discovery returns `issuer` exactly.
- `id_token_signing_alg_values_supported` shares at least one alg with `algs`. mosaic-preview advertises HS256
only, so it fails here.
- `code_challenge_methods_supported` includes `S256`.
- `jwks_uri` returns at least one key usable for one of `algs`. The empty mosaic-preview JWKS fails here too.
- `subjects` is non-empty, and each `sub` is 1..255 visible characters.
- `client.id_token_signed_response_alg` is set to `algs[0]`, so the library enforces it per token.
- Provider ids are unique and `[a-z0-9-]{1,32}`.
Starting while the provider is unreachable refuses the start. A Console with no working sign-in serves
nothing, so refusing loudly costs nothing, and the unit restarts it. The tradeoff is that an IdP outage
keeps the Console down until the IdP is back. With every route behind a session, it would be unusable anyway.
Unreachable provider (Q-B, Filbert's ruling). Config errors still refuse the start. A provider whose
discovery or JWKS can't be fetched doesn't stop the Console: it starts, that provider's `/auth/login` gets
503 `sign-in unavailable`, and a retry runs with backoff (5 s, doubling, capped at 5 minutes). `/healthz`
stays 200 and adds `sso: { <id>: "ready" | "unreachable" | "refused" }`, so the gates still pass and an
operator can see the state. A provider whose discovery answers but fails a discovery check is `refused`: at
start that refuses the start, because it's a configuration problem, and on a later retry it stays disabled
with the `discovery-failed` code until a restart. Sessions already made keep working while a provider is
unreachable, since a session check needs no network. Test 23 covers the degraded start and the recovery.
Several providers: Pocket ID, WorkOS and other compliant OPs use the same entry shape. The login page lists
them. Each entry has its own issuer, client, algs and subjects, and a session records which provider made it.
@@ -190,13 +260,15 @@ them. Each entry has its own issuer, client, algs and subjects, and a session re
### 5. Retiring `--auth-header`, `--allow-user` and the proof header
1. **Phase 1 (code row).** Add `--sso` to `cli.mjs serve` and `webui-service.sh`. It reads `console.sso` from
the business file. `--sso` cannot be combined with `--auth-header`, `--allow-user` or `--proof-*`. Under
config.json. `--sso` cannot be combined with `--auth-header`, `--allow-user` or `--proof-*`. Under
`--sso`, `named` means "has a session", and `writer` comes from the session. `--send` needs `--sso` or the
old preview set. Nothing live changes until the re-pin.
2. **Phase 2 (Jason-gated window).** Re-pin to the phase 1 commit with `--sso --send --tester-port 7333`
instead of the preview flags, after the Jason steps below. Backup first, STATE after (Q173). Acceptance:
Jason signs in through the Console flow, sends one message, signs out, and a forged-header request with no
cookie gets 401.
Jason signs in through the Console flow, sends one message and signs out. The forged-header check (a
request with `X-authentik-username` and no cookie gets 401) runs either on a scratch Console started from
the same copy with the same flags on another port, where an agent may send it, or on live by Mos or Jason
(B6). No agent sends the auth header to the live 7332 (section 8).
3. **Phase 3 (code row).** Remove `previewOptions`, `proofOptions` and their tests. `cli.mjs` and
`webui-service.sh` refuse the old flags with `--auth-header was retired by Q175; use --sso`. Close #385
with the phase 2 STATE and the phase 3 commit.
@@ -211,13 +283,15 @@ The tester listener exists so agents can test as the tester and never as Jason (
- It never mounts `/auth/*` (404), never reads a cookie, and refuses any request carrying `Authorization` or a
`__Host-mosaic_session` / `__Host-mosaic_login` cookie (403 `tester listener takes no sign-in`). The same
goes for `X-authentik-jwt` and the old auth and proof header names.
- `startServer` throws when its options hold both `tester` and `sso`, so the SSO module can't be mounted on
the tester listener by a wiring mistake. A unit test calls it with both.
- Its writer stays the fixed `{ tester: true, user: 'tester' }`, and it allows only the row 175 writes, as
today. No session or header can change it.
- Its bus calls stay on `TESTER_CLI`. The bus checks the tester proof and refuses human verbs from it, and the
broker refuses a business whose human is `tester` and any role named `tester`. So nothing that reaches 7333
can become the human.
- 7332 keeps refusing `x-mosaic-tester` for every Host (:485).
- `subjects` validation refuses an entry named `tester`.
- `subjects` validation refuses a `name` of `tester` or `human`.
### 7. Point 5, the proxy-forwarded token
@@ -225,7 +299,9 @@ Not in phase 1. Point 5 makes it optional and the code flow covers the ruling. I
- Verify with jose (MIT, exact pin), against the JWKS from the configured issuer's own discovery. Never use
the `X-authentik-meta-jwks` header, because it arrives with the request and the forger controls it.
- Use the same alg allow list, iss, aud (the proxy provider's client id), exp and subject list.
- Use the same alg allow list, iss, exp and subject list. `aud` is the proxy provider's client id, and the
config check refuses it if it equals any code-flow `clientId`, so an ID token issued to the Console can't be
replayed as a proxy token or the other way round (N4).
- The mosaic-preview provider signs with HS256 and has an empty JWKS, so its `X-authentik-jwt` fails every
check until Jason gives it an RSA or EC key (Jason step 1).
@@ -237,9 +313,11 @@ Today, with `--send` live, any same-uid process on dragon-lin can connect to 127
strips client copies of the header, so a remote forger needs local code execution first. Users on other uids
can reach the loopback port too (P19 333).
Recommendation: Mos restarts the Console without `--send` until phase 2. Reads stay up, the header path stops
carrying writes, and only Jason's sends through the Console stop. That's a Mos call (Console start belongs to
Jason or Mos). Until then, no agent sends a request with the auth header to 7332. The tests use fixture servers.
Mos ruled (mos-0972) that the Console runs without `--send` until phase 2. Reads stay up, the header path
stops carrying writes, and Jason sends piece 1 with `mosaic talk pm` instead. Row 189 (`stack-release.sh
activate --no-send`, #1687) makes that change through the pointer so the unit and stack-active.json stay in
step; the restart follows its landing. Until phase 2, no agent sends a request with the auth header to 7332.
The tests use fixture servers.
To be clear about the limit: SSO protects Console ingress. It doesn't protect the bus's human boundary. The
human proof is path-bound (#225), so a same-uid process can already run the tree's `human-cli.mjs` and act
@@ -249,11 +327,11 @@ as the human without touching the Console. Q175 doesn't change that. P19 333 own
All tests run against a fake OP in `packages/webui/tests/helpers/fake-oidc.mjs`. It's a loopback https
server with a self-signed cert. Each test passes the library a `customFetch` that trusts only that cert, so
production code needs no insecure-request flag. The fake OP has discovery, a
JWKS, and authorization, token and end-session endpoints, with keys made by `node:crypto` (RSA 2048, P-256, and an
HMAC secret for the forgeries). No test reaches a real provider. Each refusal test asserts the status, that no
`__Host-mosaic_session` was set, and that the bus send stub was never called. Each test also passes once
unmutated, as the control.
production code needs no insecure-request flag. The fake OP has discovery, a JWKS, and authorization, token
and end-session endpoints, with keys made by `node:crypto` (RSA 2048, P-256, and an HMAC secret for the
forgeries). It can serve two issuers at once and rotate its keys. No test reaches a real provider. Each
refusal test asserts the status, that no `__Host-mosaic_session` was set, and that the bus send stub was
never called. Each test also passes once unmutated, as the control.
Refusals Mos named:
@@ -261,10 +339,12 @@ Refusals Mos named:
Fetch Metadata, and no cookie: 401 on `/api/bus/message`, `/api/settings` and `/api/config`, and a 303 to
login on `/`.
2. HS256 ID token. The fake OP signs the ID token with HS256, using the client secret as the key (the classic
confusion) and `kid` set to a real RSA kid: refused at the callback.
3. Wrong aud. A correctly signed RS256 token with `aud` set to another client id: refused.
4. Expired token. A correctly signed token with `exp` 10 minutes ago (beyond the library's clock tolerance):
refused.
confusion) and `kid` set to a real RSA kid: refused at the callback. The library's alg check refuses it
before any signature check, so this test proves the alg rule, not the signature check. Test 9 covers that.
3. Wrong aud. A correctly signed RS256 token with `aud` set to another client id: refused. Also an `aud`
array holding our client id and another, with no `azp`: refused.
4. Expired token. A correctly signed token with `exp` 10 minutes ago (beyond the library's 30 s clock
tolerance): refused.
More refusals:
@@ -274,22 +354,59 @@ More refusals:
and two login cookies.
8. A provider that demands no PKCE. The token request must carry `code_verifier`, and the fake OP refuses a
wrong one.
9. `alg: none`, and an RS256 token signed by a key not in the JWKS.
10. A valid token for a `sub` not in `subjects`: 403 and one log line with iss and sub only.
11. Startup refusals: HS-only discovery (the mosaic-preview shape), an empty JWKS, no S256, an issuer mismatch,
a slot with mode 0644, and `--sso` together with `--auth-header`.
9. The signature check (B5), three cases: (a) `alg: none`; (b) an RS256 token whose header names a real kid in
the JWKS, with a changed payload and the original signature; (c) an RS256 token signed by a key whose kid
isn't in the JWKS, even after the refetch. (b) is the case only the signature check catches.
10. A valid token for a `sub` not in `subjects`: 403 and one `subject-unknown` log line with the provider id,
iss and sub only.
11. Start refusals: `algs` holding `HS256` or `none`, HS-only discovery (the mosaic-preview shape), an empty
JWKS, no S256, an issuer mismatch, a subject named `tester` or `human`, `--sso` together with
`--auth-header`, and slot files that are a symlink, mode 0644, mode 0640, or under the repo. The owner
check has no test: making a file owned by another uid needs root, which the suite doesn't have. The
review reads that branch instead.
12. Tester port: a valid session cookie (taken from a 7332 sign-in), `Authorization: Bearer <valid id token>`,
and `X-authentik-jwt` each get 403. `/auth/login` on 7333 gets 404.
and `X-authentik-jwt` each get 403. `/auth/login` on 7333 gets 404. `startServer` with `tester` and `sso`
throws.
13. Session: idle expiry, absolute expiry, a logout followed by reuse of the old cookie, and logout without
same-origin (refused, session kept).
14. Open redirect: `return=//evil.example` and `return=https://evil.example` both land on `/`.
same-origin (refused, session kept). Background `/api/` GETs every 10 s for over an hour don't keep the
session alive; a page load does.
14. Open redirect: `return=//evil.example`, `return=https://evil.example`, `return=/\evil.example` and
`return=/%09/evil.example` all land on `/`, and `return=/board?x=1` lands there.
15. Provider mix-up. Two providers, A and B. A login started for A whose callback carries B's `iss` and a
code from B is refused, and a `provider=` query on the callback is ignored.
16. Several algs: a provider with `algs: ["RS256", "ES256"]` takes a token signed with either, and refuses
PS256 even when the JWKS holds a usable PS256 key.
17. Login record cap: 33 started logins leave 32 records, and the first login's callback finds no record.
18. JWKS rotation: the fake OP rotates to a new key with a new kid. A sign-in after the rotation succeeds
through the one refetch, and a token under the removed kid is refused.
19. Logs: across every test in this file, captured log lines hold none of the tokens, codes, states, nonces,
verifiers, the client secret or a session id that the test produced.
20. The session store holds no raw session id (keys are sha256 values, and no value holds the cookie).
21. Set-Cookie: the exact session and login cookie strings, including the expiry of the login cookie at
callback.
22. Host: under `--sso`, a loopback Host on `/`, `/api/board` and a write each get 403; `/healthz` on
loopback gets 200.
23. Degraded start: the fake OP is down at start; the Console starts, `/auth/login` is 503, `/healthz` reports
`unreachable`; the OP comes up and the next retry makes sign-in work. A provider that answers with HS-only
discovery at start refuses the start.
Positive paths: an RS256 and an ES256 provider each complete sign-in and one send, and two providers configured
together each work with their own subjects.
Mutants for the gate: drop the `validateApplicationLevelSignature` call (test 2 or 9 must fail), drop the
`subjects` check, accept HS* in `algs`, take the provider from the query, let the tester listener read
cookies, and skip the login record delete.
Mutants for the gate, each killed by the named test:
- drop the `validateApplicationLevelSignature` call (9b);
- wrap that call in a try/catch that continues (9b);
- drop the `subjects` check (10);
- accept HS* in `algs` (11);
- take the provider from the query (15);
- let the tester listener read cookies (12);
- skip the login record delete (7);
- drop `HttpOnly` from the session cookie (21);
- refresh `seen` on every request (13);
- build `redirect_uri` from the request Host (a test with a different Host on `/auth/login` checks the
`redirect_uri` sent to the fake OP);
- serve the loopback read path under `--sso` (22).
### 10. Jason-gated steps
@@ -300,16 +417,19 @@ cookies, and skip the login record delete.
post-logout URI `https://mosaic.woltje.com/auth/signed-out`, keep RS256, and give the client id. Put the
client secret into slot `console-sso-authentik` (or say an agent may create the slot file from a value he
puts in place, per the Q173 secrets rule). Agents never see the value.
3. His `sub` for that provider, or a go to read it from the Console's one refusal log line on his first
sign-in attempt.
4. Any Traefik or outpost change. None is needed while the outpost stays in front. Dropping the outpost
3. His `sub` for that provider, or a go to read it from the Console's one `subject-unknown` log line on his
first sign-in attempt.
4. The `console.sso` entry in `~/.config/mosaic-dev/config.json`. He writes it, or he gives an agent the go to
write that one key from the values in steps 2 and 3, with a backup of the file first. config.json is
user-authored, so this isn't covered by Q173.
5. Any Traefik or outpost change. None is needed while the outpost stays in front. Dropping the outpost
later, so the Console is the only gate, changes who can reach the Console from outside and is his call.
5. The phase 2 re-pin window go.
6. The phase 2 re-pin window go.
## Questions for review
- Q-A: the config location, business file `console` key or config.json (section 4).
- Q-B: refuse to start when the IdP is unreachable, or start and refuse sign-ins (section 4).
- Q-C: should the loopback-Host read path on 7332 also go behind the session, as proposed? Public traffic
arrives from 127.0.0.1 too, and only Host keeps it off that path today.
- Q-D: 8 h absolute and 1 h idle, or shorter.
Q-A to Q-D are settled (Filbert r1, Mos mos-0973). One new point for Filbert:
- Q-E: the `subject-unknown` log line carries `iss` and `sub` (section 1, Logging), as the only exception to
"fixed code and provider id only", so Jason step 3 can work. Keep it, or log only the provider id and have
Jason read his `sub` from Authentik's admin view?