For separation of concern and to align with existing authorization implementation, it seems a good idea to allow authorization via an authorization-token (such as jwt) even for mqtt over ws.
Currently, the session-password is set to token if proxy is ws (https://github.com/absmach/mproxy/blob/main/pkg/websockets/websockets.go#L31-L54), and for 'mqtt over ws' the usual mqtt username/password is used. When working with authorization token, one could store the jwt as password when connecting as mqtt. However, by doing so, the http-socket has already been upgraded to ws. In addition, from a client-perspective, it is a more standard way to send a jwt token with the usual header-authorization vs the mqtt-password.
That being said, I haven't found a lot of resources about token-based-authorization for mqtt anyway.
ENHANCEMENT / Question
For separation of concern and to align with existing authorization implementation, it seems a good idea to allow authorization via an authorization-token (such as jwt) even for mqtt over ws.
Currently, the session-password is set to token if proxy is ws (https://github.com/absmach/mproxy/blob/main/pkg/websockets/websockets.go#L31-L54), and for 'mqtt over ws' the usual mqtt username/password is used. When working with authorization token, one could store the jwt as password when connecting as mqtt. However, by doing so, the http-socket has already been upgraded to ws. In addition, from a client-perspective, it is a more standard way to send a jwt token with the usual header-authorization vs the mqtt-password.
That being said, I haven't found a lot of resources about token-based-authorization for mqtt anyway.