In a ZAP automation plan, what does a context's authentication block hold and what do its users entries hold?

## What the two blocks are for A ZAP automation plan is `env` plus `jobs`. Inside `env`, each entry of `contexts` can carry an `authentication` block and a `users` list, and they answer two different questions: - **`authentication` says HOW to log in.** It picks a `method` and supplies the `parameters` that method needs - for a `form` login, the URL to post to and the body to post. - **`users` says WHO logs in.** Each entry is a `name` plus a `credentials` map holding a `username` and a `password`. Neither block is useful alone. The method describes the shape of a login request with the identity left out; the users list supplies the identity with no idea how it is sent. A job that should run authenticated names a user by its `name`, and the context's method is what turns that name into a real request. ## What actually goes in `authentication` `method` is a string. `parameters` is a free-form map whose accepted keys depend on the method: `loginRequestUrl` and `loginRequestBody` for `form` and `json`, `hostname` and `realm` for `http`, `script` and `scriptEngine` for `script`. The block is **credential-free by design** - it is written once per application, and it does not change when you add a second test identity. ## What actually goes in `users` Each user is a `name` used by jobs, and a `credentials` map. For the `form` and `json` methods the credential keys are `username` and `password`, because those methods are backed by core's `UsernamePasswordAuthenticationCredentials`. A `script` method uses `GenericAuthenticationCredentials` instead, whose credential parameter names are whatever the script declares, so a script login can take a tenant id or an API key rather than a password. ## Two curly-brace syntaxes, resolved by different layers This is where the block split bites, because one line of YAML can carry both: ``` loginRequestBody: "user={%username%}&pass={%password%}" username: "${APP_USER}" ``` | syntax | who resolves it | when | |---|---|---| | `${NAME}` | the `automation` add-on's environment | when the plan is read, once | | `{%username%}` / `{%password%}` | core's form or JSON login method | at every login replay, per user | The automation add-on's variable pattern matches only a dollar sign followed by braces, so `{%username%}` passes through the plan untouched and survives into the configured method. That is deliberate: `${...}` is how a value gets **into** the plan from outside, and `{%...%}` is how a per-user value gets **into the login request** at replay time. They are not interchangeable, and swapping them produces a plan that is syntactically fine and functionally wrong. ## Why the split matters when a scan runs unattended 1. **Reuse.** One `authentication` block plus several `users` entries lets the same context be scanned as a low-privilege and a high-privilege identity without duplicating the login shape. 2. **Substitution timing.** Because credentials are resolved per user at replay, the same `loginRequestBody` serves every identity. Putting a literal password in the body instead collapses the plan to one identity and bypasses the token machinery entirely. 3. **Externalisation.** Because `credentials` values support `${...}`, the actual secret can be supplied to the plan from outside it rather than living in the file that is checked in. 4. **Job wiring.** A job's optional `user` parameter must name a user defined in the environment - a job that names a user the context does not declare has nothing to authenticate as. ## The failure this split prevents, and the one it does not It prevents a plan where the identity is fused into the request shape, which is the version that cannot be scanned twice as two different people. It does **not** prevent a plan with a perfectly good `users` list and an `authentication` block whose body never mentions the tokens - in that case every user posts the same static string and the login is effectively anonymous. Nothing in the method's own configuration check looks for the tokens, so this is a silent outcome rather than a reported one. ## Reading a plan quickly When you inherit a plan and want to know whether it really logs in, read the two blocks together and check, in this order: - does `authentication.method` name a method this installation actually has; - do its `parameters` describe a request that would genuinely log the application in; - does `loginRequestBody` contain both credential tokens; - does `users` carry an entry whose `credentials` are populated; - does the scanning job name that user. Any one of those missing produces a run that completes normally and covers only the pages a stranger can see. None of them produces an error on its own, which is why reading the pair of blocks is a habit rather than a debugging step.