Reauthentication of expired token

[rylev]

Currently the user is expected to recreate a client when a token is expired. However, we have enough information to be able to tell if a token will expire or not. We could either reauthenticate for the user. or give the user some sort of way of doing thing that's less destructive then completely recreating the client.

Here is where exec is happening to get an auth token. The token is being taken from ExecCredentialStatus but expiration_timestamp is ignored. The token is then just stuffed into the headers.

The question is what should we do. Should we keep track of when the token will expire and if the user is past that timestamp when they use the client, reauthenticate on their behalf? Or do we return some sort of error and then give the user the change to reauthenticate themselves?

[clux]

Good question. It's a pretty non-trivial thing to solve, and it only matters in the ~/.kube/config setup, and not in the in-cluster setup (which is generally production, but not always). However, if there's a good solution to it, it would be good to do.

IIRC kubectl will do it on the users behalf, then update the local kube config. Come to think of it, I
think this is a duplicate of #72 and there's useful information if you follow in to #70.

[bacongobbler]

I did some digging here. Go's oauth2 token exposes API calls to determine if the token has expired. client-go will check if the token needs to be refreshed or not. The client auth plugins determine the validity of the token, calling out to external APIs to refresh the token.

Here's the location in Go's oauth2 library the token's validity is calculated: https://github.com/golang/oauth2/blob/bf48bf16ab8d622ce64ec6ce98d2c98f916b6303/token.go#L133-L136

Here's GCP's client auth package for kubectl, where it determines whether kubectl needs to refresh the token or not: https://github.com/kubernetes/client-go/blob/master/plugin/pkg/client/auth/gcp/gcp.go#L214-L230

Azure's client auth package: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/azure/azure.go#L205-L217

Exec client auth: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/exec/exec.go#L247-L252

oidc: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/oidc/oidc.go#L225-L240

The openstack plugin looks to have been converted to an exec plugin, so nothing to see there.

It's interesting to note that each client auth plugin appears to assess the validity of the token independent of each other. This appears to imply that each auth plugin's token validity can differ from provider to provider, though from looking closer at each provider, they all seem to just check the expiry date, so I'm not sure whether this was intentional or just an over-engineered solution in client-go.

In summary, your assessment that client-go will check the token's validity and perform a token refresh on the user's behalf seems correct here. Based on the existing client auth plugins, they all appear to check the validity of the token in the same manner and refresh the token upon request, so it appears that a generic token refresh based on the expiry date should work across all auth providers.

This may also be a duplicate of #84, as it discusses how tokens are refreshed using kubectl's client auth packages.

[clux]

Thanks for looking into this @bacongobbler that is very helpul. This has now been fixed by @thomastaylor312 and it will be released in the next minor.