시작이 반

[WEB] 로그인 쿠키/세션/토큰 본문

Programming/WEB

[WEB] 로그인 쿠키/세션/토큰

G_Gi 2021. 11. 29. 20:42
SMALL

로그인 방식에는 쿠키/세션/토큰이 쓰인다.

우선 쿠키/세선/토큰을 정리하기 전에 HTTP에 대해서 알아보자

(구글링 해서 알게된 정보로 정확하지 않을 수 있습니다.)

 

HTTP

모바일이나 웹서비스에서 가장 많이 쓰이는 통신 방식은 HTTP통신이다.

HTTP통신 2가지의 특성을 가지고 있다.

 

- Connectionsless : 요청을 하고 응답을 받게 되면 서로 접속을 끊는 특성이 있다.

- Stateless : 접속을 끊는 순간 이전 상태 정보를 유지하지 않는 특성을 가지고 있다.

 

즉, 만약에 로그인을 하게 된다면 이전 상태 정보를 유지하지 않기 때문에 여러 서비스를 누를 때마다 이 사람이 로그인을 했는지 알 방법이 없다. 때문에 이동할 때마다 로그인을 다시 새로 해줘야한다.

 

이러한 문제점을 해결하려고 나온 것이 쿠키/세션/토큰 이다.

 

 

쿠키(Cookie)

  • 쿠키는 클라이언트의 브라우저에 저장되어있는 데이터 파일이다.
  • Key-Value 형식이다.
  • 이름, 값, 만료시간, 경로 정보가 들어있다.
  • 쿠키는 header에 넣어서 서버에 전송된다. (쿠키는 자동으로 전송된다 한다.)
  • 즉 데이터를 전송하는 매개체라고 생각

쿠키는 요청시 쿠키의 값을 그대로 보내기 때문에 보안에 취약하고 유출, 조작 당할 위험이 존재한다. 이 때문에 로그인에 단독으로 사용되지 않고 세션과 같이 사용된다.

 

쿠키는 그럼 어디에 사용될까?

예를 들어 사이트에서 로그인을 할때 "아이디 기억" 체크 박스, "오늘 이창을 보지 않음", 쇼핑몰 장바구니와 같은 곳에 쓰인다고 할 수 있다.

 

제약조건

  • 클라이언트에 총 300개까지 쿠키 저장 가능
  • 하나의 도메인당 20개의 값만 가질 수 있다. (20개 초과하면 가장 빈도수 적은 것 삭제)
  • 하나의 쿠키 값은 4KB까지 저장 가능

 

세션(Session)

HTTP 프로토콜은 Stateless이다. 요청이 끝나면 서버는 우리가 누군지 까먹는다. 이 때문에 요청할 때마다 우리가 누군지 알려줘야한다. 이를 해결하는 방법 중 하나가 세션이다. 서버에 사용자를 저장시켜 기억을 하게 해주는 것이다.

 

  • 서버에 저장을 하기 때문에 따로 세션 저장소가 필요하다. (Redis를 주로 사용한다.)
  • 이 저장소에는 각 클라이언트마다 고유 ID를 부여한다.
  • 서버에 저장되기 때문에 보안적 측면에서 우수하다.

 

쿠키만을 사용해서(쿠키에 아이디, 비밀번호 넣는 것) 로그인을 하는 방식은 쿠키를 탈취할 수 있기 때문에 위험하다고 했다. 때문에 세션과 같이 사용하여 로그인을 하게 된다.

 

사용자를 좀더 빡세게 관리할 때 사용된다고 한다.

세션 저장소에 있는 세션ID를 삭제 시키면 요청이 들어와도 세션 저장소에 해당 세션 ID가 없기 때문에 다시 로그인을 해야한다.

 

그러면 또 쿠키를 탈취해서 다른 사람의 세션ID를 얻어서 그 사람인 척 할 수 있지 않나?

-> HTTPS와 세션에 유효시간을 통해 해결한다고 한다.

 

토큰(JWT)

JWT는 인증에 필요한 정보를 암호화 시킨 토큰이다.

  • Header : 암오할 방식(alg), 타입 등이 들어간다.
  • Payload : 서버에 보낼 데이터가 들어간다. (유저의 고유 ID, 유효기간 등)
  • Verify Signature : Header와 Payload를 더한 후 비밀키로 해싱하여 생성된다.

https://jwt.io

 

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

여기서 암호화된 토큰을 볼 수 있다.

 

 

JWT는 발급후 검증만 하면 되기 때문에 따로 저장소가 필요없다.

Stateless 한 서버를 만드는 입장에서 큰 강점이다.

누군가가 데이터를 위/변조 했다 해도 서명된 정보를 통해 검증을 하기 때문에 막을 수 있다.

(근데 탈취당하면 어쩔수 없는듯)

 

토큰은 이미 발급되면 돌이킬 수 없다. 때문에 관리자가 강제로 로그아웃 시키는 행위흘 할 수 없다.

-> Access Token의 유효기간을 짧게하고 Refresh Token이라는 새로운 토큰을 발급시키는 방식으로 해결할 수 있다한다.

 

 

그럼 토큰은 어디에 저장될까??

LocalStorage와 Cookie에 저장을 할 수 있다고 한다.

각각의 장단점이 있다.

 

LocalStorage에 저장

  • CSRF공격에 안전
  • XSS공격에 취약

Cookie에 저장

  • XSS공격에 안전
  • CSRF공격에 취약 (HTTPOnly 와 Secure옵션을 사용하면 CSRF공격에 대비를 할 수 있다곤한다.)

음... 찾아보니까

Access토큰을 어플리케이션 로컬 변수에 저장시키고 refresh토큰만 쿠키에 저장시키고 사용하는 것도 있다고한다.

근데 이러면 페이지가 리로드되거나 다른 곳으로 이동할 때마다 Access 토큰 값이 사라지기 때문에 리로드, 토큰이 만료되면 refresh토큰을 이용해서 Access토큰을 재발급 받는다고 한다.

 

흠... 어렵다.

 

참고:

https://tansfil.tistory.com/58

https://www.youtube.com/watch?v=tosLBcAX1vk 

https://juyoung-1008.tistory.com/2

 

 

LIST

'Programming > WEB' 카테고리의 다른 글

웹서버와 웹어플리케이션 서버  (0) 2021.04.20