Overriding top-level security with a empty operation level security array

[nickeeex]

The OAS specifies the operation level security object as follows:

A declaration of which security mechanisms can be used for this operation. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. This definition overrides any declared top-level security. To remove a top-level security declaration, an empty array can be used.

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#fixed-fields-8

The overriding with a empty array seems to be a problem when creating the OpenApiDocument from a Swagger 2.0 / OAS string as it gets deserialized into a empty list thus removing the information that the operation should override the security defined on the top level.

Example of operation level security that does not override the top-level one:
"security": []

Example that does override it but does not follow the spec
"security": [{}]

[dansoper]

I've just stumbled upon this bug too, and it affected me because I wanted to be able to define a single route without security.

Looking at the source here, I can see the problem

• OpenApiOperation.Security is initialized as an empty List. Would there be any harm if it was initialized as null? I guess this would be a problem as soon as someone wants to do Security.Add() without realising it hadn't been initialized.
• OpenApiOperation.SerializeAsV3 uses WriteOptionalCollection for the Security property, which ignores any null or empty lists. We need an alternative method which ignores null objects, but writes empty lists - I'm not sure if one exists.

I've tried a variety of workarounds, but none have worked for me yet. I think I'm going to have to override the SwaggerMiddleware, and specifically replace
"security": [ null ]
with
"security": []

before sending the JSON response.

[darrelmiller]

This is one of those "it's not actually a bug" but it confuses enough people that it warrants adding support for the empty array. See #521 for a long conversation about it.

But just to clarify, adding an array that contains an empty object is the correct way to be explicit about an operation allowing anonymous access. An empty array simply says nothing about the security requirements of the operation. However, we can assume that if you are not telling a consumer anything about the security requirements, then you probably should allow anonymous access.

[darrelmiller]

I'm going to close this as by design. I don't want to get in a place where sometimes, not describing behaviour means something and sometimes it doesn't. An empty array is equivalent to not including the security property. i.e. it tells you nothing about the security of the API. An array with an item that contains an empty security requirement is explicitly saying anonymous access is allowed. It does not say you cannot call the API with an authentication header.

OpenAPI has a philosophy that it describes what is possible, without saying what is not possible. This was an explicit decision.