Robbie, Thanks for pointing out into JmsConnectionExtensions. That is exactly what I was looking for.
Kind Regards, Alex On Wed, 13 May 2020 at 18:08, Robbie Gemmell <[email protected]> wrote: > The client has extensions for providing credentials at each connection > point, e.g: > > https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnectionExtensions.java#L74-L89 > > https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/test/java/org/apache/qpid/jms/integration/SaslIntegrationTest.java#L590 > > On Wed, 13 May 2020 at 17:18, Oleksandr Rudyy <[email protected]> wrote: > > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
