You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: