Vouch 400 and Invalid session state when opening a previous tab or returning to a tab after the laptop and browser has gone to sleep

[zoriax]

Hello everyone,

Describe the problem

I'm facing an "old" issue with vouch-proxy in a path. I'm searching during a few days trough issues and it really looks like issues :

• https://github.com/vouch/vouch-proxy/issues/373
• https://github.com/vouch/vouch-proxy/issues/323

But after some test I'm definitively facing a vouch 400. To reproduce this, I'm using on my Edge browser for example : "Open tabs from the previous session", so my browser reopen previous tab.

If during this process, my token or my cookie or session expire (seems to be jwt expiration) and my user open its browser again, I'm facing vouch 400.

With vouch testing, I can 302 see that after opening browser :

But if I tried to login I have :

And If I tried to validate I have : no jwt found in request

Please fin here gist for logs and vouch config here : https://gist.github.com/zoriax/ca6528a51123593ff0725d48198f40b3

Expected behavior I think the login process should be respected according to the vouch config. /!\ one important point is if I try to reach my url for exemple www.test.com in a new tab, the whole vouch login process works as expected

Desktop (please complete the following information):

• OS: Windows 10 -11
• Browser : Chrome and Edge
• Version : Laset

Smartphone (please complete the following information):

• Not used for this test

Additional context I'm using vouch in a path on /authenticate. According to the logs it seems vouch is trying to reach /auth regarding of ``/authenticate/auth``` but I'm not totally sure of the whole process... I missed something somewhere but I can't find the culprit ;-( so your help could me warmly useful.

Many many thanks if a way to solve this can be found ! It will save my day.

[bnfinet]

@zoriax happy to help but please read the README and adjust your post accordingly. It makes it much easier when it's done as such. Cheers.

[zoriax]

Hello @bnfinet : Sorry for that ! I hope its now correctly formed ;-)

[bnfinet]

@zoriax the session (time to log in at IdP) is configured to timeout (maxAge) after one minute, the JWT will only be valid for 1 minute. Try removing those to use defaults (5 minutes session, 4 hours JWT).

If that doesn't change the behavior please offer your nginx config as well and offer logs that show two round trips with testing as described in the README.

[zoriax]

Hello,

MaxAge is set to 1 for testing purpose. The behavior is the same if I set for example maxAge to 4 hour for token. If I close my browser and wait for 4 hours and 2 minutes, then when I open it again and tab is restored, I see vouch 400 error page.

Please find here in gist : https://gist.github.com/zoriax/ca6528a51123593ff0725d48198f40b3

Nginx config and log for round trop (first when I started "from scratch", then when jwt as expire and browser open tab)

Many thanks

[bnfinet]

It appears that all requests are successfully being handled "in a path" including /auth and /auth/$STATE

The logs are showing the session cookie is not able to be retrieved https://gist.github.com/zoriax/ca6528a51123593ff0725d48198f40b3#file-logs-complete-round-testing-mode-L52

What version of VP is this?

It's difficult to follow what you've offered. That nginx config looks to be only partial, the VP config you've offered doesn't correspond to the config used to produce those logs. The logs seem to be incomplete / truncated.

Could you please start over fresh, take your time and produce a new round of logs and config that are complete and full and place those in a fresh gist.

I'd love to see something which confirmed a suspicion I have about how 302 redirect might be affecting a "revived tab" but I can't make that case with what you've offered.

[zoriax]

Hi @bnfinet,

Thanks for your feedback and your tome. The version of VP is actually the last one, v 0.39.0.

My NGINX config is fully complete now. I just changed some informations because of security reasons ;-)

For testing and log, what is strange is that I can't see /auth link on vouch testing page. I only have /authenticate/auth/<lot of stuff> I supposed /auth in your README is this one.

In the gist I putted the 2 rounds of log in testing mode. One set when my browser opens tab and one from "fresh" access.

I'm not sur of what I'm seeing but with vouch in a path why I can see in logs a query that reach /auth/{$state} when vouch should reach /authenticate/auth/ ?

I'm sorry if I missed something, I do my best ;-) ! if yes don't hesitate to tell what you are exactly looking for and maybe the exact process to extract the log.

Please kindly find all the stuff here again : https://gist.github.com/zoriax/ca6528a51123593ff0725d48198f40b3

Many thanks for your help !

[bnfinet]

@zoriax need the VP config

[zoriax]

@bnfinet sure, it's added to gist. The JWT MaAge is set to 1 for testing purpose. It I set it to 4 hours, then when I close my browser, wait for 4hours and 2 minutes, I encounter vouch 400 too. So it really seems to be related to somethin with token expiration

[zoriax]

Hello @bnfinet,

You founded something in logs / config ? I think i tried all the possible ways to configure vouch in a path with Nginx but I continue du have a vouch 400 after tab are restored. It could be very very very nice if we can find a solution for this problem.

I'm available to provide the logs / config you need to help you to understand this behavior.

By advance, many thanks for your return and your next help

[zoriax]

Hi @bnfinet

I've done a little change in vouch-proxy to act correctly with this strange behavior. I changed these lines (starting at line 65) in auth.do after a little test, when my browser tab is restored, it works better (but not on all browser)... So I'm approaching the goal

I've done a little change in auth.do

// is the nonce "state" valid?
queryState := r.URL.Query().Get("state")
if session.Values["state"] != queryState {
    target := "https://" + r.Host
    responses.Redirect302(w, r, target)
    return
}

Because I'm not an expert in go and vouch, I'm sure your you can check and give me (us) your feedback of this change :-) !

Thanks I hope having some news shortly !

Cheers

[nicornk]

We have also started to see this issue recently, I am still gathering some data on it.

[nicornk]

After some investigations we figured out that the issue only occurred when the users clicks the link to the app from an MS Teams chat.

Teams changes the link to https://statics.teams.cdn.office.net/evergreen-assets/safelinks/1/atp-safelinks.html?url=https%3A%2F%2F<url-of-the-app> and adds some "link checker" in front which apparently can not be disabled.

This in combination with SameSite: Strict Cookie Policy led to the issue that Chrome is not sending the VouchSession Cookie in the https://<app-url>/auth/53tYpfjVN5nxaQRtKaI50RHmq8jYAJq/?code=2b850561-7642-4501-85bd-e1bb5ccdd8c4&state=53tYpfjVN5nxaQRtKaI50RHmq8jYAJq redirect request.

Relaxing the SameSite policy to Lax did fix the issue.

[bnfinet]

@nicornk nice sleuthing!

[j6b72]

I had the exact same problem - in my case, setting the SameSite policy to Lax didn't help. I could solve it by explicitly forbidding the caching of the 302 redirects using headers. I wasn't using vouch in a path though, but rather on it's own subdomain.

In the server block of auth.:

        add_header Cache-Control "no-cache, no-store, must-revalidate" always;
        add_header Pragma no-cache always;

In the @error401-block inside the protected service's server block:

        add_header Cache-Control "no-cache, no-store, must-revalidate" always;
        add_header Pragma no-cache always;

It instantly solved this previously easily reproducible problem.