JWT · JSON Web Token
JSON Web Token / JavaScript Object Notation
What is JWT?
- A signed 'digital pass'
- Verifies without a server check each time
- Well suited to authentication in distributed services
What changes with JWT is what the server remembers. With sessions, the server or Redis stores who is logged in and looks it up on every request. JWT puts that memory in the token and leaves it with the user. As a result, no matter how many servers you add, there is no session to share, and the outcome is the same wherever the load balancer routes a request. The trade-off: once a token is issued, the server has no way to revoke it.
A token is a string of three parts, header, payload, and signature, joined by dots. The first two parts are only Base64URL-encoded, so anyone can open and read them. The last part, the signature, is the only thing that prevents forgery. Signatures come in two kinds: HS256, which uses the same secret key to issue and verify, and RS256, where the authentication server signs with a private key and each service only verifies with the public key. The more places verification is spread across, the more RS256 fits, and the moment you copy a secret key to several teams, anyone on those teams can mint tokens.
Token lifetime needs designing too. In practice, a common setup is a short access token of 15 to 30 minutes, quietly renewed with a refresh token that lasts about two weeks. The shorter the lifetime, the less time a stolen token is useful, but the more re-issue traffic you generate, so expiry time is a trade-off between security and load. It is easy to confuse with OAuth 2.0, but OAuth is the procedure for delegating permissions, while JWT is just the format of the token passed around in that procedure. The two are not substitutes.
Incidents usually start from the belief that 'it's signed, so the contents are safe too.' The payload is encoded, not encrypted, so the moment you paste it into jwt.io, the employee ID, salary grade, and internal email are all visible. What trips teams up even more often is that logout and permission revocation don't take effect immediately. Even after you deactivate a departed employee's account, tokens already issued stay valid until they expire, so a company with an 8-hour expiry leaves internal documents open for those 8 hours. That is why you need a double safeguard: have the server check account status once more for sensitive APIs such as payments and HR, or keep a blocklist.
Ilyoung JungExpert in smart factories, equipment management, and the Fourth Industrial Revolution
Jaryong KooMarketing Ph.D. and leading authority on AI, data analytics, and personal brandingA token format defined by a web standard (RFC 7519). It became the authentication standard as APIs, single-page apps, and microservices spread.
Consider a hypothetical case: Company A, an online food distributor with 210 employees and annual revenue in the KRW 90 billion (≈ US$67,335,000) range. Its web store, mobile app, and partner admin each kept their own login, and during a Lunar New Year promotion the session server went down twice, causing a 30-minute login outage across all channels. That triggered a three-month project to unify authentication.
- When Lee, the platform team lead, pulled peak-hour authentication lookups, they came to 1,400 per second, and 92% of them only asked, 'Is this person really logged in?'
- Ms. Kim, the security lead, objected to a draft that put employee ID, email, and permission codes in the token: "Paste it into jwt.io and it all shows up as plain text." Only the identifier and the expiry time stayed.
- They split the roles: only the authentication server signs with a private key, while the three channels only verify with a public key. The secret key never reached the partner admin, which outside contractors use.
- They set access tokens to expire after 20 minutes and refresh tokens after 14 days. For 4 APIs, including payments and personal-data changes, they made an exception: the server checks account status once more after validating the token.
- Three months later, authentication DB lookups fell to 110 per second and there were no login outages during promotions. Canceling the 2 servers that had been planned for expansion saved KRW 36 million (≈ US$26,900) a year, and revoking a departed employee's access dropped from 8 hours to 20 minutes.