As we all know, JSON Web Tokens are a way of sending information between parties in a way where the sender's authenticity can be verified. It is essentially a JSON object with a signature. Using this signature, services that issue these tokens can verify that they are the ones who issued this token and thus can trust the claims which are contained within.
\nThe trustworthiness of these tokens make them popular for use in authorization and authentication scenarios:
\nFor this post, we'll be focusing on the former use case. So having a token with trustworthy claims is great; we can take the token at its word, and trust all of the information that it has contained within as gospel. Our server is unburdened from having to potentially make database calls to verify the user's role, their permissions, their existence, or even if they're logged in. Once the server has generated the token, as far as it is concerned, no state has to be maintained regarding the validity of the token. It will expire once its expiration time included in its claim has passed.
\nBut before we go ahead and use this for all of our authorization needs, we have to remember that while JSON Web Tokens themselves are stateless, to have a robust, feasible, and controllable authorization workflow, we'll have to maintain some state one way or another.
\nYou can think of an authorization token as an elementary school hall pass. The teacher (resource server) knows that it is a legitimate hall pass because it is green, 6 cm x 12 cm and has a signature from another member of the faculty. Now imagine that you've issued a hall pass, but now you need to take it back (you've changed your mind, or the kid did something bad). Your options are:
\nOther than the 3rd option which may or may not be feasible depending on your use case (most likely not), we can see that it is not possible to reliably remove or revoke a token without maintaining state. The solutions that I've looked upon Stack Overflow for invalidating these tokens boil down to relying on some form of state, one way or another. Don't get me wrong however, this is not a bad thing in my opinion. Using JSON Web Tokens can and do allow us to minimize the state that we do have to maintain, with minimal added complexity.
\nSo let's look at some ways that we can couple state and JSON Web Tokens that allow us to invalidate these tokens effectively.
\nWe can maintain a database table containing all of the tokens issued by our server that we would like to accept as valid. This would be a 1:1 session store, with every transaction occurring requiring this table to be checked to prevent an invalidated token from being accepted. While we would not be able to reduce the amount of state being maintained on our server, JSON Web Tokens still provide us with the utility of its trusted claims (and the performance benefits of not needing to check those).
\nWe can maintain a database table containing all of the tokens issued by our server that we do NOT want to accept as valid. Every transaction that occurs will require this table to be checked, to prevent an invalidated token from being accepted. Each record would only have to be maintained until the token itself expires. I can't think of any use case where a table of invalidated tokens would regularly be larger than a table of active tokens, so I'd imagine that the table maintained would almost always be smaller than maintaining a table of active tokens.
\nThis solution still needs a database lookup, but interestingly requires no state. For this, we can use the hash of a piece of data to sign the token itself. For example, by using the hash of a user's password, when the user changes their password, subsequent transactions involving an old token will fail, as the signature will fail to be verified. The effectiveness of this, however, would depend on your requirements, as this would be limited to invalidating tokens based on changing data (such as changing roles, passwords, etc.). It would not allow you to invalidate a token whenever you want.
\nI think that JSON Web Tokens coupled with a token blacklist is a fantastic way to manage authorization in web applications. This allows you to leverage the benefits of these tokens in reducing the network calls needed to secure your application, reduce the amount of data you need to store to manage sessions, and do so in a reliable way without introducing too much complexity.
\n","frontmatter":{"date":"January 18, 2021","updated_date":null,"title":"Invalidating JSON Web Tokens","tags":["JSON Web Tokens","JWT"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/0c11b157497c5b54f5a0149f01ce15ac/58556/unsplash.webp","srcSet":"/static/0c11b157497c5b54f5a0149f01ce15ac/61e93/unsplash.webp 200w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/1f5c5/unsplash.webp 400w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/58556/unsplash.webp 800w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/99238/unsplash.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt-signing-algorithms/"},"html":"When JSON Web Tokens are created, they are typically signed by its issuer. This allows the recipient of the token to validate that the token received contains all of the information encoded by the issuer unmodified and as intended.
\nA signature is not to be mistaken for encryption! The fact that a JSON token is signed does not mean that the data enclosed is unreadable by third parties. All a signature does is ensure that the message is authentic, which it achieves by allowing the recipient to compare the data they’ve received with a trusted claim included in the data (the signature).
\nJWTs are most commonly signed using one of two algorithms: HS256 (HMAC using SHA256), and RS256 (RSA using SHA256).
\nA signature can only be created by someone possessing a secret key, and the original payload. Signatures are generally formed by combining the data to be signed with a secret key, either by appending them together and hashing them (HS256), or by encrypting a representation of that data (a hash) using the secret key (RS256).
\nIn both signing algorithms, the data is formatted into an immutable representation in a way that a recipient can check that the creator of the signature was in possession of that particular secret key.
\nHS256 is a symmetric signing method. This means that the same secret key is used to both create and verify the signature.
\nThe issuer appends the JWT header and payload with the secret key, and hashes the result using SHA256, creating a signature. The recipient uses their copies of the secret key, JWT header and payload in the same way to reproduce the signature, checking to see if they match.
\nAside from some incredibly unlikely scenarios, the only way for these signatures to be consistent is if the JWT header, payload and secret shared between the two parties are identical.
\nRS256 is an asymmetric encryption method. This differs from a symmetric scheme in that rather than using a single secret key, a pair of seperate keys are used to encrypt and decrypt the data.
\nThe issuer generates a hash of the JWT header and payload using SHA256, and encrypts it using the RSA encryption algorithm, and their private key. The recipient uses their public key to decrypt the signature ciphertext, and then compares it to a hash they’ve reproduced using their copy of the JWT header and payload, checking for consistency.
\nThe only way that these resulting hashes are consistent is if the JWT header and payload shared between the two parties are identical, and the public key corresponds to the private key used to encrypt the hash.
\nBoth signing schemes are effectively secure, with HS256 being a little faster. However, given this use case, the difference in speed is not particularly relevant.
\nThe main consideration on which to use, is in my opinion the symmetric vs asymmetric property of each:
\nHaving an unsecured publicly available key is useful in many cases. For example, it can be published openly on the internet as part of a metadata endpoint, allowing JWT configurators to automatically retrieve the key, making for a straightforward and automatic JWT setup. As such, RS256 may be more suitable for situations where data is exchanged between two independent parties.
\nHaving a shared secret key can however also be useful in some cases. For example, if the issuer and recipient were both managed by a single party, the two applications would be able to share configurations without having to manage two separate keys. As such, HS256 may be more suitable for situations where data is exchanged within a single party
\n","frontmatter":{"date":"September 24, 2020","updated_date":null,"title":"JWT Signing Algorithms","tags":["JWT","JSON Web Tokens"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/2fd4c7f86c996d936d9b217235d6257d/58556/unsplash.webp","srcSet":"/static/2fd4c7f86c996d936d9b217235d6257d/61e93/unsplash.webp 200w,\n/static/2fd4c7f86c996d936d9b217235d6257d/1f5c5/unsplash.webp 400w,\n/static/2fd4c7f86c996d936d9b217235d6257d/58556/unsplash.webp 800w,\n/static/2fd4c7f86c996d936d9b217235d6257d/99238/unsplash.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}}]}},"pageContext":{"tag":"JSON Web Tokens"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}