본 포스트는 아래 영상을 요약한 글로 원작자의 허락을 받고 올립니다. 저작권 문제시 본 글은 삭제조치하겠습니다
https://www.youtube.com/watch?v=1QiOXWEbqYQ&t=1s
로그인? 아이디랑 비번 DB에 갖고있다가 로그인할 때는 그게 DB에 있는지 조회하면 될 줄 알았지만 그건 너무 날먹이었고~ㅋㅋㅋ 보안문제땜에 당연히 그렇게 안 한다고 한다.
로그인 기능을 만들기도 쉽지 않지만, 더 까다로운 건 로그인 상태를 유지하는 것! 지메일에 로그인했는데 메일 열 때마다 뭐 할때마다 로그인할 수는 없다. 내가 로그인하면 로그인했다는 걸 서버가 계속 알고 있어야 한다. 인증(Authentication)과 인가(Authorization)의 차이가 중요한 것.
JWT는 인가 즉 Authorization에 관련된 기술로, 어떤 사이트나 서비스에 사용자가 로그인했다가 서버에 인지시키는 것과 관련된다.
인가란 분야에서 전통적으로 많이 사용된 건 세션(session)이다. 사용자가 로그인에 성공하면 서버는 세션표딱지를 출력하는데 이걸 쭉 찢어서 반쪽은 브라우저라 보내고 반쪽은 자기가 갖는다. 브라우저는 이를 session ID라는 이름의 쿠키로 저장한다! 브라우저는 그럼 로그인된 사이트에 요청을 보낼따마다 이 표딱지를 실어보내고, 서버는 요청에 표딱지반쪽이(즉 session ID가) 서버는 자신이 가진 표딱지들 중 브라우저로부터 받은 반쪽짜리와 맞는 표딱지가 있는지 보고 ‘인가’한다. 이렇게 session ID를 사용해 서버에 로그인되어있음이 지속되는 상태를 ‘세션’이라고 표현한다. 그러나 이는 서버쪽 메모리가 날아가거나(재부팅 등으로) 너무 많은 유저들이 로그인하면 여러 반쪽표딱지들을 갖고 있어서 메모리가 부족해지는 현상이 생기기도 한다. 또한 여러 서버를 운영할 경우 로드밸런싱 문제로 로그인은 A 서버에서 하고(반쪽표딱지가 A 서버 메모리에 저장됨) 인가는 B 서버에서 진행될 수도 있는데, B 서버에는 A 서버에서 로그인한 반쪽표딱지가 없으니 에러가 생기기도 한다..
그래서 이런 부담없이 고안된 인가 방식이 토큰 방식인 JWT다. JSON WEB TOKEN의 줄임말이다. 토큰방식은 로그인하면 토큰이랑 딱지를 주는데, 세션방식과는 달리 반으로 찢지 않고 그대로 준다. 이는 서버가 뭔가를 기억하지 않는다는 얘기다! 토큰은 알파벳과 숫자들이 마구잡이로 섞인 문자열로 인코딩 또는 암호화된 3가지 데이터를 이어붙인 거다. XXXXXX.YYYYYY.ZZZZZZ같은 형태이며 마침표를 기준으로 세 가지 부분(헤더, 페이로드, 서명)으로 구분한다.
Payload
디코딩하면 JSON형식으로 여러 정보들이 들어있다. 토큰을 누가 누구에게 발급했는지, 언제까지 유효한지 등..토큰에 담긴 사용자 정보 등의 데이터를 Claim이라고 한다. 이를 통해 로그인 이후 요청들마다 사용자로부터 서버로 이 Claim들이 전해지는데, 사용자가 발급받아 갖고 있는 토큰 자체에 이런 정보들이 들어있으면 서버는 요청마다 하나하나 DB에서 뒤질 필요가 없으니 더 편하다. 근데 디코딩이 매우 쉬워서 누군가 수정할 오류가 있다! 근데 조금이라도 바뀌면 금방 알아챌 수 있다. 어떻게 하는지는 다음에 계속 서술
Header
디코딩하면 type(언제나 JWT가 들어감)과 alg(알고리즘)정보가 나온다. 여기는 ‘3번 서명값’을 만드는데 사용될 알고리즘이 지정된다(ex : HS256)
즉, Header와 Payload 그리고 서버에 감춰둔 비밀 값 이라는 3가지 요소를 암호화 알고리즘에 넣고 돌리면 3번 서명값이 나오는 거다. 암호화 알고리즘은 한쪽 방향으로만 계산이 돼서 토큰을 탈취해서 염병을 해도 서버가 감춰둔 비밀 값을 알아낼 수 없다.
여기서 주목. 서버는 요청에 토큰 값이 실려오면 Header와 Payload를 서버가 감춘 비밀값과 함께 알고리즘을 돌려서 계산된 값이 3번 서명값과 같다면, 그리고 유효기간이 지나지 않았다면 인가처리를 해준다. 이것이 JWT다. 참고로 Payload가 조금이라도 바뀌면 알고리즘 돌려서 나오는 값이 완전히 달라져서 3번 서명값과 같아지지 않는다. 이를 통해 payload변조를 알아챌 수 있다.
이를 통해, 서버는 사용자들의 상태를 어디다가 기록해둘 필요 없이 자신의 비밀 값만 가지고 있다면 요청들 들어올 때마다 헤비한 작업을 할 필요가 없다. 이처럼 시간에 따라 바뀌는 어떠한 상태값을 갖지 않는 걸 stateless하다고 표현한다. 세션은 반대로 stateful하다고 표현할 수 있다
그러나 JWT의 결점
stateful방식 즉 모든 사용자들의 상태를 기억하는 건 구현이 어렵고 고려사항도 많지만 구현만 되면 기억하는 대상의 상태들을 언제든 제어가능하다. 예를 들어 한 기기에서만 로그인가능한 서비스를 만든다고 하자. PC에서 로그인한 상태의 어떤 유저가 핸드폰으로 또 로그인하려하면 PC에서는 로그아웃되도록 만들 수도 있다는 얘기! JWT는 이런게 불가능하다. 이미 줘버린 토큰을 뺏을 수도 없고 토큰의 발급 내역(payload에 저장되는 정보)를 서버가 따로 추적할 수도 없으니..
즉 JWT는 내가 쥐고 있을 필요가 없어 편하긴 한데 그만큼 통제를 못 하는 방식이다.
또한 토큰이 만약 탈취된다면, 이 토큰을 무효화할 방법이 없다는 것도 큰 단점이다ㅋㅋ. 때문에 토큰을 두 개 발급하는 방법이 쓰이곤 한다. 완벽한 해결책은 아님. 이런 문제들이 큰 이슈가 안되는 서비스들에 한해서만 JWT만을 쓰는 인가방식을 쓰는 게 좋다.
'WEB > 그 외 필요한 지식' 카테고리의 다른 글
| [짧] 단방향 암호화 vs 양방향 암호화 (0) | 2023.01.24 |
|---|---|
| 세션 인증 방식 vs 토큰 인증 방식 (2) | 2023.01.24 |
| HTTP 상태 코드 (0) | 2022.07.12 |
| HTTP의 특징(stateless 등..) (0) | 2022.07.06 |
| DNS(Domain Name Service)에 대한 짧은 지식 (2) | 2022.01.09 |
