Is auth with Bearer JWT token supported

[CarlosNano]

We use authentication based on a Bearer JWT token for other APIs over HTTP, using an HTTP client. To do this, we add the Bearer token in the request header.

Is it possible to set up authentication with a Bearer JWT token in mqtt-nio, instead of using a username and password?

[adam-fowler]

Are you connecting to the MQTT server using WebSocket? I don't know how else you'd connect to a MQTT server via HTTP?

[CarlosNano]

Yes, I would like to connect using websockets. Is this possible?

[adam-fowler]

Yes this is possible and you can add additional headers at connection time using initialRequestHeaders of MQTTClient.WebSocketConfiguration eg

try MQTTClient(
    host: Self.hostname,
    port: 8081,
    identifier: identifier,
    logger: self.logger,
    configuration: .init(
        timeout: .seconds(5),
        useSSL: true,
        tlsConfiguration: Self.getTLSConfiguration(),
        sniServerName: "soto.codes",
        webSocketConfiguration: .init(
            urlPath: "/mqtt", initialRequestHeaders: ["Authorization": "bearer askjfhdslkjfhsdkljf"]
        )
    )
)

[CarlosNano]

I keep getting the error: ioOnClosedChannel

Maybe it not related and I may be wrong, but my understanding is the token should be at the end of the list of protocols with the key: Sec-WebSocket-Protocol and value "mqtt, <access-token>"

Is this something mptt-nio does on its own?

The only reference I could find for Sec-WebSocket-Protocol is this

Thanks for the help

[adam-fowler]

I didn't realise you needed to add the token on the end of the Sec-WebSocket-Protocol. I can look at not overriding this

EDIT actually this code should send the access token on. So you should be able to set the initialRequestHeaders to initialRequestHeaders: ["Sec-WebSocket-Protocol": "bearer askjfhdslkjfhsdkljf"]. The "Sec-WebSocket-Protocol" header will get appended to the mqtt value I have already added.

[CarlosNano]

I may be wrong but HTTPHeaders is not appending the content to the header Sec-WebSocket-Protocol, it's actually creating another tuple. So it will have two tuple with Sec-WebSocket-Protocol:

2 : 2 elements
        - .0 : "Sec-WebSocket-Protocol"
        - .1 : "mqtt"
      ▿ 3 : 2 elements
        - .0 : "Sec-WebSocket-Protocol"
        - .1 : "bearer {{token}}"

Then is converted to data to the ChannelHandlerContext so I assume is sent like that?

In the server I only get one header, the first one:

"Sec-WebSocket-Protocol": "mqtt"

[adam-fowler]

Adding additional key, value tuples should mean they merged. That is how I understand the NIOHTTP1 http header type works. I'll have to double check.

[adam-fowler]

I checked with Wireshark to see what is sent and this is what I get

Frame 11: 323 bytes on wire (2584 bits), 323 bytes captured (2584 bits) on interface lo0, id 0
Null/Loopback
Internet Protocol Version 6, Src: ::1, Dst: ::1
Transmission Control Protocol, Src Port: 62303, Dst Port: 8080, Seq: 1, Ack: 1, Len: 247
Hypertext Transfer Protocol
    GET /mqtt HTTP/1.1\r\n
    Content-Length: 0\r\n
    host: localhost:8080\r\n
    Sec-WebSocket-Protocol: mqtt\r\n
    Sec-WebSocket-Protocol: bearer 34598435\r\n
    Connection: upgrade\r\n
    Upgrade: websocket\r\n
    Sec-WebSocket-Key: PZFQvlr0a4KZcvmVMrHByg==\r\n
    Sec-WebSocket-Version: 13\r\n
    \r\n
    [Response in frame: 13]
    [Full request URI: http://localhost:8080/mqtt]

Having multiple versions of a header in the list is equivalent to having a comma separated list

[CarlosNano]

Oh nice, thanks for double checking this. So the sender sends both headers.

Is the header field for Sec-WebSocket-Protocol a comma-separated list.

I was trying to read over the http protocol and this is what I found:

A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
(https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2)

I'm not an expert in http, so I maybe I'm missing something here.