Skip to main content

​
Save a baseline, compare later

The diff compares the facts a verdict depends on, not the raw report — otherwise every run would “change” its own timestamp and HTTP observations. Scope lists compare as sets; version lists stay order-sensitive because their order is preference.

​
Continuous monitoring

List servers in monitor/targets.txt, one URL per line. A scheduled workflow scans each daily against committed baselines and, when the authentication configuration moves:
  1. Fails the run, with the changed fields in the job summary.
  2. Opens a labelled issue, which notifies through whatever you already have GitHub notifications wired to — email, mobile push. When the scan matches the baselines again, the issue closes itself.
  3. Opens a pull request with the new baseline, so accepting drift is a reviewable diff a human merges — not a silent push. The baseline is written only when the scan produced a valid graded report, so an inconclusive or failed run never overwrites a trusted reference.
There is no scheduler and no database: cron already exists, and keeping baselines in the repository means every change is attributable.

​
What it alerts on

  • A field disappeared from the metadata
  • The issuer changed
  • code_challenge_methods_supported dropped
  • An endpoint moved to a different host — the change that matters most, since credentials are sent to it, and nothing else about the metadata need change
  • The server stopped requiring authorization, or started redirecting
For the one failure no probe can see coming — a credential expiring inside the identity provider — see Microsoft Entra.