# Use Unauthenticated Paths With Vault

fleeting

use unauthenticated paths with vault

In the construction of the backend, one must provide the PathsSpecial to indicate the paths that are unauthenticated.

b.Backend = &framework.Backend{
Help:        strings.TrimSpace(backendHelp),
BackendType: logical.TypeLogical,
Paths: framework.PathAppend(
*framework.Path{
{
Pattern: "some/UNAUTHENTicated/path",
Fields:  map[string]*framework.FieldSchema{},
Operations: map[logical.Operation]framework.OperationHandler{
...
},
ExistenceCheck: b.handleExistenceCheck,
},
{
Pattern: "some/AUTHenticated/path",
Fields:  map[string]*framework.FieldSchema{},
Operations: map[logical.Operation]framework.OperationHandler{
...
},
ExistenceCheck: b.handleExistenceCheck,
},
},
),
PathsSpecial: &logical.Paths{
Unauthenticated: []string{
"some/UNAUTHENTicated/path",
},
}
}


Those are then parsed and put in the loginpaths during the mount of a plugin.

Indeed, it appears that login paths where dealt with as unauthenticated and then the unauthenticated notion was made more general, will still leaving behind several variables called login (in vault unauthenticated == login).

Then, during communication with a backend, this information is used to decide whether to call handleLoginRequest or HandleRequest.

In the former case, checkToken is called with unauth=true, in the latter case, it is called with unauth=false.

Then, in the code of checkToken, as the name does not suggest, not only does it check the token previously gathered using requestAuth, but it also removes it from the headers.

This is done unconditionally. That means that even in case of unauthenticated paths, the authorization header is removed, making it unusable in the plugin in case the plugin wanted to make its own authentication.