Open AxelNennker opened 4 months ago
If the example was intended to show multiple alternative security requirements or combining an oauth2 security object with another non-oauth2 security object, then the second one should not be empty. Maybe the API is migrating from apiKey to oauth2 and is deprecating api_key.
I can understand your interpretation of this example. However, while I do not recall the nature of the example what it wanted to convey originally, what if it the intent was to say "hey, the entire (or some resource of the ) API had no security, and now we can secure it with oauth2" and thus the two entries? I think really this example is not intended to convey an overall good practice but simply that you have a list of choices you can apply to all or some surfaces of the API. More mechanical than overall good security.
I can understand your interpretation of this example. However, while I do not recall the nature of the example what it wanted to convey originally, what if it the intent was to say "hey, the entire (or some resource of the ) API had no security, and now we can secure it with oauth2" and thus the two entries? I think really this example is not intended to convey an overall good practice but simply that you have a list of choices you can apply to all or some surfaces of the API. More mechanical than overall good security.
So, you are agreeing that "no security" is not a good choice when we want to show multiple security options, right?!
On the matter of "Security Requirements Object" examples:
I would find an example valuable that shows the "Security Requirement Objects that contain multiple schemes require that all schemes MUST be satisfied" part of the spec. Something like:
security:
- modern_pet_auth_part_one:
- write:pets
- read:pets
modern_pet_auth_part_two: []
- legacy_pet_auth: []
In particular, I stumbled upon the first sentence of #security-requirement-object: "Lists the required security schemes to execute this operation.". I was expecting a list/an array, but the Security Requirement Object is a map. So first I thought the outer list (in the security of the Operation Object/OpenAPI Object) was meant. Such an example would have helped me clear the confusion more quickly.
I wonder why these "Optional OAuth2 security" examples were created in the first place.
I agree that an API can have several options how the API client authenticates but having oauth2 security or alternatively none seems not a good security practice.
e.g. here https://github.com/OAI/OpenAPI-Specification/blob/v3.2.0-dev/versions/3.0.3.md#optional-oauth2-security
If the example was intended to show multiple alternative security requirements or the combination of an oauth2 security object with another non-oauth2 security object, then the second one should not be empty. Maybe the API is migrating from apiKey to oauth2 and is deprecating api_key.