JWT를 검증하려면 서명을 확인할 공개 키가 필요한데요. 그런데 그 공개 키, 도대체 어떤 형식으로 표현하고 어떻게 주고받을까요? 전통적으로는 X.509 인증서나 PEM 같은 형식을 썼지만, JSON 기반인 JOSE 생태계에는 키를 위한 전용 형식이 따로 있습니다. 바로 **JWK(JSON Web Key)**입니다. 키 하나를 JWK로 표현하고, 여러 JWK를 묶으면 **JWKS(JWK Set)**가 되는데요. OAuth/OIDC에서 인가 서버가 공개 키를 배포할 때 쓰는 그 꾸러미가 바로 JWKS입니다. 이 글에서는 JWK가 무엇
JWS로 이해하는 JSON 데이터 서명에서 서명이 토큰의 위변조를 막아준다는 걸 봤는데요. 한 가지 짚고 넘어간 점이 있습니다. 서명은 내용을 숨겨주지 않는다는 것이죠. JWS나 JWT의 페이로드는 그냥 Base64로 인코딩됐을 뿐이라 누구나 디코딩해서 들여다볼 수 있습니다. 그렇다면 토큰 내용 자체를 진짜로 가려야 할 때는 어떻게 할까요? 이때 등장하는 것이 **JWE(JSON Web Encryption)**입니다. 이번 글에서는 JWE가 JWS와 무엇이 다른지, 독특한 5조각 구조와 2단계 암호화 방식이 무엇인지를 직접 암호화/
JWT나 JWS로 토큰에 서명하려고 보면 alg 자리에 뭘 넣어야 할지부터 막히는데요. HS256, RS256, ES256, EdDSA... 이름은 비슷비슷한데 막상 고르려니 뭐가 다른지 감이 안 옵니다. 🤔 이 알고리즘들은 모두 JWA(JSON Web Algorithms, RFC 7518)가 정의한 서명 알고리즘인데요. 그냥 아무거나 골라도 토큰은 만들어지지만, 대칭이냐 비대칭이냐, 토큰이 얼마나 커지느냐, 검증 부하가 어디에 실리느냐에 따라 분명한 트레이드오프가 있습니다. 이번 글에서는 자주 쓰이는 네 가지를 비교하고 상황별로
JWT를 한 번이라도 디코딩해 본 적이 있다면 header.payload.signature처럼 점으로 나뉜 세 조각을 기억하실 텐데요. 앞의 두 조각은 그냥 Base64로 인코딩된 JSON이라 누구나 열어볼 수 있지만, 마지막 서명(signature) 조각이 있어서 토큰의 위변조를 잡아낼 수 있습니다. 그런데 이 서명, 사실 JWT만의 것이 아닙니다. **JWS(JSON Web Signature)**라는 별도의 표준이 있고, JWT는 그 위에 얹힌 한 가지 응용일 뿐인데요. 이번 글에서는 JWS가 정확히 무엇이고 어떻게 데이터에 서
JWT는 익숙한데 JWS, JWE, JWK, JWA까지 줄줄이 나오면 갑자기 머리가 복잡해지는데요. 이름도 비슷하고 죄다 eyJ로 시작하는 긴 문자열을 다루는 것 같은데, 도대체 뭐가 뭔지 경계가 흐릿합니다. 🤔 사실 이 다섯은 JOSE라는 한 가족입니다. 서로 다른 일을 맡은 형제들이 모여 "JSON으로 데이터를 안전하게 주고받는다"는 하나의 목표를 이루는 구조죠. 이 글은 JOSE 가족의 큰 그림을 그리고, 각 멤버가 무슨 역할을 하며 어떻게 맞물리는지, 그리고 더 깊이 알고 싶을 때 어느 글로 가면 되는지를 안내하는 지도 역