A spec can say that one operation needs no authentication, which OpenAPI spells as an empty security on the operation, overriding the document's default:
security:
- bearer: []
paths:
/private:
get: { operationId: getPrivate, ... }
/public:
get:
operationId: getPublic
security: [] # explicitly public
...Both calls carry the credential:
authorization headers: ["Bearer s3cr3t" "Bearer s3cr3t"]
The client applies its auth provider in do, for every request, and no per-operation security reaches the IR at all. ir.OperationDef has no security field; SecurityReq exists in the IR and nothing populates it.
Why it is worth fixing
Sending a bearer token to an endpoint documented as needing none is a small credential leak with no upside: it goes to whatever host the operation targets, is recorded in that server's logs, and the spec explicitly said not to. An unauthenticated endpoint is also the one most likely to be served by something other than the API itself.
The narrow, unambiguous case is an operation declaring security: []. It says exactly one thing, and the client currently ignores it.
Deliberately not proposed here
Choosing between several schemes per operation, or requiring several at once (security: [{a: [], b: []}] versus [{a: []}, {b: []}]), is a bigger design question: the client holds one AuthProvider, and honoring per-operation scheme selection means either several providers or a provider that knows which scheme it satisfies. That deserves its own issue if it comes up. The opt-out does not depend on it.
A spec can say that one operation needs no authentication, which OpenAPI spells as an empty
securityon the operation, overriding the document's default:Both calls carry the credential:
The client applies its auth provider in
do, for every request, and no per-operation security reaches the IR at all.ir.OperationDefhas no security field;SecurityReqexists in the IR and nothing populates it.Why it is worth fixing
Sending a bearer token to an endpoint documented as needing none is a small credential leak with no upside: it goes to whatever host the operation targets, is recorded in that server's logs, and the spec explicitly said not to. An unauthenticated endpoint is also the one most likely to be served by something other than the API itself.
The narrow, unambiguous case is an operation declaring
security: []. It says exactly one thing, and the client currently ignores it.Deliberately not proposed here
Choosing between several schemes per operation, or requiring several at once (
security: [{a: [], b: []}]versus[{a: []}, {b: []}]), is a bigger design question: the client holds oneAuthProvider, and honoring per-operation scheme selection means either several providers or a provider that knows which scheme it satisfies. That deserves its own issue if it comes up. The opt-out does not depend on it.