Why does a Postman collection with an `auth.type` of `jwt` run fine yet fail schema validation?
answer
- Two projects, two lists, one disagreement
- The validator and the runner read different sources
- Two handlers have no declared enum value
- The asymmetry runs one way only
- getHandler never consults the format's enum
basics
~10 sDeclaration and implementation are separate authorities. The collection format's auth.type enum declares eleven schemes; a runner's authorizer registers thirteen signing handlers, including jwt and asap, which the format never names.
solid answer
~40 sTwo different projects own the two halves. The **collection format** declares `auth.type` as an enum of eleven scheme names, and a strict validator rejects anything outside it — `jwt` included. The **runtime** keeps its own registry, built by loading the handler modules in its `authorizer` directory and registering each one through `AuthLoader.addHandler`. That registry holds thirteen entries: the eleven declared schemes plus `jwt` and `asap`. When a run signs a request it calls `AuthLoader.getHandler(auth.type)` against that registry and never consults the format's enum, so a `jwt` selection finds a handler and signs normally. The document is therefore executable and schema-invalid at the same time. Never quote the union of the two sets as "the auth types" — they are a declaration and an implementation, and they disagree.
go deeper
Be ready to say that a collection file can be valid to run and invalid to validate, because two different lists of scheme names exist.
Explain which component reads which list: a validator reads the format's enum, a runner reads its own registry of signing handlers.
Show you can diagnose the report of a collection that runs but fails a schema check, and can name the two handlers that cause it.
Own the policy call for a whole estate: which authority you pin to, what that forecloses, and how you keep the choice from silently breaking a future importer.
## Two registries, two authorities There are two independent lists of authentication scheme names in play, produced by different projects for different purposes, and they do not agree. The first is the **collection format's declaration**. The `auth` object's `type` member is a string constrained by an enum of eleven values: `apikey`, `awsv4`, `basic`, `bearer`, `digest`, `edgegrid`, `hawk`, `noauth`, `oauth1`, `oauth2` and `ntlm`. That enum is what a schema validator enforces. The second is the **runtime's handler registry**. The runtime keeps an `authorizer` directory of handler modules and registers each one by name through `AuthLoader.addHandler`, which also checks that the module exposes the four hooks a handler must have — `init`, `pre`, `sign` and `post` — and throws at load time if any is missing. Thirteen handlers go into that registry: the eleven the format declares, plus `jwt` and `asap`. | Scheme | Declared by the format? | Handler registered by the runtime? | |---|---|---| | `apikey`, `awsv4`, `basic`, `bearer` | yes | yes | | `digest`, `edgegrid`, `hawk`, `ntlm` | yes | yes | | `oauth1`, `oauth2`, `noauth` | yes | yes | | `jwt` | **no** | yes | | `asap` | **no** | yes | The asymmetry runs one way only: every declared value has a handler, and two handlers have no declared value. ## What a file naming `jwt` actually does Follow the document through the two paths and the apparent paradox disappears: 1. **Loaded into the object model.** The SDK's `RequestAuth.isValidType` accepts any string except the literal `'type'`. It does not know the format's enum exists. `jwt` is stored as the selector, a matching parameter list is created for it, and the value round-trips through serialisation unchanged. 2. **Executed by the runner.** The pre-send auth step calls `AuthLoader.getHandler('jwt')`, finds the registered handler, and hands it the auth interface to sign with. The request goes out signed. Nothing anywhere in that path reads the enum. 3. **Validated against the schema.** A tool that checks the document against the published collection schema compares `type` against the enum, finds `jwt` absent, and reports a failure. That verdict is correct on its own terms and says nothing about whether the collection runs. So the file is simultaneously **executable and schema-invalid**, and both statements are true because they are answering different questions. ## Why you must not merge the two lists The tempting shortcut is to answer "what auth types are there?" with the union — thirteen names. That is wrong in a way that matters: - **It over-promises portability.** Anything that validates before accepting a document — an importer, a linter, a schema-driven editor, a converter — enforces the enum. A collection built around `jwt` or `asap` will be rejected there while running perfectly in a runner. - **It under-explains failures.** When somebody reports "my collection is invalid but it works", the union model has no explanation to offer. The two-authority model answers it in one sentence. - **It attributes the wrong owner.** `jwt` and `asap` are the runtime's, not the format's. Saying "the format supports `jwt`" is a factual error about which project declares what. ## Practical consequences - **Decide which authority you are pinning to.** If documents in your repository must pass a schema check in the pipeline, restrict yourself to the declared eleven. If they only ever go to a runner, the extra handlers are available to you. - **Expect no error from the runner for an undeclared type it does know.** There is no warning path for `jwt`; it is a first-class handler as far as execution is concerned. - **Expect no help from the runner for a type it does not know.** An unrecognised name is not a hard failure either; the run warns and carries on unsigned. - **Do not infer the enum from the directory listing, or the directory from the enum.** They are maintained separately and there is no generation step tying one to the other. - **State your source when you answer.** "The format declares eleven" and "the runtime registers thirteen" are both correct and neither is a complete answer on its own.
- Does the asymmetry ever run the other way — a declared scheme with no handler?Not in the shipped set. All eleven declared values have registered handlers; the two extras, `jwt` and `asap`, are handlers with no declared value. So a document restricted to the format's enum is always executable, while an executable document is not always schema-valid.
- Which side should a team standardise on when collections are checked into a repository?Whichever side your pipeline actually enforces. If a schema check gates merges, the declared eleven is the safe set and an undeclared type will fail the build. If the only consumer is the runner, the extra handlers are usable — but record that choice, because a future importer or converter will reject those documents.
saying these in an interview costs you the question
- Quotes the union of enum and handlers as the auth types
- Says the format declares jwt and asap
- Claims a runner validates auth.type against the collection schema
- Assumes the handler registry is generated from the enum
- Concludes an undeclared type cannot be executed at all