RFC
http를 개발한 벨 연구소에서 제시한 문서로, 조직별로 구축된 내부망간의 연결을 잇기 위해 만들어진 규칙이다. RFC(Request for Comments)는 프로토콜의 집합체로, 인터넷을 구성하는 모든 망의 프로토콜이 문서화 되어있다. World Wide Web에 새로운 규칙을 통해 가입하기 위해선 구성원들 전체의 동의를 거쳐 RFC 문서화를 거쳐야 한다.
JWT
JWT(JSON Web Token)은 RFC7519번을 통해 추가된 개방형 표준이다. JSON객체를 이용하여 정보를 전송하고, RSA / ECDSA 방식의 암호화를 사용하여 디지털 서명을 진행할 수 있는 토큰이다.
JWT의 구조는 다음과 같이 이루어져있다.
xxxx.yyyy.zzzz
JSON
복사
첫번째로 구분된 부분은 헤더(Header)로, 사용한 암호화 알고리즘의 종류와 JWT타입의 객체임을 명시해두고 있다.
이는 Base64Url로 복호화가 가능한 문자열로 인코딩되어 토큰의 첫번째 부분을 형성한다.
두번째로 구분된 부분은 유효탑재량(Payload)으로, 공개 클레임과 개인 클레임을 가진다.
공개 클레임엔 토큰의 발행자, 유효기간, 주제, 청중 등 선택적인 정보들을 넣을 수 있으며 필수는 아니다.
개인 클레임은 당사자간 교환해야 할 정보를 담는다.
주의해야 할 점은, Base64Url은 쉽게 복호화가 가능하니 개인 클레임에 민감한 정보를 담으면 안된다는 것이다.
이 또한 Base64Url로 복호화가 가능한 문자열로 인코딩되어 토큰의 두번째 부분을 형성한다.
세번째로 구분된 부분은 서명(Signature)으로, 인코딩된 헤더와 인코딩된 유효탐재량을 합친 문자열을 가진다.
토큰을 전송하기 전, 헤더에 명시된 알고리즘으로 발신인의 개인키를 이용하여 암호화하여 토큰의 세번째 부분을 형성한다.
Base64UrlEncode({"alg":"RSASHA256","type":"JWT"})+"."+
Base64UrlEncode({"sub": "1234567890","name": "John Doe","admin": true})+"."+
RSASHA256Encode(Base64UrlEncode({"alg":"RSASHA256","type":"JWT"})+"."+Base64UrlEncode({"sub": "1234567890","name": "John Doe","admin": true}))
JSON
복사
수신자가 Base64Url로 인코딩 한 헤더와 유효탑재량을 SHA256 방식으로 해싱하고
서명을 HMAC 방식으로 공개키를 이용해 복호화 하면
두개의 해싱된 값을 비교해 정보의 무결성과 발신인을 확인할 수 있다.
웹서버가 토큰을 발행하여 공개키와 함께 클라이언트에게 건네주면, 클라이언트는 공개키로 웹서버의 토큰의 서명을 확인하여 로컬 저장소에 보관한다.
클라이언트가 request 헤더의 쿠키에 토큰을 담아 권한이 필요한 정보를 요청한다면, 서버는 JWT 서명을 체크한 후 Base64Url로 암호화 된 헤더와 유효탑재량을 복호화 하여 토큰에 명시된 사용자 정보를 확인한다.
로그인 기록이 메모리에 남아있지 않기 때문에, 토큰 기반의 인증 메커니즘을 제공한다. 클라이언트가 서버에 저장되어있는 개인정보를 요청한다면 복호화된 토큰에 명시된 사용자의 정보를 이용해 DB에 접근할 수 있다.
클라이언트에게 토큰을 생성하여 건네줌으로써 신원을 증명하는 JWT는 앞서 세션이 가졌던 로드 밸런싱의 문제 또한 사라진다.
