As a holdover from the original hashi_vault lookup, token auth does a lookup-self on the given token as a way to try to determine if the token is valid.
Later an option token_validate was added to control this (so that it could be turned off), because in some cases, tokens don't have permission to perform that operation.
But its default was set to true to match previous behavior.
However, this lookup is a largely unnecessary extra round-trip for everything that uses token auth, that's on by default.
The only real advantage of doing this lookup is that we can provide a more specific error message if this fails. Without this lookup, the token will attempt to be used for whatever operation is being performed, and if it's not valid, the failure returned will depend on the operation somewhat, and so it may look like a different error (permission denied for example).
The disadvantages of doing this "validation" are:
It's not actually validating the validity of the token
It does not determine whether the token has the permission needed to perform the operation it needs to perform
It could prevent unauthenticated endpoints from working if an old inferred token is read (from the sink file for example), unless none auth is explicitly chosen (arguably, you should be choosing none if you are hitting an unauthenticated endpoint)
It's an extra round-trip
The only other area where this matters is in the vault_login lookup/module. Using token auth in vault_login returns the token itself (there is no login operation to perform), but it has to use lookup-self to get any additional information about the token, otherwise it will only return the token value (in the familiar structure).
So I have two options for vault_login:
Let the default change (keep inheriting from the global definition)
Change the default globally, but override the default in vault_login to be true.
~I am leaning toward option 1; the other information returned is the information least likely to be used, the option can be set explicitly, and there will be sufficient announcement of the change.~
After some testing, I will go with option 2. The issue is larger than just "extra" information, it's that with vault_login there is no "actual" operation to perform with a "token" login that will fail. So if you call vault_login with "token" auth and a bad/expired token, it will just return that (it will "succeed"). So I think validation defaulting to true for vault_login only makes sense.
SUMMARY
As a holdover from the original
hashi_vaultlookup, token auth does alookup-selfon the given token as a way to try to determine if the token is valid.Later an option
token_validatewas added to control this (so that it could be turned off), because in some cases, tokens don't have permission to perform that operation.But its default was set to
trueto match previous behavior.However, this lookup is a largely unnecessary extra round-trip for everything that uses token auth, that's on by default.
The only real advantage of doing this lookup is that we can provide a more specific error message if this fails. Without this lookup, the token will attempt to be used for whatever operation is being performed, and if it's not valid, the failure returned will depend on the operation somewhat, and so it may look like a different error (permission denied for example).
The disadvantages of doing this "validation" are:
noneauth is explicitly chosen (arguably, you should be choosingnoneif you are hitting an unauthenticated endpoint)The only other area where this matters is in the
vault_loginlookup/module. Usingtokenauth invault_loginreturns the token itself (there is no login operation to perform), but it has to uselookup-selfto get any additional information about the token, otherwise it will only return the token value (in the familiar structure).So I have two options for
vault_login:vault_loginto betrue.~I am leaning toward option 1; the other information returned is the information least likely to be used, the option can be set explicitly, and there will be sufficient announcement of the change.~
After some testing, I will go with option 2. The issue is larger than just "extra" information, it's that with
vault_loginthere is no "actual" operation to perform with a "token" login that will fail. So if you callvault_loginwith "token" auth and a bad/expired token, it will just return that (it will "succeed"). So I think validation defaulting to true forvault_loginonly makes sense.ISSUE TYPE