TIL58. HTTP : JWT(JSON Web Token)

📌 이 포스팅에서는 HTTP의 인가 방식 중 하나인 JWT에 대해 정리하였습니다.

🌈 JWT(JSON Web Token)

🔥 인가(Authorization)는 왜 필요할까?

🔥 인가(Authorization)에는 어떤 방식을 이용할까?

🔥 Access_Token & Refresh_Token 이란?

1. 인가(Authorization)는 왜 필요할까?

🤔 인증(Authentication)과 인가(Authorization)

✔️ 사용자가 자신의 계정을 사용할 수 있게 로그인하는 것을 인증이라하고, 사용자가 자신의 메일함에 들어가고, 자신이 쓴 글을 삭제하는 것과 같이 인증 상태에서 어떠한 권한을 갖는 것이 인가의 개념이다.

✔️ 로그인이라는게 보안에 직결되면서도 사용자들이 불편하지 않도록 해야하기 때문에 서버 개발자는 인증과 인가를 어떻게 처리해야할지 고민을 가질 수 밖에 없다.

✔️ 대표적인 인가(Authorization) 방식은 Session이나 JWT으로 나뉜다.

2. 인가(Authorization)에는 어떤 방식을 이용할까?

🤔 Session이란?

✔️ 세션은 세션 ID를 사용해서 어떤 사용자가 서버의 로그인 되어있음이 지속되는 이 상태를 세션 방식이라 한다.

✔️ 세션은 사용자가 로그인을 햇을 때, 이를 인증할 수 있는 표를 반으로 잘라서 하나는 클라이언트에게 보내 웹브라우저가 쿠키 정보로 갖고, 하나는 서버가 갖고 있음으로써 이를 대조해보는 방식으로 인가를 구현한다.

✔️ 서버는 이 반쪽짜리 티켓을 메모리 또는 데이터베이스에 저장해 두는데 메모리에 저장하면 빠르지만 서버가 장애가 생겨 재부팅되야하는 상황이 생기면 서버에서 세션정보를 모두 잃어버릴 수 있다는 단점있다.

✔️ 서버의 다른 저장장치나 데이터베이스에 세션에 저장하는 것은 속도가 느릴 뿐 아니라 서버가 여러대 있는 경우에는 HTTP의 Stateless, Connectionless의 특징 때문에 구현하기 까다롭다.

✔️ 다른 방법으로는 레디스나 MemCached 같은 메모리형 공용 데이터베이스 서버를 둬서 이를 관리하기도 하지만, 이 또한 서버의 장애가 발생하면 세션 정보를 유지하기 어려운 단점을 갖고 있다.

✔️ 즉, 서버측의 복잡한 구성과 환경에서 어떤 상태를 기억해야는 어려움 때문에 이러한 부담을 낮추고자 고안된 것이 Token 방식인 JWT다.

🤔 JWT(JSON Web Token)

✔️ JWT 또한 사용자가 로그인을 하면 인가를 할 수 있는 어떤 표를 주는데 이번에는 반으로 찢지않고 그냥 준다. 이때 이 표를 Token이라하고, 반으로 찢지않는다는 것은 서버가 무언가를 기억하고 있지 않는다는 의미이다.

✔️ 이 토근은 인코딩 또는 암호된 3가지 데이터로 이뤄져있는데, 이 3개의 영역을 header, payload, signature라 하고 마침표 2개로 나눠져 있다.

✔️ 이 중 payload를 Base64 방식으로 디코딩해보면 누가 누가에게 발급했는지, 언제까지 유효한지, 사용자의 id번호, 관리자여부 등이 JSON형식으로 들어있다.

✔️ 이에 이런 token을 발급하면 서버가 요청마다 일일이 메모리나 데이터베이스를 뒤져봐야할 일을 줄어들지만, Base64로 인코딩 되어있기 때문에 이를 디코딩하여 악영할 수 있는 여지가 존재한다.

✔️ 때문에 header부분과 signature 부분이 함께 있다. header를 디코딩해보면 typ이 존재하는데 이는 고정값이고, alg는 signature를 만드는데 사용되는 여러 알고리즘 중 하나가 지정되어 있다.

✔️ 즉, payload 값과 서버에 감춰논 SECRET_KEY를 header의 alg 방식으로 생성한 것이 signature이다. 따라서 JWT의 암호화 방식은 클라이언트에서 서버로 보내져서는 복호화가 가능하지만, 클라이언트에서는 계산이 어렵다.

✔️ 이에 JWT는 서버에서 상태 유지하지 않기 때문에 Stateless의 특성을 가지고 있고, Sesstion은 반대로 Stateful한 특징을 갖고 있다.

3. Access_Token & Refresh_Token 이란?

🤔 JWT의 한계

✔️ JWT는 이러한 장점이 있지만, Session을 대체하기에는 JWT에도 한계가 존재한다.

✔️ Session은 부담이 존재하고 구현하기 어렵다는 단점이 있지만, Stateful하기 때문에 기억하는 대상의 상태들을 언제든 제어가 가능하다. 예를들어, 한 기기에만 로그인이 가능하게 만들고 싶을 경우에 사용자가 다른 디바이스로 접속하면 한 세션을 종료시킬 수 있다.

✔️ 이에 반해 JWT는 어딘가 기록하고 있지 않기 때문에 간편하긴하지만 통제하긴 어렵다. 예를 들어, 해커가 토큰을 탈취한 경우 이를 무효화할 수 있는 방법이 없다.

🤔 access_token & refresh_token 이란?

✔️ 이러한 JWT의 한계를 보완하기 위한 방법 중 하나는 사용자가 로그인 시, 2개의 토큰을 발급하는 것이다. 수명이 몇 시간이나 몇분 이하로 짧은 access_token과 보통 2주정도로 기간이 잡혀 있는 refresh_token이다.

✔️ 서버는 refresh_token과 상응하는 값을 저장해 두는데, 클라이언트에서 access_token의 만료기간이 지나 refresh_token을 전송하면 그걸 서버에 저장된 값과 대조하고 맞다면 새로운 access_token을 발급하는 것이다.

✔️ 이제 refresh_token만 안전하게 관리된다면 이게 유효할 동안은 access_token이 만료될 때마다 다시 로그인할 필요 없이 인가를 해주는 방식이다.

✔️ 즉, 매번 인가를 할 때 사용하는 access_token과 access_token의 유효기간이 지났을 때 재발급 받기 위한 refresh_token을 활용하는 것이다.

✔️ 또한 서버에서 누군가를 강제로 로그아웃 시킨다던지 토큰을 무효과시키고 싶다면 refresh_token을 DB에서 지워서 토큰 갱신이 안되게 제어할 수 있다. 다만, 이는 token의 한계점을 부분적으로 보완한것 뿐이지 완전한 해결책은 아니다.