DRF 로그인 인증

[Dong-Hyeon-Yu]

현재는 로그인은 세션으로 처리하고 있다.
django session framework 를 사용 중.
브라우저 별로 session_id 를 저장해서 사용.
key(id)-value 쌍으로 db 에 암호화되어 저장되어 있는데, value 는 기본적으로 dict 형태로 저장되어 있다.
원하는 값들을 추가, 제거 가능하다.=> 그때그때 사용자에 대한 정보를 저장하여 이용할 수 있다.

세션

1. DB에 해당 유저의 로그인 정보를 남김
2. 분산된 DB 환경에서는 일정한 상태를 보장할 수 없음.
3. 서버가 유저의 로그인 상태를 계속 추적하고 있다.
4. 웹페이지, 어플 또는 여러 기기 등에서의 동시접속 제어가 가능하다.
5. 토큰보다 보안에 우수하다.

토큰

1. 토큰을 발행하고, 해당 토큰은 db에 저장되지 않음. 클라이언트 쪽에서 보관한다.
2. 사용자에 관한 정보를 클라이언트 쪽에 암호화하여 저장한다.
3. 요청이 들어오면 복호화하여 유효성을 검증하고, 저장되어 있던 사용자 정보로 인증한다.
4. 사용자의 상태를 추적하지 않는다. 세션보다는 더 stateless 하다.
5. 세션 운용보다는 더 간편한 것 같다.

REST api 만들면서 고려해볼점.

1. 스프링을 도입한다면... =>
   (세션)

   • 사용자가 웹페이지를 탐색하면서 서버 스위칭이 발생 (장고<->스프링)
   • 세션을 그대로 사용한다면, 브라우저에 있는 세션 id 를 통해 스프링에서 db에 접근해야함. => 스프링을 안해봐서 모르겠다.

   (토큰)

   • 사용자가 웹페이지를 탐색하면서 서버 스위칭이 발생 (장고<->스프링)
   • 브라우저에 있는 토큰의 유효성만 확인하면 됨.
   • 기존 장고는 완전히 교체되기 전까지 세션인증 방식과 토큰을 병행. => 기존 권한체계를 고려해야함.

2. 장고를 이어간다면...
   (세션)

   • DRF 에서 세션을 사용하도록, session id 만 주고 받으면 될 듯.
   • 다만 context processor 를 못쓰게 됨. 이게 state를 추적하는데 편리하면서 중요한 역할을 해주고 있다는 생각.

   (토큰)

   • 최초 소셜로그인 시 토큰 발급
   • 기존 장고는 완전히 교체되기 전까지 세션인증 방식과 토큰을 병행. => 기존 권한체계를 고려해야함.

머리 아프다..