[DRF] JWT로 로그인 구현하기(1) - What is a JWT?

웹 서버는 Stateless 프로토콜인 HTTP를 사용한다.

HTTP는 바로 직전의 한 통신도 기억하지 못한다. Stateless 하기 때문에.

따라서, 웹사이트에서는 이러한 인증을 관리하는 방안이 필요하다.

로그인 한 유저들에 대해 권한이 필요한 매 요청마다 재로그인을 시킬 수 없기 때문이다. 

따라서 이 문제를 해결하기 위해 사용되는 것은 세션(session)과 토큰(token)이다. 

 

1. 세션 기반 인증(session based authenticaton)

세션 기반 인증(session based authentication)에는 session과 cookie가 사용된다.

크롬 브라우저에서 '쿠키 및 사이트 데이터 삭제' 같은 기능을 써본 적이 있을 것이다.

여기서 cookie는 클라이언트가 웹 사이트에 접속할 때 브라우저에 저장되는 작은 텍스트 파일이다.

이 cookie는 접속자를 인식하거나 일부 데이터를 저장하는 역할을 한다. 

session이란 id나 password 같은 보안이 필요한 데이터를 다루어야 하는 상황에서 cookie를 보완하여 나왔다.

특정한 session에 인증 정보 자체를 저장하고 이 값을 cookie에 담아 클라이언트가 cookie를 요청할 때마다 session에 있는 정보랑 동일한지로 로그인을 확인하는 방법이다. 

 

작동 방식

1. 클라이언트에서 사용자의 인증 정보를 서버에 전달한다.

2. 서버는 인증을 처리 한 뒤 해당 user에 대한 session을 생성한다. 이 때 세션을 식별하기 위한 session id를 기준으로 정보를 저장한다.

3. 브라우저에 쿠키로 session id가 저장된다.

4. 브라우저는 해당 사이트에 대한 모든 Request 에 Session Id 를 쿠키에 담아 전송한다.
5.서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session 정보로 인증을 처리한다.

세션 기반 인증의 가장 큰 특징은 서버에서 데이터를 관리한다는 것이다.  

이는 데이터가 안전하다는 장점이 있지만 서버 메모리에 부담이 되고 매 요청마다 인증을 위해 session를 탐색해야 한다는 단점이 있다. 

 

2. 토큰 기반 인증(token based authentication) 

대부분의 토큰 기반 인증에서는 JWT(Json Web Token)을 사용하기 때문에 JWT based authentication이라고도 불린다.

JWT Logo

그렇다면 JWT는 무엇일까? 

JWT는 세션 기반 인증의 단점을 보완하기 위해 나온 하나의 인터넷 표준 인증 방식이다.

JWT는 서명된 토큰으로 서버에서 이 토큰이 정상적인 토큰인지 인증하는 방식으로 작동한다.

이를 가능하게 해주는 것은 JWT의 구조 때문이다. 

 

JWT Structure

JWT는 헤더(header), 정보(payload), 서명(signature) 세 개의 영역으로 구분되고 각각은 고유의 역할이 있다.

xxxxx.yyyyy.zzzzz의 구조로 '.'으로 구분되어있는 형태이다. 

 

1. header는 xxxxx의 위치로 타입(JWT)와 어떤 알고리즘(alg)이 쓰였는지의 정보를 담는다.

여기서 알고리즘의 정보를 전달하기 때문에 서버가 달라져도, decryption 알고리즘만 공유된다면 인증할 수 있는 것이다.

2. payload는 yyyyy의 위치로 유저 정보와 만료기간 같은 실질적인 data를 담는 영역이다. 

유의해야할 점은, payload에 민감한 개인정보를 담아서는 안된다는 것이다.

header와 payload는 암호화 되어있지 않기 때문에 누구나 jwt.to 에서 decoding을 하여 정보를 확인할 수 있다.

따라서 user_id 같은 노출되어도 상관없는, 오로지 식별을 하기 위한 정보만을 담는 것이 좋다. 

3. signature는 zzzzz의 위치로 JWT의 핵심 영역이라고 볼 수 있다. Signature는 인코딩 된 header, payload, secret을 합친 뒤 이를 header에서 지정한 알고리즘으로 hashing 한다. 

이때 secret은 서버가 가지고 있는 개인키이며 이를 이용하여 데이터를 암호화한다. 따라서 signature는 서버에 있는 개인키로만 decoding 할 수 있다. 

 

작동 방식

1. 유저가 로그인을 하고, 서버는 세션을 이용해서 정보를 기록하는 대신 token을 발급한다.2. 서버는 이 토큰을 클라이언트에 전달하고, 클라이언트는 발급된 token을 브라우저에 저장한다.3. 서버는 매 요청시 클라이언트로부터 전달받은 header의 token 정보를 verification 하여 인증을 처리한다.장점 - 서버 메모리에 부담X, 서버에 데이터가 저장되는 것이 아니기 때문에 서버 확장성이 좋다. 

절대 비밀번호, 이메일 같은 중요한 정보를 토큰에 담아서는 안된다. 

 

세션 기반 인증과의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않는다는 것이다. 

따라서 이 때문에 다른 서버와의 호환성 또한 늘어난다. 

 

3. 세션 기반 인증 vs 토큰 기반 인증

세션 기반 인증의 단점을 보완하여 나온 것이 토큰 기반 인증이기 때문에, 요즘에는 토큰 기반 인증이 더 널리 사용된다.

하지만 Netflix에서 공유 중인 계정의 수를 제한하는 기능은 session을 이용하는 것처럼 아직도 session 을 이용하여 인증을 처리하는 곳 또한 많다.

따라서 각 인증 방식을 파악하여 사용하는 것이 중요하다.