Made OIDC auth renewable according to the refresh token

[kcolford]

Overview

This makes it so that security teams that rely on their identity provider to decide when a user continues to be valid and have access (such as during user off boarding) won't have to manually invalidate a user's credentials in vault as well. This makes adoption much easier and automates important security steps.

Design of Change

We simply add a step that saves the access token, refresh token, and expiry info into the internal metadata for a token. Then during a renew we check these values and use the oauth2 library directly to refresh the value (this feature isn't supported in the hashicorp oidc library and that library was too confusing for me to go and make a seemless change there). I also reused much of the code that serves the callback endpoint so that we get to update the user identity/groups every time we successfully refresh.

Related Issues/Pull Requests

N/A

Contributor Checklist

Docs have not been added yet since I want to get a review of this change done first. Please direct me to where I can include appropriate CI tests.

[DrDaveD]

Interesting. I see the AccessToken getting saved, but is it being used for anything?

For a more full-featured solution check out #119 in combination with https://github.com/puppetlabs/vault-plugin-secrets-oauthapp for storing refresh tokens as a secret. With that secrets plugin then you can obtain access tokens, do token exchanges, and other interesting things using the vault token created by this auth plugin.

[kcolford]

@DrDaveD I'm not actually using the access token for anything beyond getting a fresh id token to keep things link group metadata intact. The only reason I even save it is just in case it has expired before the next vault token renew; the whole purpose of this is to make sure that once someone is removed from the identity provider, their access is also removed quickly and without hassle

I'm sure our two PRs can be made to work together pretty easily though