Which authentication schemes does the `auth.type` enum in the Postman collection format declare?

## The declared list In the collection format, the `auth` object's `type` member is a string with an **enum constraint**. Any document validated against that schema must use one of these values: - `apikey` - `awsv4` - `basic` - `bearer` - `digest` - `edgegrid` - `hawk` - `noauth` - `oauth1` - `oauth2` - `ntlm` Eleven values, and that is the whole declared surface. `type` is also the auth object's **only required member**, so a file that omits it fails validation even if a scheme array is present and fully populated. ## Every value but one has a settings array Beside `type`, the format declares one property per scheme, named for the scheme, whose contents are an array of auth attributes. The exception is `noauth`, declared as an empty schema — the format's own comment on that line says anything is allowed under it, and in practice a `noauth` selection carries nothing. | `auth.type` value | Settings property declared beside it | |---|---| | `apikey` | `apikey` array of auth attributes | | `awsv4` | `awsv4` array of auth attributes | | `basic` | `basic` array of auth attributes | | `bearer` | `bearer` array of auth attributes | | `digest` | `digest` array of auth attributes | | `edgegrid` | `edgegrid` array of auth attributes | | `hawk` | `hawk` array of auth attributes | | `ntlm` | `ntlm` array of auth attributes | | `oauth1` | `oauth1` array of auth attributes | | `oauth2` | `oauth2` array of auth attributes | | `noauth` | none — declared as an empty schema | Note that the scheme arrays are all **optional**. Only the selector is mandatory, so `{"type": "basic"}` with no `basic` array is a perfectly valid auth object — it simply gives a signing handler nothing to work with. ## Spellings that catch people out - **`awsv4`.** The enum spells the AWS signing scheme `awsv4`, with the `v`. The file that implements the handler in a runner is named `aws4.js`, without it, and the handler is registered under the enum's spelling. If you are writing the value into a document by hand, `awsv4` is the one that matters; `aws4` is a source-file name and never appears as an `auth.type` value. - **`oauth1` and `oauth2`** are two separate enum values with two separate attribute arrays. They are not one value with a parameter. - **Everything is lower-case and unbroken.** No enum value uses camel case, a hyphen, or an underscore. `apiKey`, `no-auth` and `bearerToken` are all wrong, and none of them will be recognised anywhere. ## What this enum is, and what it is not The enum is the **file format's declaration** of which scheme names a document may legally use. That is a narrower statement than it sounds: 1. **It is not a capability list for a runner.** A program that executes collections keeps its own registry of signing handlers, which is a different set built by a different project. Do not read the enum as "the schemes that work". 2. **It is not enforced by the SDK.** The object model that loads a collection in memory does its own, far looser check on the scheme name and does not consult this enum at all. 3. **It is only enforced when something validates.** Importers, linters, schema-driven editors and converters that check a document against the published collection schema will reject a value outside the enum. A runner that simply loads and executes will not. The practical rule: when you are asked what auth types the format supports, answer with these eleven and say explicitly that you are quoting the **format's enum**. Presenting a merged list of "everything the enum declares plus everything a runner implements" is a factual error, because the two sets genuinely differ and each belongs to a different authority.