Redirect after reauthentication

[ChristofferL181]

Describe the bug
In the web ui, when you try to view a secret (foo/bar) with an expired token, you are asked to reauthenticate (Error - Your token expired...). When authenticated you are redirected to the root path instead of to foo/bar. When you don't have a token previously and authenticate you are redirected to foo/bar. The behavior is confirmed with LDAP and token as authentication method.

To Reproduce
Steps to reproduce the behavior:

1. Set a low token expiration time (or wait the time that the expiration time is set to)
2. Authenticate in the web ui and view foo/bar
3. Let the token expire
4. Authenticate using "reauthenticate" on the token expired page

Expected behavior
Redirect/stay on foo/bar after reauthentication

Environment:

• Vault Server Version (retrieve with vault status): 1.6.0
• Vault CLI Version (retrieve with vault version): 1.6.0
• Server Operating System/Architecture: CentOS 8

Vault server configuration file(s):

path "foo/metadata/*"
{
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "foo/data/*"
{
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "foo/metadata/"
{
  capabilities = ["list"]
}

# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
    capabilities = ["read"]
}

# Allow a token to renew a lease via lease_id in the request body; old path for
# old clients, new path for newer
path "sys/renew" {
    capabilities = ["update"]
}
path "sys/leases/renew" {
    capabilities = ["update"]
}

# Allow looking up lease properties. This requires knowing the lease ID ahead
# of time and does not divulge any sensitive information.
path "sys/leases/lookup" {
    capabilities = ["update"]
}

# Allow a token to manage its own cubbyhole
path "cubbyhole/*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

# Allow a token to wrap arbitrary values in a response-wrapping token
path "sys/wrapping/wrap" {
    capabilities = ["update"]
}

# Allow a token to look up the creation time and TTL of a given
# response-wrapping token
path "sys/wrapping/lookup" {
    capabilities = ["update"]
}

# Allow a token to unwrap a response-wrapping token. This is a convenience to
# avoid client token swapping since this is also part of the response wrapping
# policy.
path "sys/wrapping/unwrap" {
    capabilities = ["update"]
}

# Allow general purpose tools
path "sys/tools/hash" {
    capabilities = ["update"]
}
path "sys/tools/hash/*" {
    capabilities = ["update"]
}

# Allow checking the status of a Control Group request if the user has the
# accessor
path "sys/control-group/request" {
    capabilities = ["update"]
}

Additional context

[glavoie]

We are also seeing this problem with a low token expiration.

• If a user starts with a fresh session, he gets forwarded properly to the target URL after OIDC SSO login.
• But if an expired token is present, the Reauthenticate button that shows up will lose the context of the initial call and the user will get forwarded to the root path after OIDC SSO login.