Server security

Server security refers to the measures and practices implemented to protect servers from unauthorized access, data breaches, and other security threats. Server security involves implementing various security mechanisms to ensure the confidentiality, integrity, and availability of server resources.

In the context of AsyncAPI, securing servers ensures secure exchange of messages between clients and servers. While also protecting sensitive data, preventing unauthorized access, and maintaining the overall security of the API or server.

You can describe how your server is secured with the security property where you define which security schemes can be used with the server in context. Each server in the AsyncAPI document can have one or more security schemes declared. A security scheme defines a security requirement that must be satisfied to authorize an operation, such as an API key or a username and password.

Here is an example of adding security to your server, demonstrating that different servers can employ various security mechanisms:

1asyncapi: 3.0.0
2info:
3  title: Streetlights Kafka API
4  version: 1.0.0
5servers:
6  scram-connections:
7    host: 'test.mykafkacluster.org:18092'
8    protocol: kafka-secure
9    description: Test broker secured with scramSha256
10    security:
11      - $ref: '#/components/securitySchemes/saslScram'
12  mtls-connections:
13    host: 'test.mykafkacluster.org:28092'
14    protocol: kafka-secure
15    description: Test broker secured with X509
16    security:
17      - $ref: '#/components/securitySchemes/certs'
18components:
19  securitySchemes:
20    saslScram:
21      type: scramSha256
22      description: Provide your username and password for SASL/SCRAM authentication
23    certs:
24      type: X509
25      description: Download the certificate files from service provider

Here is an illustration of securing servers:

Loading diagram...

Here are some of the security schemes that AsyncAPI supports:

User/Password
```
type: userPassword
```
API key (either as a user or as a password)
```
1type: apiKey
2in: user
```
X.509 certificate
```
type: X509
```
End-to-end encryption (either symmetric or asymmetric)
```
type: symmetricEncryption
```
HTTP authentication
```
1type: http
2scheme: basic
```

HTTP API key

1type: httpApiKey
2name: api_key
3in: header

JWT Bearer

1type: http
2scheme: bearer
3bearerFormat: JWT

Implicit oauth2

1type: oauth2
2flows:
3  implicit:
4    authorizationUrl: https://example.com/api/oauth/dialog
5    availableScopes:
6      write:pets: modify pets in your account
7      read:pets: read your pets
8scopes:
9  - 'write:pets'

SASL (Simple Authentication and Security Layer) as defined in RFC4422
```
type: scramSha512
```

Although the security property is not mandatory, it is a good practice to always secure your server(s) in production. Similarly, having multiple security schemes declared does not necessarily mean that the server is more secure; it depends on other factors such as the protocol used, use case, business perspective, and more. Additionally, you can also add security at the operation level.