2025-07-30 15:54:20 +00:00
|
|
|
# Authentication & Authorization via external HTTP server
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
If clients accessing the broker are managed by another application, it can implement API endpoints
|
2025-08-06 18:08:45 +00:00
|
|
|
that respond with information about client authentication and/or topic-level authorization.
|
|
|
|
|
|
|
|
- `amqtt.contrib.http.UserAuthHttpPlugin` (client authentication)
|
|
|
|
- `amqtt.contrib.http.TopicAuthHttpPlugin` (topic authorization)
|
|
|
|
|
|
|
|
Configuration of these plugins is identical (except for the uri name) so that they can be used independently, if desired.
|
|
|
|
|
2025-08-11 21:38:50 +00:00
|
|
|
# User Auth
|
2025-08-06 18:08:45 +00:00
|
|
|
|
|
|
|
See the [Request and Response Modes](#request-response-modes) section below for details on `params_mode` and `response_mode`.
|
2025-07-30 15:54:20 +00:00
|
|
|
|
|
|
|
!!! info "browser-based mqtt over websockets"
|
|
|
|
|
|
|
|
One of the primary use cases for this plugin is to enable browser-based applications to communicate with mqtt
|
|
|
|
over websockets.
|
|
|
|
|
|
|
|
!!! warning
|
|
|
|
Care must be taken to make sure the mqtt password is secure (encrypted).
|
|
|
|
|
|
|
|
For more implementation information:
|
|
|
|
|
|
|
|
??? info "recipe for authentication"
|
|
|
|
Provide the client id and username when webpage is initially rendered or passed to the mqtt initialization from stored
|
2025-08-05 15:56:05 +00:00
|
|
|
cookies. If application is secure, the user's password will already be stored as a hashed value and, therefore, cannot
|
|
|
|
be used in this context to authenticate a client. Instead, the application should create its own encrypted key (eg jwt)
|
|
|
|
which the server can then verify when the broker contacts the application.
|
2025-07-30 15:54:20 +00:00
|
|
|
|
|
|
|
??? example "mqtt in javascript"
|
|
|
|
Example initialization of mqtt in javascript:
|
|
|
|
|
|
|
|
import mqtt from 'mqtt';
|
|
|
|
const url = 'https://path.to.amqtt.broker';
|
|
|
|
const options = {
|
|
|
|
'myclientid',
|
|
|
|
connectTimeout: 30000,
|
|
|
|
username: 'myclientid',
|
|
|
|
password: '' // encrypted password
|
|
|
|
};
|
|
|
|
try {
|
|
|
|
const clientMqtt = await mqtt.connect(url, options);
|
|
|
|
|
2025-08-06 18:08:45 +00:00
|
|
|
::: amqtt.contrib.http.UserAuthHttpPlugin.Config
|
|
|
|
options:
|
|
|
|
show_source: false
|
|
|
|
heading_level: 4
|
|
|
|
extra:
|
|
|
|
class_style: "simple"
|
|
|
|
|
2025-08-11 21:38:50 +00:00
|
|
|
# Topic ACL
|
2025-08-06 18:08:45 +00:00
|
|
|
|
|
|
|
See the [Request and Response Modes](#request-response-modes) section below for details on `params_mode` and `response_mode`.
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-08-06 18:08:45 +00:00
|
|
|
::: amqtt.contrib.http.TopicAuthHttpPlugin.Config
|
2025-07-30 13:32:56 +00:00
|
|
|
options:
|
|
|
|
show_source: false
|
|
|
|
heading_level: 4
|
2025-07-30 15:54:20 +00:00
|
|
|
extra:
|
|
|
|
class_style: "simple"
|
2025-07-30 13:32:56 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
[//]: # (manually creating the heading so it doesn't show in the sidebar ToC)
|
2025-08-05 15:56:05 +00:00
|
|
|
[](){#request-response-modes}
|
|
|
|
<h2>Request and Response Modes</h2>
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
Each URI endpoint will receive different information in order to determine authentication and authorization;
|
|
|
|
format will depend on `params_mode` configuration attribute (`json` or `form`).:
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
*For user authentication, the request will contain:*
|
2025-07-26 19:47:49 +00:00
|
|
|
|
|
|
|
- username *(str)*
|
|
|
|
- password *(str)*
|
|
|
|
- client_id *(str)*
|
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
*For acl check, the request will contain:*
|
|
|
|
|
2025-07-26 19:47:49 +00:00
|
|
|
- username *(str)*
|
|
|
|
- client_id *(str)*
|
|
|
|
- topic *(str)*
|
2025-07-30 15:54:20 +00:00
|
|
|
- acc *(int)* : client can receive (1), can publish(2), can receive & publish (3) and can subscribe (4)
|
|
|
|
|
|
|
|
All endpoints should respond with the following, dependent on `response_mode` configuration attribute:
|
|
|
|
|
2025-08-05 15:56:05 +00:00
|
|
|
*In `status` mode:*
|
2025-07-30 15:54:20 +00:00
|
|
|
|
|
|
|
- status code: 2xx (granted) or 4xx(denied) or 5xx (noop)
|
|
|
|
|
|
|
|
!!! note "5xx response"
|
2025-08-06 18:08:45 +00:00
|
|
|
**noop** (no operation): plugin will not participate in the operation and will defer to another
|
|
|
|
plugin to determine access. if there is no other auth/filtering plugin, access will be denied.
|
2025-07-30 15:54:20 +00:00
|
|
|
|
|
|
|
*In `json` mode:*
|
|
|
|
|
|
|
|
- status code: 2xx
|
|
|
|
- content-type: application/json
|
2025-08-05 15:56:05 +00:00
|
|
|
- response: {'ok': True } (granted)
|
|
|
|
or {'ok': False, 'error': 'optional error message' } (denied)
|
|
|
|
or { 'error': 'optional error message' } (noop)
|
2025-07-30 15:54:20 +00:00
|
|
|
|
|
|
|
!!! note "excluded 'ok' key"
|
2025-08-06 18:08:45 +00:00
|
|
|
**noop** (no operation): plugin will not participate in the operation and will defer to another
|
|
|
|
plugin to determine access. if there is no other auth/filtering plugin, access will be denied.
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
*In `text` mode:*
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
- status code: 2xx
|
|
|
|
- content-type: text/plain
|
|
|
|
- response: 'ok' or 'error'
|
2025-07-26 19:47:49 +00:00
|
|
|
|
2025-07-30 15:54:20 +00:00
|
|
|
!!! note "noop not supported"
|
|
|
|
in text mode, noop (no operation) is not supported
|