Support OAUTHBEARER SASL mechanism in HonoClient and service implementations

[sophokles73]

Currently, components authenticate each other based on SASL PLAIN. However, under the hood, the server components forward the credentials provided by the client to Hono Auth in order to retrieve a JWT asserting the client's identity and authorities.

This mechanism has the big drawback of requiring the server to close the connection with the client once the token expires in order to trigger the client to start a new SASL handshake so that the server can retrieve a new token from Hono Auth.

It seems more desirable to allow the client to authenticate using a token in the first place. This way, the client can also refresh the token on its own behalf and update the token on the server over the (still) existing connection using e.g. AMQP 1.0 Claims based Security.

See A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

[avgustinmm]

I stuck into the same issue. I'm not sure how the adapter using HonoClient should react in this case (if the hono client doesn't handle this by itself).
First of all the problem is not directly visible - e.g. it is hard to be identified if there is authentication issue or something else as a problem. Then, even I find out that I should re-establish clients then I should do this while having many messages to send (I don't want to return errors to device and left it to handle that - not a nice for device. It may not be able to handle it). Since I do sending in multiple thread I should some how sync the re-establishment of the new client, make all send actions to wait for this single re-establishment. This is a complex task to be made effectively and safe.
At the end I'd vote for this re-authentication to be handled invisibly in the HonoClient.

[sophokles73]

I don't want to return errors to device and left it to handle that - not a nice for device. It may not be able to handle it

They will need to be able to handle such errors in any case because the protocol adapter might not be able to reconnect at all. Or the protocol adapter instance might be shut down and re-scheduled to another node by Kubernetes.

[avgustinmm]

They may just give up in this case. So, the adapter should do its best to handle the events without returning them to device. Of course 100% guaranty form the adapter side is not possible.

[Alfusainey]

@sophokles73 I want to take a look into this but is wondering if its still an issue?

[sophokles73]

@Alfusainey it is currently not a priority for me. However, if you would like to work on it, be my guest ...