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