HTTP통신, 쿠키, 세션, 토큰

diense_kk·2023년 7월 27일
0

Developer

목록 보기
2/8

인증 & 인가

인증(Authentication) "넌 누구냐"
-> 사용자가 누구인지 확인하는 것
Ex) 회원가입, 로그인

인가(Authorization) "너냐? 통과"
-> 사용자의 요청에 대해 권한을 확인하는 것
로그인 이후에만 접근 가능한 페이지에 대한 권한 허락

1. 인증

1-1. 로그인 요청: 사용자가 아이디와 비밀번호를 입력하고 로그인을 요청합니다.

1-2. 사용자 확인 : DB에 저장된 사용자의 비밀번호와 사용자가 입력한 비밀번호를 비교해보고, 인증 여부를 결정합니다.

1-3. 토큰 발급 : 사용자 정보가 일치하다면, 사용자의 정보가 담긴 일종의 출입증인 "토큰"을 사용자에게 전송합니다.

1-4. 상태 유지 : 이제 다음 요청부터는 아이디 비밀번호가 아닌 토큰을 제시합니다.

2. 인가

인가를 위해서는 인증이 선행되어야 한다.

2-1. 데이터 요청 : 사용자는관리자에게만 허용된 페이지로 넘어가려 합니다. 서버에 페이지 요청과 함께 아까 발급받은 토큰도 제시합니다.

2-2. 토큰 검증 : 서버는 토큰을 보고 어떤 사용자가 요청했는지를 식별 한 후 DB에서 사용자가 이 페이지에 대한 접근 권한이 있는지를 확인합니다.

2-3. 인가 처리 : 사용자의 권한이 확인되면, 요청을 처리해줍니다.

HTTP 통신

HTTP는 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜이다.

보통 url앞에 http나 https가 있는데 이것이 "이 프로토콜로 통신할거야" 라고 말해주는 자리입니다.

https는 s(secure)이 추가된 버전으로, 보안이 더 강화된 버전입니다.

HTTP는 다음과 같은 특징이 있습니다. 이 특징 때문에 인증과 인가를 위해 토큰, 세션, 쿠키를 이용하게 됩니다.

  1. 사용자가 서버에 요청을 했을 때, 서버는 요청에 맞는 응답을 보내준 다음 바로 연결을 끊어버립니다.
  2. 서버는 사용자의 상태 정보를 저장하지 않기 때문에 이전에 통신을 했는지, 어떤 데이터를 주고 받았는지 전혀 기억하지 못합니다.

쿠키 & 세션

둘의 공통점은 클라이언트의 정보를 연속적으로 유지하기 위해 존재한다는점입니다.

둘의 차이점은 상태 정보의 저장 위치입니다.

쿠키(Cookie)

사용자가 어떤 웹사이트를 방문할 때, 사용자의 PC에 저장하는 조그만 정보 파일입니다.

자주 방문한 사이트에 ID와 PW가 자동입력 되어 있거나 팝업창에서 오늘은 다시 보지 않기를 클릭하는 것등은 모두 쿠키를 활용한 사례입니다.

첫 방문 시점에 저장해두고, 이후 동일 사이트에 방문할 경우 서버는 쿠키 정보를 바탕으로 ID와 PW가 입력된 사이트, 팝업창이 생략된 사이트를 보여주는 것입니다.

쿠키는 사용자 PC에 저장되므로 속도가 빠르고 서버의 자원을 낭비하지 않아 효율적입니다.

그렇지만 사용자의 PC에 저장되므로 해킹의 위험이 있고, 브라우저가 종료되어도 자동으로 삭제되지 않아 보안 측면에서 세션보다 떨어집니다.

이러한 이유로 민감한 정보를 저장하지 않습니다.

세션(Session)

세션은 일정 기간 사용자의 상태를 일정하게 유지시키는 기술입니다.

로그아웃하거나 브라우저를 닫아버리면 세션이 뚝 끊기므로 다음 접속 시에는 다시 로그인해야 합니다.

브라우저 하나당 하나의 세션이 생성되고 해당 브라우저에서 들오어는 요청들은 모두 동일한 세션 ID로 식별해서 처리합니다.

로그인 후 다른 화면으로 이동해도 로그인이 풀리지 않고 로그인 상태가 유지되는 것이 바로 세션 덕분입니다.

새션은 서버에서 관리하기 떄문에 상대적으로 안전한 상태를 유지할 수 있고, 브라우저를 닫으면 자동으로 삭제되기 떄문에 쿠키보다 보안이 좋습니다.

그렇지만 세션은 서버에 저장되기 떄문에 많은 사람들이 사용하면 과부하가 올 수 있고, 서버와 통신하므로 속도가 느리다는 단점이 있습니다.

세션은 쿠키와 함께 사용된다.

  1. 사용자 로그인시 사용자는 서버에 쿠키 정보를 함께 보낸다.

  2. 이후 서버는 사용자가 전달한 쿠키에 세션 id가 있는지 확인한다.

  3. 세션 id가 존재하면 상태를 유지해주고, 존재하지 않는다면 세션 id를 새로 생성해서 DB에 저장합니다.

  4. 그리고 사용자에게 웹페이지를 돌려줄 때, 쿠키에 방금 생성한 세션 id 정보를 함께 넣어서 줍니다.

  5. 이 쿠키는 요청을 보낸 사용자의 PC 에 저장됩니다.

  6. 이제 사용자는 다른 요청을 보낼 때 세션 id가 포함된 쿠키를 동봉하게 되고 서버는 세션 id로 사용자를 식별하여 사용자의 상태에 알맞게 처리해줍니다.

하지만 로그인 할 때 쿠키/세션 방식을 사용하면 해커가 쿠키를 가로채서 치명적인 보안 문제를 일으킬 수도 있고 서버는 수많은 사용자의 세션을 저장하고 요청이 들어올 때마다 확인 작업을 하느라 서버의 부담이 커질 수도 있습니다.

이때 등장하는게 바로 토큰입니다.

토큰 기반 인증은 위의 세션/쿠키 보다 보안성이 높고 서버에게도 효율적인 방식이다.

토큰(Token)

토큰은 사용자의 인증 정보를 암호화 한 것으로, 일종의 출입증 역할을 합니다.

사용자가 최초 로그인 시 토큰을 발급해주고, 이후 사용자는 이 토큰을 가지고 다른 웹사이트들도 "출입" 할 수 있게 됩니다.

  1. 사용자가 로그인 시 서버는 토큰을 발급 해줍니다.
  2. 사용자는 발급된 토큰을 PC에 저장합니다.(쿠키처럼 로컬에 저장)
  3. 사용자는 이후 다른 요청을 보낼 때 토큰을 동봉해서 보내게 됩니다.
  4. 서버는 사용자의 토큰 정보를 검증한 뒤 사용자의 권한을 확인하고 인가 요청을 처리해줍니다.

토큰은 세션과 달리 사용자 PC에 저장 됩니다.

세션에서처럼 서버에 유저의 정보를 저장할 필요가 없고 서버는 토큰에 댜헌 검증만 수행하면 되기 때문에 서버에 부담이 적은 방식입니다.

물론 토큰도 세션처럼 중간에 해커가 가로채는 위험이 발생할 수 있습니다.

그래서 보안 피해를 최소화하기 위해 서버는 2가지의 종류의 토큰을 사용자에게 발급합니다.

첫번째는 "출입증"으로 사용할 Access Token 두번째는 Access Token이 만료 되었을 때 인증 상태를 연장 해 줄 Refresh Token입니다.

보통 보안을 위해 Access Token의 유효기간을 짧게 설정하고 Refresh Token의 유효기간을 보다 길게 설정해놓습니다.

사용자는 Access Token으로 요청을 보내지만, Access Token의 유효기간이 만료되면 Refresh Token을 서버에 보냄으로써 새로운 Access Token을 발급받을 수 있게 됩니다.

Refresh Token은 만료시에만 노출되기 때문에 해킹을 당할 위험이 적습니다.

0개의 댓글