Is it safe to put a jwt into the url as a query parameter of a GET request?

Question

Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?

Gambrill

Answer 1

It can be safe under the following circumstances:

1. the JWT is one-time time usage only
2. the jti and exp claims are present in the token
3. the receiver properly implements replay protection using jti and exp

but in case it is used as a token that can repeatedly be used e.g. against an API then supplying it as a query parameter is less preferred since it may end up in logs and system process information, available to others that have access to the server or client system. In that case would be better to present it as part of a header or a POST parameter.

Besides that, by using it in the query parameters you may run in to URL size limitations on browsers or servers; using it in a header provides some more space, using it as a POST parameter would work best.

Baalbek

Also, un-trained users may copy and paste a URL with the token, which could lead to basically unintended session-hijacking. – Shue

If the endpoint is REST there are many cases you have to use GET method. Besides, if the request is to download, you cannot even use ajax. – Duralumin

What about a reasonably short exp < 2 min. plus a second redirect (after the jwt has been collected by the app)? The second redirect to simply prevent copy-and-paste problems. If your browser is compromised, even a header won't save you from you token from being stolen. – Globulin

Why must the token be 1 time only? – Wyman

Because being a query parameter the token may end up in server log, browser logs or referer headers and someone could grab it from there and try to re-use it. – Baalbek

but headers can also be sniffed and then use the JWT ? so what is the difference from security perspective? – Chou

@Chou Any token that is sent to the client-side is at risk. When you put a token as part of the URL the risk is greater because many non-malicious systems log URLs by default (servers, browser history, ISPs, cheap VPNs), which increases the attack surface of your system: a malicious agent doesn't have to compromise the client, but can instead compromise any of those systems. – Yusuk

@RamonSnir won't https encrypt urls? will they be logged as well? – Sanative

@Sanative HTTPS encrypts in transit, but both the client's computer and the server will likely log URLs. Browser history, Chrome/Firefox extensions, server access logs, performance monitoring tools, etc. all might log URLs for good reasons and so might log in-URL tokens inadvertantly. – Yusuk

Oh that makes sense. But apart from server and client, will there be any intermediate apps that log this? Like ISP or some other vpn provider etc? – Sanative

I read a lot about the query parameter being logged. You could also pass it with an anchor tag to web-based urls. Those won't get logged. – Chandelier

Just treat any URL as-if it is already leaked. URLs are designed as an identifier to be passed around, so it is more or less a public property. URLs passed to a browser will likely passed along to the browsers vendor to collect usage information for example. Just expect it to happen and for all parts of it. – Susiesuslik

Answer 2

Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?

Yes, insofar that a JSON Web Token (JWT) is encoded in a way that it is transparent with the encoding of a query parameter in an URL:

A JWT is URL-encoding-safe. There will be no data-loss when used in-place; no additional encoding is required; it is even URL encoding safe inherently, applying url-encoding (percentage-encoding) on the JWT multiple times will not destroy it.

This safety is limited:

There can be a data-leak when used in-place if the URL itself is part of such a data-leak. By how URLs are commonly in use, you should treat any JWT in an URL query parameter as-if the data-leak already happened and therefore prepared the JWT for it already (e.g. prevent replay attacks).

And it will be at best as safe as the transport of the URL information is, and never more safe.

And if the transport of the URL information is not safe, everything in the URL can never be more safe either, which includes the JWT when used as a GET parameter.

---

Apart from using it in an URL (which looks to me as a mechanism of transport), you may want to consider additional data-retention, protocol and even your own systems properties, including those of the JWT in question itself.

For all these it depends.

For some of those considerations, please see the other answer and JSON Web Token (JWT) - RFC-7519 incl. the referenced updates there.

Susiesuslik