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

Persist refreshed tokens #408

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

benlangfeld
Copy link
Contributor

@benlangfeld benlangfeld commented Apr 16, 2019

See #409

This is based on #407, and should be rebased once that is merged.

When the authorization server rotates key IDs, we might encounter a token with a kid which the server no longer reports in discovery. Currently, json-jwt raises an exception and the user must expend a lot of effort debugging. We can help by simply assuming the token is expired and forcing token refresh.
This allows consumers to get access to the new refresh token when the ID token is refreshed. This is important because refresh tokens are single-use. If the consumer code needs to refresh the ID token a second time, it will need to use an updated refresh token.
In case the ID token is refreshed, client code will also need to know the new refresh token in order to pass it forward.
@cben
Copy link
Collaborator

cben commented Dec 1, 2019

Friendly ping 👋, as #407 has been merged, would you like to rebase and advance this?

AFAICT, this prepares some APIs but doesn't yet write back a kubeconfig file, right?

@cben
Copy link
Collaborator

cben commented Dec 1, 2019

BTW, preparing some APIs can be a great stand-alone PR 👍, not saying you have to do it all at once.

@cben
Copy link
Collaborator

cben commented Mar 20, 2023

Do'h I finally get it. Currently, (once id-token from Config is expired) each OIDCAuthProvider.token call creates a fresh OpenIDConnect::Client.new(...) so the refresh_token it returns gets discarded entirely. ☹️

  • This PR doesn't yet persist to a file (and that'd deserve separate discussion whether it needs to be opt-in) but:
  • it does bundle refresh_token with the returned access token 👍
  • it does bundle it into auth_options[:refresh_token] that goes into Config::Context object (and typically from there into Client object(s)). 👍
  • I don't see it being used for next renewal yet?

As I now mentioned on #606, need to find right place where to save it... current README advice to renew auth by re-creating all objects, even the Config, is bad.

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

Successfully merging this pull request may close these issues.

2 participants