Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JWT] Enable configurable early token refresh in Java Client #22314

Open
2 tasks done
damienburke opened this issue Mar 20, 2024 · 3 comments
Open
2 tasks done

[JWT] Enable configurable early token refresh in Java Client #22314

damienburke opened this issue Mar 20, 2024 · 3 comments
Assignees

Comments

@damienburke
Copy link

damienburke commented Mar 20, 2024

Search before asking

  • I searched in the issues and found nothing similar.

Motivation

Same as this #13951 - but to support the "simpler" JWT auth workflow/client setup.

Solution

Similar to AuthenticationOAuth2 - firstly AuthenticationToken will need to cache the authenticating JWT in a transient volatile field.

This value will also be injected into AuthenticationDataToken - and getCommandData will now return this value - and not lazily generate a new token.

Meanwhile, a scheduled task will be created, similar to #13951 to refresh the cached token.

Respect backwards compatibility.

Alternatives

Complete #13951 - and use it. In some cases though, using the OAuth client is not appropriate. For example, when using Vault as an OIDC - while also providing apps a Vault agent to do the Vault auth - a clientID and secretID are not needed by the app (as again the OIDC/Vault auth is abstracted away)

Anything else?

No response

Are you willing to submit a PR?

  • I'm willing to submit a PR!
@damienburke
Copy link
Author

@lhotari - if u have some time, can u let me know ur thoughts on the feasibility of having this functionality added? The current details are hopefully enough to enable that conversation - and if no immediate/obvious blockers or issues, I can spend some more time identifying all the changes, and continuing conversation on the dev email distribution. Thanks

@lhotari
Copy link
Member

lhotari commented Mar 22, 2024

if u have some time, can u let me know ur thoughts on the feasibility of having this functionality added? The current details are hopefully enough to enable that conversation - and if no immediate/obvious blockers or issues, I can spend some more time identifying all the changes, and continuing conversation on the dev email distribution. Thanks

@damienburke yes, the plan you have presented looks good to me.

For example, when using Vault as an OIDC - while also providing apps a Vault agent to do the Vault auth - a clientID and secretID are not needed by the app (as again the OIDC/Vault auth is abstracted away)

Just curious, how is this configured with the Pulsar client?

@damienburke
Copy link
Author

Thanks @lhotari

how is this configured with the Pulsar client?

Sure. We configure the token supplier method to make the Vault API call. This call is proxied through a Vault Agent - and the Vault Agent handles the auth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants