Async API Security

Configure security schemes for async event APIs. Covers SASL authentication, OAuth2, X.509 certificates, encryption, and the OR/AND security requirements model.

February 25, 2026

Async APIs have distinct security requirements compared to REST and GraphQL. Message brokers use SASL mechanisms, mTLS certificates, and encryption rather than HTTP headers and cookies. NeoArc supports a comprehensive set of security scheme types covering all common broker authentication patterns.

Security Scheme Types

Category	Type	Use Case
HTTP	Bearer (basic/bearer/digest)	API gateways, management endpoints, Schema Registry
HTTP	HTTP API Key (header/query/cookie)	Service-to-service API calls
Broker	API Key (user/password)	Broker-native key-based authentication
Broker	User/Password	Simple username and password authentication
Certificate	X.509	mTLS with client certificates
Encryption	Symmetric Encryption	Shared-secret message encryption
Encryption	Asymmetric Encryption	Public-key message encryption
SASL	PLAIN	SASL/PLAIN (username and password, typically over TLS)
SASL	SCRAM-SHA-256	SASL/SCRAM with SHA-256 (Kafka default)
SASL	SCRAM-SHA-512	SASL/SCRAM with SHA-512 (stronger hash)
SASL	GSSAPI (Kerberos)	Enterprise Kerberos authentication
Federated	OAuth2	Token-based with scopes (4 grant flows)
Federated	OpenID Connect	Identity-aware authentication via OIDC discovery

Security Requirements Model

Security requirements follow an OR-of-AND pattern matching the AsyncAPI specification. Each inner array represents an AND group (all schemes must be satisfied). The outer array represents OR alternatives (any group is sufficient).

{
  "defaultSecurityRequirements": [
    [
      { "schemeId": "scram-sha-256" },
      { "schemeId": "oauth2", "scopes": ["events:publish"] }
    ],
    [
      { "schemeId": "x509" }
    ]
  ]
}

In this example, a client can authenticate by either:

Providing both SCRAM-SHA-256 credentials and an OAuth2 token with events:publish scope, or
Presenting a valid X.509 client certificate

SASL Authentication

SASL schemes are the primary authentication mechanism for Apache Kafka and other enterprise brokers.

SCRAM-SHA-256

Salted Challenge Response Authentication. The default for Kafka. Credentials are stored as salted hashes on the broker. Resistant to replay and dictionary attacks.

SCRAM-SHA-512

Stronger variant of SCRAM using SHA-512. Use when security policy requires longer hash lengths.

SASL/PLAIN

Simple username/password over TLS. Common for development and managed Kafka services (e.g. Confluent Cloud). Must always be used with TLS.

GSSAPI (Kerberos)

Enterprise Kerberos authentication via the GSSAPI mechanism. Used in on-premises deployments integrated with Active Directory or MIT Kerberos.

OAuth2 for Async APIs

OAuth2 in async APIs typically uses the client credentials flow for service-to-service communication. Scopes control which topics a service can publish to or subscribe from.

Per-Operation Security

Individual operations can override the API-level default security requirements. This is useful when different operations require different authentication levels. For example, a publish operation might require OAuth2 with events:publish scope, while a subscribe operation requires events:subscribe.

Rename Propagation

When you rename a security scheme ID or an OAuth2 scope in the API definition editor, the change automatically cascades to all security requirement references across operations. This maintains consistency without manual find-and-replace.