[로그인 구현하기 #1] 쿠키 세션 토큰 캐시 공부 및 정리

hyunwoo Jin·2023년 2월 9일
0
post-thumbnail

들어가기 앞서 . .

드디어 사이드 프로젝트에서 로그인을 구현하려고한다.
걱정도 되지만 프론트엔드 개발을 한다면 꼭 알아야 하는 부분이라 생각한다.
로그인 기능을 구현하면서 연계되는 다양한 내용들이 많이 나올 것 같아서 기록과 함께 내가 어떤 생각을 가지고 개발을 했는지 후에 그 생각들이 옳았는지 비교할 수 있었으면 한다.

! 여러가지 자료들을 통해 정리된 견해로 주관적이거나 전문성이 떨어지는 정보가 있을 수 있습니다. 피드백 언제나 환영합니다.

쿠키 세션 토큰 캐시

쿠키 세션 토큰 캐시 모두 익숙히 들어 보았던 단어다.
상태(state)를 유지할 때 사용하는 도구들 정도로 생각했다.
로그인 구현에 앞서 이 친구들에 대한 개념은 확실히 알아야 할 것 같았다.
이번 글에서는 이 친구들에 대한 내용을 담을 것이다.

  • 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 4KB 내의 작은 데이터 파일
  • 사용자 인증이 가능한 유효시간을 명시한다. 유효시간이 정해지면 브라우저가 종료되더라도 인증이 유지된다.
  • 최대 300개의 값을 저장할 수 있으며, 도메인 당 20개까지 저장할 수 있다.
  • response-header에 Set-Cookie 속성을 사용하여 클라이언트 쿠키를 생성 가능하다.
  • 브라우저에 따라 저장되는 위치가 달라진다.
  • 장바구니, 오늘 더이상 보지 않음 과 같이 가벼운 내용들에 사용된다.
  • 보안성이 떨어지고 스니핑 공격에 취약하다. 개인 정보와 같은 중요 정보는 담지 않는 것이 좋다.

동작 방식
1. 클라이언트가 페이지를 요청한다.
2. 서버에서 쿠키를 생성하여 HTTP 헤더에 쿠키를 담아 응답한다.
3. 클라이언트는 쿠키를 로컬에 저장하고 있다가 다시 서버에 요청할 때 HTTP 헤더에 쿠키를 담아 보낸다.
4. 서버는 쿠키를 보고 상태정보가 변경되었으면 업데이트하여 응답한다.

세션(session)

  • 쿠키를 기반으로 하나 클라이언트 정보를 서버에서 저장 및 관리한다.
  • 쿠키에 비해 보안성이 좋으나 사용자가 많아지면 서버 메모리를 차지하게 되고 동시 접속자 수가 많으면 서버 과부하로 인한 성능 저하 발생
  • 서버는 클라이언트 구분을 위해 세션ID를 사용한다.
  • 웹 브라우저가 서버에 접속하고 브라우저가 종료될 때까지만 인증상태를 유지한다.
  • 접속 시간에 제한을 두어 일정 시간동안 서버에 응답이 없을 경우 정보가 유지되지 않도록 한다. 흔히 보았던 세션 만료 인 듯 하다..!

동작 방식
1. 클라이언트에서 페이지를 요청한다.
2. 서버는 response-header 에 쿠키에 세션ID가 있는 지 확인한다.
3. 세션ID가 없으면 서버의 엔진이 세션ID를 생성하여 클라이언트에 반환한다. 동시에 서버는 해당 ID를 세션 저장소에 저장하고 구분할 수 있게 한다.
4. 클라이언트는 서버로부터 받은 세션ID를 쿠키를 사용하여 로컬에 가지고 있는다
5. 이 후 클라이언트에서 같은 요청으로 서버에 접속할 때 HTTP요청 내 가지고 있던 세션ID를 담아 보낸다.
6. 서버는 해당 ID를 통해 세션 저장소 내 클라이언트 정보를 확인하고 요청에 맞는 서비스를 제공한다.

토큰(Token)

  • Token 기반 인증 방식 JWT(JSON WEB TOKEN)는 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다.
  • 사용자가 access token(JWT)를 HTTP 헤더에 담아 서버에 전송한다.
  • 임의로 생성된 비밀번호처럼 동작한다.
  • 한번 만료되면 새로 생성해야 한다.(refresh token)
  • 쿠키/세션과 달리 인증만을 위해 존재하기 때문에 저장소를 필요로 하지 않는다.(Stateless) 서버 확장 및 유지보수에 유리하다.
  • 토큰을 기반으로 하는 다른 인증 시스템에 접근할 수 있다.
  • 세션/쿠키 인증 방식의 경우 악의적 사용이 발생할 경우 쿠키를 삭제하면 되지만 JWT는 유효기간이 만료되기 전까지는 대처가 불가능하다. 이를 방지하기 위해서 access token 의 유효기간을 짧게 설정하고 refresh token 을 발급하여 access token 탈취 피해를 최소화시킬 수 있다.
  • 길이가 길기 때문에 인증 요청이 많아질수록 자원 낭비가 심해진다.

동작 방식
1. 클라이언트가 로그인한다.
2. 서버에서 클라이언트 정보를 확인 후 고유ID 값을 부여하고 기타 정보와 함께 payload 에 저장한다.
3. JWT 의 유효기간을 설정합니다.
4. secret key 를 이용해 access token 을 발급한다.
5. 클라이언트는 access token 을 받아 저장 후 인증이 필요한 요청의 헤더에 담아 전송합니다.
6. 서버는 토큰에 담긴 Verify Signature 를 Secret key 로 복호화한 후 조작여부와 유효기간을 확인한다.
7. 검증이 완료되면 payload 를 디코딩하여 클라이언트 ID에 맞는 데이터를 가져온다.

캐시(cache)

  • 지역성을 이용하여 데이터에 빠르게 접근하기 위한 메모리 계층이다.

    시간적 지역성 : 최근에 사용된 데이터는 또 사용될 것이다.
    공간적 지역성 : 사용된 데이터 주변 데이터는 사용될 확률이 높다.
    순차적 지역성 : 메모리에 저장된 순서대로 사용될 확률이 높다.

  • 파레토의 법칙에 따라 서비스를 이용할 때 많이 사용되는 데이터를 캐싱한다면 전체적으로 영향이 발생하며 효율을 극대화 할 수 있다는 철학을 가졌다.

참고자료1
참고자료2
참고자료3

profile
꾸준함과 전문성

0개의 댓글