EMQX Authentication Chains Need Explicit Failure Semantics
An authentication chain is useful when an MQTT deployment must support several client populations, such as certificate users, password devices, and JWT-bearing applications. The chain evaluates authenticators in order. The security outcome depends as much on the handling of errors and ignored results as on the first successful match.
Follow the decision path
EMQX documentation describes an authentication chain in which multiple authenticators are evaluated in a defined sequence. A client may be accepted, rejected, or passed to the next authenticator. An external HTTP authenticator returns a status code and body. Documentation for the HTTP authenticator states that certain 4xx and 5xx responses are treated as ignore and continue the chain rather than producing an immediate denial.
This behavior can be intentional for compatibility, but it creates a fail-open risk when the external provider is the authoritative decision point. If the provider times out, returns an unexpected status, or is misconfigured, the client may fall through to a weaker authenticator or an anonymous path.
Separate authentication from authorization
A successful login does not decide which topics a client can publish or subscribe to. EMQX supports authorization rules, access control lists, and external authorization sources. JWT and HTTP authentication responses can carry ACL data as part of the authentication result.
Treat the embedded ACL as a convenience, not the only control. Use authorization rules that can be independently inspected and tested. Whitelist mode makes the default deny model clear. In blacklist mode, an unexpected rule match can leave a topic open.
Review the provider contract
For an HTTP authenticator, record the URL, TLS trust, timeout, retry policy, response schema, and what each status code means. Ensure that the provider returns an explicit rejection for a bad credential rather than a generic server error that the chain interprets as ignore.
For JWT authenticators, validate issuer, audience, signature algorithm, key source, expiry, and required claims. A JWKS endpoint that is unavailable must not cause a token to be accepted through another path. Cache public keys with a bounded refresh policy and retain a known-good key set during a short outage.
Inventory clients and topics
Build a matrix of client identity, authenticator, authorization source, publish topics, subscribe topics, and last credential rotation. Include bridges, connector accounts, device fleets, and internal services. A device client that publishes telemetry should not be able to subscribe to command topics used by the control plane.
Use placeholders carefully. Topic patterns that derive from a client ID are safe only when the authenticated identity cannot choose an arbitrary client ID. Test a modified client ID and confirm that authorization still limits it to the intended topic.
Exercise failure modes
Stop the external authenticator in a test deployment and observe whether clients are denied or silently sent to the next path. Return malformed JSON, a slow response, and a 503. Verify that the broker's behavior matches the security design.
Then disable the network route to the provider and test again. The broker should not accept new clients merely because the authorization service is unreachable. Existing sessions should be handled according to an explicit policy, not an incidental default.
Authentication chains can support a realistic mix of legacy and modern clients. They need a written precedence model, observable decisions, and tests for every error path. Without those controls, a chain is only a list of code paths that someone hoped would reject the wrong client.
Top comments (0)