The video from Okta says that it's possible to hijack the access token when on public wifi. But if HTTPS is used, the headers are encrypted. And therefore the Location returned by the Auth Server won't be visible to the attacker.

Replay attacks won't help the attackers either - again because the headers are encrypted.

So are there actually any ways that MITM or anyone else can intercept the token in the URL? It seems like this flow is more secure than people say..

1 Answer 1


Referring to the original question - which was specifically asking about HTTP/2: The headers (and also the body) are encrypted already if HTTPS is used with HTTP/1, i.e. this is not specific to HTTP/2. And HTTP/2 does not add another encryption layer specifically for the header to this. You might have confused this with header compression.

So if the client trusts an insecure connection (i.e. a TLS man in the middle) then the attacker can inspect and even modify all transferred data including the header. This means it is game over no matter if HTTP/1, HTTP/2 or HTTP/3 is used.

  • Ahh. Right, confused it with the compression.. But my main confusion is still about the untrusted wifi networks. Why in the video the Okta guy says it was possible to hijack the access token from the URL? I don't think he meant trusting the insecure connection. Commented Oct 1, 2023 at 17:29
  • @StanislavBashkyrtsev: The part of the video is about captive portals which are essentially man in the middle. In this case interception is possible only if the traffic is either plain HTTP (i.e. no protection) or the protection of the browser is ignored (i.e. accept insecure connection by the user). Commented Oct 1, 2023 at 17:34
  • Aaah, got it. That's what I missed - didn't know the term "captive portal". Thanks! PS: I replaced HTTP2 with HTTPS in my post. Commented Oct 2, 2023 at 6:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .