Clarify the shape of the SecurityRequirement Object

[magicmatatjahu]

Together with @smoya we wonder if we have a good understanding of the use of the SecurityRequirements Object item in the Server Object and Operation Object. The specification gives the shape for SecurityRequirement Object as:

Then, according to the definition, are we able to use two SecuritySchemas in one SecurityRequirement Object like:

security:
  - apiKeyScheme: []
    oauthScheme: ['...']
  - openIDScheme: []

?

It seems to me that we should describe it in a better way and if it is possible to use two schemas for one SecurityRequirement Object then we should also give an example using two schemas. If not then it still requires a precise description that only one schema is allowed for one SecurityRequirement Object.

cc @derberg @fmvilas @dalelane

[fmvilas]

That's a good question. I got this from OpenAPI and it doesn't clarify it either. My gut feeling is that it's possible and it's fine. So the following two examples should be equivalent:

security:
  - apiKeyScheme: []
    oauthScheme: ['...']

security:
  - apiKeyScheme: []
  - oauthScheme: ['...']

[magicmatatjahu]

@fmvilas Thanks for fast response!

So the following two examples should be equivalent:

Hmm, I don't think so 😅 As we read description for single SecurityRequirement Object:

When a list of Security Requirement Objects is defined on a Server object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the connection.

so when you have two schemas like:

- apiKeyScheme: []
  oauthScheme: ['...']

You need to satisfy to authorize the connection these two schemas, both apiKeyScheme AND oauthScheme. In the case:

- apiKeyScheme: []
- oauthScheme: ['...']

we need to satisfy apiKeyScheme OR oauthScheme. Of course I can be wrong, but for me array !== object.

[fmvilas]

Oh yeah, you're right. So there you go. If it's an object, it's an AND operation, otherwise, it's an OR.

[fmvilas]

Do we have an example of a use case in which we want to have the AND operation in security? I mean, a case in which we should meet all the defined security mechanisms? I can't think of any right now.

[smoya]

Do we have an example of a use case in which we want to have the AND operation in security? I mean, a case in which we should meet all the defined security mechanisms? I can't think of any right now.

Would it make sense that a server requires asymmetricEncryption for connection + userPassword or another mechanism for authentication? In that case, both would be required for the same connection to success.

[fmvilas]

Oh true, encryption. Now it's making me wonder if encryption should be there as a security mechanism 🤔 Maybe it can be a property of all Security Scheme Object, something like:

type: userPassword
encription: asymmetric # Optional. Could be "symmetric" or null too.

Given that it's the only one that's combinable with others. Or at least the only one I can think of.

[smoya]

Given that it's the only one that's combinable with others. Or at least the only one I can think of.

Thinking out of the box, wouldn't MFA be an actual use case here? Maybe not very clear with the current supported mechanisms, but still an option I think.

[magicmatatjahu]

I don't have any use case, but currently in the specification it is possible, and we should either describe it or remove this possibility.

[fmvilas]

Maybe MFA can be just another auth mechanism? Nobody complained that we don't have MFA support yet so I'm not sure how widespread this is.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️