TIL(38일차)

📝오늘 배운 것

• 토큰 방식의 로그인과 세션 방식 로그인의 차이

  jwt 참고 글

  session login
  django에서 authenticate를 사용한 로그인 방식은 서버에 세션을 생성 및 저장하고, 클라이언트에 세션 id를 넘겨줘서 이후 클라이언트가 세션 id로 서버에 요청을 하면 서버에 저장된 세션 정보로 인증을 처리한다.
  token login
  클라이언트가 사용자의 인증 정보를 서버에 전달하면 받은 사용자의 인증 정보로 인증 처리 후 토큰(jwt)을 생성하여 클라이언트에게 전달하고, 클라이언트는 브라우저에 토큰을 저장해서 이후 이루어지는 요청은 토큰을 이용하여 서버에서는 다시 토큰을 받아 검증하고 인증을 처리한다.

  차이점

  가장 큰 차이점은 세션은 서버에 세션을 저장하는 반면, 토큰은 서버에 아무것도 저장이 되지 않으며, 저장된 것이 없기 때문에 세션을 탐색하는 과정도 필요가 없다.

  그리고 세션은 만료가 되면 클라이언트가 사용자 정보를 제출하여 다시 세션을 만드는 과정을 거치지만, 토큰은 refresh 되어 과정이 간결하다.

• 로컬스토리지에 저장하는 방식과 쿠키에 저장하는 방식
  쿠키는 매번 요청마다 실려서 보내지지만, 로컬스토리지는 그렇지 않으며 저장할 수 있는 공간도 로컬 스토리지가 더 크다. 그리고 쿠키는 만료가 있지만 로컬 스토리지는 만료가 없으며 저장하는 과정도 쿠키는 매우 복잡하지만 로컬 스토리지는 간결하게 저장할 수 있다.

• jwt
  jwt는 Header, Payload, Signature 구조로 이루어져 있으며 각각의 구조마다 고유의 역할이 있다.

  Header 부분은 jwt의 메타 정보를 나타내며 토큰의 type과 alg(알고리즘)을 나타낸다.

  payload 부분은 토큰 만료시간 및 사용자의 정보와 같은 실질적인 데이터를 담으며, 유저의 인증 정보가 아닌 유저를 특정할 수 있는 값만 담아 해싱하여 보안상으로도 문제가 없다.

  signature 부분은 해싱된 Header, payload와 django 프로젝트의 secret_key를 해싱하여 모두 합쳐서 위 header에서 정의한 알고리즘대로 해싱한 값이며 jwt의 구조 중 어느 것 하나라도 틀리다면 signature은 전혀 다른 값을 가지게 되어 보안에 유리하다.

• drf에 jwt 적용
  simple-jwt를 install하고, setting에 restframework의 기본 인증 클래스로 simple-jwt의 인증을 등록한 다음 urls에 api/token과 api/token/refresh를 추가하여 drf에 jwt를 이용한 인증과 인증 만료 시 refresh로 재발행하는 과정을 배웠다.

• jwt의 payload 커스터마이징
  먼저 jwt를 커스터마이징을 하기 위해 settings에 jwt의 기본 설정값을 추가해주고, TokenObtainPairSerializer와 TokenObtainPairView를 simplejwt의 serializers,views에서 불러와 커스터마이징 할 수 있다.

  simple-jwt 공식문서 참고

• jwt의 토큰 유효, 만료기간 설정
  settings의 simple-jwt 기본 설정값에 ACCESS_TOKEN_LIFETIME과 REFRESH_TOKEN_LIFETIME에 원하는 설정을 하여 유효기간과 만료기간을 설정할 수 있다.

• jwt 토큰 만료 시 재발행(refresh) 방법
  로그인시 생성된 refresh token으로 api/token/refresh 경로에 제출하여 새로운 access 토큰을 발급 받고, 재인증 과정에서 headers의 value에 Bearer access토큰을 넣어 제출하면 재인증이 된다.

🛠️Error

프론트에서 js로 백엔드에 사용자 정보를 넘기는 과정에서 에러가 발생했다.
대충 에러메세지를 보니 백엔드 서버와 연결이 끊어진 것 같았다.

역시 확인해보니 백엔드 서버가 연결이 끊어진 상태였고, 에러메세지를 확인하고 구글에 검색해보니 보통 Installed Apps에 콤마가 빠졌을 경우 많이 나타나는 에러인 것 같았다.

하지만 내가 작성한 Installed Apps는 콤마가 잘 찍혀있었고, 따옴표도 문제 없고 settings를 전체 훑어 보아도 딱히 잘못 입력한 부분은 없어보였다.

그렇게 장시간 삽질을 하던 중에 프론트쪽에서 cors-policy 문제를 해결하기 위해 django cors headers를 install 받았었고, installed apps에도 등록했으나 혹시나 install한 앱들의 list를 봤는데 cors headers가 없었다.

분명 설치했지만 설치가 정삭적으로 진행되지 않은 것 같고, 그 상태에서 내가 installed apps에 추가하여 발생한 에러인 것 같아 다시 pip install django-cors-headers 명령어로 install 해주었더니 문제가 해결이 되었다.

다음부터 WinError 123 에러가 발생하면 내가 installed apps 부터 확인하고 내가 설치한 패키지들도 잘 있는지, 추가를 잘 했는지 부터 확인해야 할 것 같다.