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 about vouch-proxy HOT 14 CLOSED

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.

from vouch-proxy.

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.

from vouch-proxy.

@nicornk nice sleuthing!

from vouch-proxy.

@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.

from vouch-proxy.

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

from vouch-proxy.

@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.

from vouch-proxy.

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

from vouch-proxy.

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.

from vouch-proxy.

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 !

from vouch-proxy.

@zoriax need the VP config

from vouch-proxy.

@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

from vouch-proxy.

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

from vouch-proxy.

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

from vouch-proxy.

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

from vouch-proxy.