JWT (4)

Http : 서로 다른 내부망끼리 통신하기 위한 약속된 규칙(protocol)이며, 이 규칙을 담은 문서가 RFC 문서이다. 이 내부망들이 모인 것이 www, 즉 인터넷이다.

jwt는 RFC 7519라는 문서에 정의가 되어있다.

jwt란 정보를 JSON 객체로 안전하게 전송하기 위한 방식이다. 이 정보는 디지털 서명이 되어있으므로 신뢰 가능하다. jwt는 암호화 기능이 있지만, 인증에 중점을 둔 토큰이다.

jwt는 다음과 같은 구조를 가진다.

• header
  • 알고리즘이나 타입같은 정보가 담기고 Base64Url로 인코딩 된다.
• payload(정보)
  • 등록된 클레임
    • 필수는 아니지만 권장되는, 미리 정의된 클레임
      • ex) 발행자(iss), 만료 시간(exp), 주제(sub), 청중(aud)
  • 개인 클레임
    • 당사자끼리의 정보를 공유하기 위해 생성된 클레임
      • ex) id
• signature
  • header와 payload, 개인 키를 hmac sha256 또는 rsa로 암호화 한다.
  • hmac sha256 : 시크릿 키를 포함한 해쉬 암호화 방식

세션의 구조와 비슷하게 jwt 구조를 설명하겠다.

1. 클라이언트에서 로그인을 하려고 웹 서버로 id, pw를 전송했다.
2. 서버는 세션이 아니라 jwt를 만든다.

HS256으로 암호화 할 시
3. header, payload, signature를 만든다.
4. header에는 HS256으로 서명을 하고, payload에는 useranme=id 가 담기고,
signature에는 header와 payload, 서버만 알고있는 secretkey를 더해서 HS256으로 암호화 한다.
5. header, payload, signature를 각각 Base64Url로 인코딩 한다.
6. 3가지를 클라이언트에게 response 한다.
7. 클라이언트가 다시 jwt를 서버에 주면서 개인정보를 request 한다.
8. 이때 jwt가 유효한지 검증이 필요한데, 서버 내부에서 jwt 안의 header, payload와 서버 자신이 갖고있는 secretkey를 더해서 HS256으로 암호화를 진행하여 jwt의 signature와 같은지 검사한다.
9. 인증이 되었으면 palyload에 담긴 username으로 db에서 조회하여 값을 찾아 개인정보를 다시 response한다.

RSA로 암호화 할 시
3. header, payload를 만든다.
4. header에는 RSA로 서명을 하고, payload에는 useranme=id 가 담긴다.
5. signagture에서 header와 Payload를 서버의 개인키로 암호화 한다.
6. 그 후 jwt를 클라이언트에 response 한다.
7. 클라이언트가 jwt로 서버에 다시 request 한다.
8. 서버는 공개키로 signature를 복호화한다.(서명 검증)

둘다 사용하지만 보통 HS256을 좀더 많이 사용한다.

이런 jwt를 사용하게되면 서버는 따로 세션 저장소가 필요 없이 secretkey 하나만 알고있으면 사용자 인증이 가능하게 된다. 또한 클라이언트가 로드밸런싱이나 기타 이유로 여러 서버를 왔다 갔다 해도 jwt 토큰만 검증하면 되니 상관이 없게 된다. 세션에서의 user정보 저장소를 jwt가 사용하는 것이다.