remove "Optional OAuth2 security" examples

[AxelNennker]

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.

{
  "security": [
    {
      "api_key": []
    },
    {
      "petstore_auth": [
        "write:pets",
        "read:pets"
      ]
    }
  ]
}

[miqui]

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.

[AxelNennker]

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?!

[thgoebel]

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.