jwt 토큰 기초

1. web -> server 최초 요청

• web이 주소를 요청하면 server가 해당하는 html을 던짐
• 이때 header에 세션 id 담아서 던짐 (server에 세션 id를 모아둔 목록이 있다고 생각)
• web은 이 세션 id를 저장하고 있음

2. web -> server 두번째 요청

• web이 세션 id 들고 server로 요청
• server는 세션 id 목록 확인
• 이미 존재하면 있음을 확인, 없으면 새로 생성

session 사라질 때?

1. server에서 세션 값 지움
2. 사용자가 브라우저 종료 (web이 저장해둔 세션 id가 날라가고, 서버에 저장된 세션 id는 그대로 존재)
3. 특정 시간(보통 30분)이 지나면 server쪽에서 사라짐

session 단점

클라이언트가 너무 많으면 (동시접속자 수가 서버가 처리할 수 있는 수보다 많으면) 서버를 여러 대를 사용 -> 로드 밸런싱

ex) 서버가 100명 처리 가능 but 클라이언트 300명이 접속 -> 서버 3대 만들기 (A, B, C)

만약 한 클라이언트가 서버 A에 최초 요청해서 세션을 받음, 후에 두번째 요청에서 서버 A가 바빠서 서버 B로 가게 됨 -> 서버 B에서는 최초 요청으로 인식 -> 문제

---

세션 문제 해결 -> JWT 토큰

• RSA에 대해 알고 넘어가기 (JWT가 쓰는 암호화)
  public key : 공개키
  private key : 개인키

a가 b에게 문서를 보내는데(1234) b의 공개키로 감싸고 a의 개인키로 또 감싸면 된다.
이때 b는!

1. 문서를 받는다.
2. a의 공개키로 열어본다. (a의 개인키로 감싸진 부분이 열림)
3. 열리면 인증이 된 것이다. (a의 개인키로 감쌀 수 있는 사람은 a뿐이므로 a의 공개키가 작동했다는 것은 a가 직접 잠궈서 보낸 것이 맞다는 것 = 중간에 해커가 낚아채서 문서를 조작하지 않았다는 것(?))
4. b의 개인키로 열어본다. (b의 공개키로 감싸진 부분이 열림)
5. 1234 가 나온다. (암호화된 데이터 읽을 수 O)

즉, RSA 암호화 방식은 b의 공개키로 먼저 감싸고, a의 개인키로 한 번 더 감싸는 것
-> 인증 해결, 암호화 해결

JWT 토큰

정보를 JSON 객체로 안전하게 전송하기 위한 방식 (RFC 7519 문서에 만들어짐)

Header / Payload / Signature

Header

토큰 유형과 서명 알고리즘 두 부분으로 구성

{
	"alg": "HS256",
    "typ": "JWT"
}

JSON은 Base64Url로 인코딩 되어 JWT 첫 번째 부분을 형성
(Base64Url은 암호화 하고 나서 디코딩 가능)

Payload

클레임을 포함하는 페이로드는 JWT 두 번째 부분을 형성

• 등록된 클레임 : iss(발행자), exp(만료시간), sub(주제) 등 -> 넣지 않아도 되는 부분
• 공개 소유권 주장
• 개인 클레임 : 유저 아이디, primary key 같은 정보를 공유하기 위해 사용

{
	"sub": "123456789",
    "name": "yeonji",
    "admin": true
}

Signature

서명 부분은 인코딩 된 헤더(header) + 인코딩 된 페이로드(payload) + secret

HMACSHA256(
	base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret)

🎈 목적은 암호화가 아니라 전자서명이다.!!! (요청 보낸 사람이 본인이 맞다는 걸 증명)