-
-
Notifications
You must be signed in to change notification settings - Fork 343
Description
Problem
Currently, AsyncAPI 3.x only allows expressing OR semantics between multiple security schemes using the security array:
security:
- $ref: '#/components/securitySchemes/saslScram'
- $ref: '#/components/securitySchemes/mtls'
This means either SASL/SCRAM or mTLS can authorize a connection.
However, in many real-world scenarios, a server or operation may require multiple authentication schemes simultaneously (logical AND), for example:
SASL/SCRAM and a valid client certificate (mTLS) for a Kafka broker
Currently, there is no spec-compliant way to enforce both requirements in AsyncAPI 3.x without using a vendor extension (x- fields) or describing it only in prose. This limitation prevents full machine-readable documentation and automated validation of multi-factor authentication requirements.
Current workarounds
- Use only one $ref and describe the second requirement in description
Pros: Spec-compliant
Cons: Not machine-enforceable, tooling cannot validate - Vendor extension
Pros: Documents AND requirement
Cons: Non-standard, tooling may ignore it
Neither approach is ideal for consistent, spec-compliant multi-scheme security modeling.
Proposal
Introduce a native, spec-supported syntax to express AND logic between multiple security schemes in a single security requirement object. Possible approaches:
- Array of $refs array.
security:
- - $ref: '#/components/securitySchemes/saslScram'
- $ref: '#/components/securitySchemes/mtls'
- Named keys with logical AND semantics (similar to v2):
security:
- saslScram: []
mtls: []
Requirements for tooling: Studio, CLI validator, and generators should enforce that all schemes in a single requirement object are required.