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]

Reply via email to