JWT: A Fundamental and Technological Deep Dive

Yo, JWTs are fun!
As cybersecurity champions, we often fail to understand how a technology works at the core, but rush to understand how the technology is applied instead. Lets take it a step back and MASTER the idea of JWT!
Video Timeline:
5:33 Structure of JWT
12:05 Making our own JWT
35:29 Testing how JWT provides Authorization
45:23 Common JWT Misconfiguration (Overview)
Join our discord community!
/ discord

[@ethicalpap]

Note: Base64 is actually limited to encoding only, and not an encryption algorithm. Whenever you hear me say "encryption" for base64, I mean "encoding" 😊

[@jpphoton]

I reasoned JWE opaque tokens are the way to go as well as setting audience claim in JWT creation is the X-FOR header that strongly binds the client origin .

[@DIYSEC]

Thanks for the break down, keep it up!

[@Okaypeyton1]

Dope vid fam. Saw this from ur post

[@cheffloppa1]

Very good 👏

[@learnngo-jr5xu]

Out of curiosity. What are your thought on authorization? In technologies like JavaScript Auth as a service is becoming the norm opposed to rolling your own. Where in other tech frameworks like rail and Laravel auth is part of the framework.

[@ethicalpap]

Funny you mention this, I touch on this in a video that I just finished recording. It should be out in a few days. My thoughts are this:
Delegating Authorization for APIs had been a thought for about 2 decades. Major tech firms were working on proprietary implementations, leading up to the OAuth 1.0 specification release in 2007.
Now, before I continue here - it is important to note that technology evolves for the purposes of providing convenience to people, whereas cybersecurity evolves for the purpose of ensuring that these convenient methods are secured (thus potentially making them less convenient). It's almost like a game of tug-a-war.
Now, rolling your own Auth can be a good thing, but can be unappealing for a business. Here's why:
good with own solution:
- customizable, flexible, full control of implementation and protocols.
bad with own solution:
- takes far more time to implement than an out-of-box solution, meaning the company would incur more upfront cost in development, as well as potentially more costs in maintenance, testing, patching, and scaling.
*there are far more pros and cons, but I only chose 1 for the sake of a shortened response
So, while a dev might be inclined to employ their own solution for full control, an organization might opt for a faster and cost effective solution. If this is the case, it is up to the cyber-team to work with the devs to ensure that the chosen solution is optimal, cost-effective, and also can be hardened to an acceptable level.