TIL - 22.02.22

 

개인 공부 후 자료를 남기기 위한 목적이므로 내용 상에 오류가 있을 수 있습니다.

 

2월 22일(화)

 

django session authentication

---

How session authentication works

 

session 과정은 다음과 같다.

 

1. 클라이언트에서 사용자의 인증 정보를 서버에 전달한다.
2. 서버는 인증을 처리한 뒤, 해당 user에 대해 session을 생성한다.
3. session 정보는 서버에 저장되고, 클라이언트는 session id를 받아 브라우저에 저장한다.
4. 클라이언트는 이후 이루어지는 요청에 session id를 이용한다.
5. 서버는 전달받은 session id를 이용하여 저장 중인 session 정보로 인증을 처리한다.
6. 만약, session id가 만료된다면 1번 과정부터 다시 동일 절차가 진행된다.

 

session authentication

 

여기서 중요한점은 session 정보를 서버에서 관리한다는 사실이다.

클라이언트도 브라우저에 session id를 저장하여 사용하지만, session id 자체는 중요한 정보가 담겨있지 않은 일종의 임시 비밀번호이며 실제 session의 정보를 관리하는 것은 전적으로 서버의 역할이다.

 

django에서 기본으로 제공하는 session 인증을 사용해보면, django_session 테이블이 생성되고 그 안에 session_key, session_data, expire_data와 같은 필드로 session 정보가 저장된다.

 

위의 인증 절차 때문에, session 인증을 위해서는 매 요청마다 데이터베이스를 탐색해야 한다는 단점이 있다.

캐시 등을 이용하여 탐색 과정을 최적화할 수 있지만, 기본적으로 session 정보를 어딘가에 저장해야 되는 구조이다.

또한, session 정보를 저장하는 데이터베이스가 분산되어 있을 경우에는 각각의 데이터베이스를 탐색해야 하며 MSA(MicroService Architecture)로 설계된 경우에는 각 어플리케이션 마다 session 정보를 통합으로 관리하기도 쉽지 않다.

 

 

django jwt(json web token)

---

JWT : Token based authentication

 

토큰 기반의 인증과 session 인증의 가장 큰 차이점은 토큰 자체에 유저 정보가 담겨 있다는 것이다.

session 인증은 모든 유저의 정보와 session 정보를 서버에서 관리하지만, JWT 인증에서는 토근에 유저 정보를 담는다.

 

JWT 인증의 절차는 다음과 같다.

 

1. JWT 인증 절차는 session 인증 절차와 마찬가지로 클라이언트에서 사용자의 인증 정보를 서버에 전달한다.
2. 서버는 인증 정보로 인증을 처리하고, session 대신 JWT를 생성하여 클라이언트에 전달한다.
3. 클라이언트는 JWT를 브라우저에 저장한다.
4. 클라이언트는 이후 이루어지는 요청에 JWT를 사용한다.
5. 서버는 JWT를 검증하여 인증을 처리한다.
6. JWT가 만료되면 토큰을 refresh 한다.

 

JWT authentication

 

JWT 인증과 session 인증의 차이점을 비교해보면 다음과 같다.

 

1. session 정보는 서버에 저장되는 반면, JWT 인증에서는 서버에 어떠한 정보도 저장되지 않는다.
2. session 확인을 위해서는 데이터베이스를 탐색하지만, JWT 인증에서는 토큰을 바로 검증한다.

 

session 인증과 JWT 인증의 가장 큰 차이점은 서버에 인증 정보를 저장하지 않는다는 것이다.

그렇기 때문에 클라이언트 요청마다 인증을 위해 데이터베이스를 탐색하는 과정이 필요 없다.

django에서 JWT 인증을 사용해보면 session 인증과 달리 데이터베이스에 별도의 테이블이 생성되지 않는 것을 확인할 수 있다.

 

 

JWT Structure

 

JWT가 유저의 정보를 담고 있음에도 보안을 유지할 수 있는 비결은 JWT의 구조 때문이다.

 

xxxxx.yyyyy.zzzzz

 

JWT의 구조는 위의 예시처럼 dot(.)을 기준으로 크게 세 영역으로 나눌 수 있다.

 

먼저, xxxxx 부분은 Header 영역이며, JWT의 메타정보를 나타낸다. (ex : type, algorithm 등)

그 다음 yyyyy 부분은 Payload로 불리는 영역으로 토큰이 만료되는 시간과 유저의 정보와 같은 실질적인 데이터를 나타낸다. 참고로, xxxxx 영역과 yyyyy 영역은 Base64Url로 인코딩되어 있다.

 

마지막 zzzzz 부분은 JWT의 핵심인 Signature 영역이다.

JWT는 signing을 통해 토큰 안에 유저 정보를 담으면서도 이를 안전하게 처리한다.

Payload 영역에 담긴 유저 정보는 인코딩만 되어 있으며, 별도의 암호화 처리는 되어있지 않다.

즉, 누군가에 의해 쉽게 디코딩될 수 있으며 변조도 가능하다는 의미이다.

따라서, 이러한 변조의 문제를 해결하기 위해 Signature 영역이 필요한 것이다.

 

Signature가 만들어지기 위해서는 인코딩된 Header, 인코딩된 Payload, Secret이 필요하다.

참고로, Simple JWT에서는 django 프로젝트마다 사용하는 secret_key를 기본적으로 활용한다.

Signature는 인코딩된 Header, Payload, Secret을 합친 뒤에 이를 Header의 지정된 알고리즘으로 해싱한다.

따라서 Header, Payload, Secret 값 중 어느 하나라도 일치하지 않으면 signature는 완전히 다른 값을 갖게 되는 것이다.

 

이렇게 생성된 JWT는 클라이언트에 전달되며, 이후 요청에서 HTTP Header에 담겨서 서버로 전송된다.

서버가 JWT를 검증하는 과정은 JWT가 생성될 때와 마찬가지로  Header, Payload, Secret를 이용하여 signature를 해싱한 후 클라이언트로 부터 전달받은 JWT의 signature와 동일한지 확인한다.

만약, Payload가 변조되었다면 클라이언트에서 받은 signature와 서버에서 해싱한 signature가 다를 것이므로 인증에 실패하게 된다.

 

이렇게 토큰 검증이 완료되면 서버는 Payload에 담긴 유저의 정보를 통해 유저를 특정하고 인증된 유저로 처리한다.

이러한 이유로 JWT 인증은 별도의 데이터베이스 탐색 없이도 빠르게 유저 인증을 수행할 수 있다.

 

 

참고사항

 

JWT와 비교를 위해 session 방식을 부정적으로 언급하였으나, 실제로 session 인증도 널리 사용되는 방식이며 중요한 기능이다. 결국 각 인증방식의 장단점을 명확히 알고 필요에 맞는 기술을 선택하여 사용해야 한다.