Broker Auth

MQTT brokers act as central hubs for message routing, making their authentication mechanisms critical to securing IoT communications. Proper broker authentication ensures only authorized clients can publish or subscribe to topics, mitigating risks like unauthorized data access or device impersonation. This section explores three primary authentication methods: username/password, certificate-based, and token-based approaches, along with implementation considerations.

Username/Password Authentication¶

The simplest and most common method involves requiring clients to provide a username and password during the MQTT connection. Brokers like Mosquitto or Eclipse Mosquitto support this via configuration files.

Implementation¶

Broker Configuration:

# Example Mosquitto config (mosquitto.conf)
allow_anonymous false
password_file /etc/mosquitto/pwfile

The password_file contains hashed credentials (e.g., using mosquitto_passwd).

Client Connection:
```
mosquitto_sub -h broker.example.com -u username -P password -t "sensor/#"
```
Passwords must be transmitted over TLS to prevent interception (see "Secure Transport" below).

Vulnerabilities & Mitigations¶

Brute-force attacks: Use strong, randomized passwords and enforce complexity rules.
Password reuse: Avoid reusing credentials across systems.

Certificate-Based Authentication (TLS Client Certificates)¶

Certificate-based authentication leverages TLS to verify client identities using X.509 certificates. This method is ideal for high-security environments.

Implementation¶

Generate Client Certificate:
```
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout client.key -out client.crt
```
This creates a self-signed certificate (for testing; production requires a CA-signed cert).

Broker Configuration:

# Example Mosquitto config
listener 8883
cafile /path/to/ca.crt
certfile /path/to/broker.crt
keyfile /path/to/broker.key
require_certificate true

The broker validates client certificates against the CA's trust store.

Client Connection:

mosquitto_sub -h broker.example.com -p 8883 --cert client.crt --key client.key -t "secure/#"

Ensure the client's certificate is signed by the broker's trusted CA.

Advantages¶

Eliminates password storage on clients.
Prevents replay attacks via certificate revocation lists (CRLs).

Token-Based Authentication¶

Token-based authentication uses opaque access tokens (e.g., JWTs) instead of passwords. Tokens are often issued via HTTP APIs and validated by the broker.

Implementation¶

Token Generation:

# Example using a JWT library (Python)
import jwt
token = jwt.encode({"user": "device123", "exp": 1698765432}, "secret_key", algorithm="HS256")

Tokens include claims like user identity and expiration time.

Broker Configuration:
Integrate with an HTTP endpoint to validate tokens (e.g., using auth_http in Mosquitto).
Example config:
```
auth_http /path/to/token_validator
```
The validator checks the token's signature and claims against a database or JWT library.

Client Connection:

mosquitto_sub -h broker.example.com -u "token" -P "your_jwt_token_here" -t "api/#"

Tokens should be short-lived and transmitted securely.

Use Cases¶

APIs requiring scoped permissions (e.g., read-only access to specific topics).
Integration with identity providers (e.g., OAuth2).

Additional Considerations¶

Secure Transport: Always use TLS (port 8883) to encrypt credentials and tokens in transit.
Rate Limiting: Prevent brute-force attacks by limiting connection attempts.
Audit Logs: Monitor authentication failures and successful logins.
Key Management: For certificate-based systems, securely store private keys and rotate them periodically.

Key takeaways¶

Username/password is simple but vulnerable to interception; always use TLS.
Certificate-based authentication provides strong identity verification but requires careful certificate management.
Token-based methods enable fine-grained access control but demand secure token issuance and validation.
Combine these methods with TLS, rate limiting, and audit logging for robust MQTT security.