Hi folks, The current JMS clients' support for OAUTH2 based authentication has a significant limitation when it is used in a production environment with short-lived tokens. When OAUTH2 access token expires, there is no way to update the token on an existing connection. The user would need to generate a new token and create a new connection. The failover feature cannot be used, as when the token expires, the failover functionality would try to re-establish connectivity with an old expired token.
I would like to start a discussion to improve the OAUTH2 based authentication support in both JMS clients for AMQP 1.0 and AMQP 0-x. I think it makes sense to provide a similar OAUTH2 authentication features in both clients. I created a confluence page [1] where I summarised some approaches how to solve the problem. Essentially, the solution can involve the following changes - extend the JMS API with ability to update the credentials - extend the JMS API with a hook to plug OAUTH2 implementation to obtain an access token directly on connection opening. That would allow users to create their own implementations for getting OAUTH2 token In the confluence page I described the following possible solutions for the issue 1. Add CredentialSupplier hook to supply the credentials 2. Observe authentication failure and update credentials on notification 3. Introduce a special failover mechanism 4. Generate token inside of the client via special pluggable mechanism I am sure there could be better ways to address the issue. The pooled connection factory implementations are also affected by the token expiration issue. What would be the best way to fix a limitation of current support for OAUTH2? Kind Regards, Alex [1] https://cwiki.apache.org/confluence/display/qpid/XOAUTH2+SASL+Mechanism+and+token+expiration
