test: make the smoke run's narrowing check able to fail

[kanushka]

Follow-up to #34, stacked on it. Closes the last open definition-of-done box in docs/plans/login-first-slice.md.

The problem

The live smoke run's narrowing check could not fail.

login_smoke_test.go acquired once, asking for config.Scopes — every permission the session already carries. internal/auth/narrowing.go verifies by comparing the issued scopes against the requested ones, so when the request is the whole session, that comparison is a set against itself. It holds however the deployment behaved. Point the run at a backend that disregards a narrowing request entirely and it would still print granted.

The audience half of that verification was real and did catch things — an Asgardeo run refused on it. The scope half was theatre. Which matters, because the definition of done reads "against a backend proven to satisfy the scope/audience policy", and half of that proof was vacuous.

config.NarrowTarget() had existed for exactly this since the smoke package was written, and nothing called it.

What this does

Acquires twice, because the two acquisitions fail for different reasons:

LOGIN SMOKE: granted  — asked for everything the session carries, received access of
                        1261 characters bound to "reference-status" carrying
                        [reference:status:read reference:status:write]
LOGIN SMOKE: narrowed — asked for one permission out of the 2 the session holds,
                        received access of 1230 characters bound to "reference-status"
                        carrying [reference:status:read]

The first proves the broker can derive access at all, which is what a first run against a new deployment needs to know. The second is a strict subset — the request a module actually makes — and is the only form the verification can disagree with.

A refusal on the broad request stops the run rather than repeating one finding: a deployment that will not issue against this audience at all says nothing about narrowing. A refusal on the narrowed request is a real statement about the deployment, and still passes, because the shell declining to hand a module more authority than it asked for is the designed outcome.

One thing the change surfaced

The first attempt reused a single auth.Broker and failed:

auth.already_granted: the "reference" module asked for access twice in one command

The shell allows a module one acquisition per command. So the two acquisitions run as two invocations — which is not a way around the rule but the accurate model of it: two commands, in turn, against one session, the way the shell is actually used. Against a rotating deployment the second acquisition now also proves the first persisted its replacement refresh token, since it can only reach the token endpoint with what the first one stored.

Not changed, and why

The same definition-of-done clause says the reference module receives the token. That half needs nothing further. TestLoginThenTheModuleReceivesIssuerMintedNarrowedAccess already launches the real module subprocess, has the issuer introspect what it presented, and pins refresh rotation across three runs. A module never learns which issuer minted its token — that is what the source seam is for — so running it against a live deployment would add a subprocess and a status service to a test whose value is about the deployment, and prove nothing the deterministic chain does not.

Verification

make smoke-login    granted 1261 chars [read write], then narrowed 1230 chars [read]
make test           exit 0
./scripts/acceptance.sh   exit 0
make lint           0 issues, tagged and untagged
make vet            clean
gofmt -l            no output

Live run against wso2/wso2is:7.3.0, the deployment #34 registered. The two tokens differ in length and in scope set, which is the evidence the previous single-acquisition form could not produce.

docs/plans/login-first-slice.md is now fully ticked, definition of done included.

Relates to #17.

https://claude.ai/code/session_01RojiAgW9hi3b9f9G6ZXBVp

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 7bcf299b-86cc-495a-ae8c-56843e8d317e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

This PR updates the live login smoke run so its scope-narrowing verification can actually disagree with a misbehaving deployment, by performing two brokered acquisitions: one “broad” (prove access derivation works at all) and one “narrowed” (strict subset, so narrowing can meaningfully fail). It also updates the smoke-run documentation and the implementation plan to reflect the new evidence and definition-of-done completion.

Changes:

• Update TestLoginSmoke to acquire twice (broad + narrowed) using separate auth.Broker instances, and add an acquire helper to standardize smoke output.
• Expand test/smoke/RUNNING.md to explain why the second acquisition is the meaningful narrowing measurement and how to interpret refusals.
• Mark the definition-of-done item as completed in docs/plans/login-first-slice.md, with a short summary of the new empirical evidence.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
test/smoke/RUNNING.md	Documents the new two-acquisition smoke run and clarifies how to interpret narrowing-related outcomes.
test/smoke/login_smoke_test.go	Implements the two-step acquisition (broad + narrowed) so the narrowing check can fail when a backend ignores narrowing.
docs/plans/login-first-slice.md	Updates plan status/definition-of-done text to reflect the now-non-vacuous live narrowing proof.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.