I have a backlist of tokens (JWT) stored in Redis and would like to enable users of my website to blacklist their tokens in a RESTful way.
I can either:
- Build the route
/sessions/<token> with a DELETE method
- Build the route
/sessions/ with a DELETE method and the token sent in the request body.
The first solution is simple but the token is stored in the server's logs and in the user's browser's history.
The second solution seems better but I'm not sure I'm not breaking HTTP RFC's idempotency principle by sending a DELETE request with a body.
What's the best practice in this case?
Is JWT in URI a bad practice?
JWT tokens are URL-safe when it comes to the syntax. From the RFC 7519:
A JWT is represented as a sequence of URL-safe parts separated by period (.) characters. Each part contains a base64url-encoded value. [...]
However, when using JWT as bearer tokens, it's advisable to avoid sending them in the URL. See the following quote from the RFC 6750:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be
passed in page URLs (for example, as query string parameters).
Instead, bearer tokens SHOULD be passed in HTTP message headers or
message bodies for which confidentiality measures are taken.
Browsers, web servers, and other software may not adequately secure
URLs in the browser history, web server logs, and other data
structures. If bearer tokens are passed in page URLs, attackers might
be able to steal them from the history data, logs, or other unsecured
locations.
For the situation mentioned in your question, you may not need to send the full token. You could give the token a unique identifier (stored in the jti claim) and then send only the token identifier to the server.
See how the jti claim is defined in the above mentioned RFC:
4.1.7. "jti" (JWT ID) Claim
The jti (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well. The jti claim can be used
to prevent the JWT from being replayed. The jti value is a case-
sensitive string. Use of this claim is OPTIONAL.
A UUID should be unique enough to identify your tokens without collisions.
You don't need to store the full token in the blacklist either: store only the value of the jti claim and some other claims that you may find relevant (such as sub and exp, for example).
DELETE requests shouldn't contain a body. So you could use DELETE /sessions/{id}, where {id} is the unique identifier of your token.
