코틀린

TIL 20231230

개발자 백구 블로그 2023. 12. 30. 14:51

스프링 심화(인증/인가 파트) 들어가기 전에 맛보기 느낌으로 간략하게 인증 방식에 대한 지식을 배웠다..

 

음 예전에도 로그인 관련된 걸 했을때 살짝 해봤던 것 같은데,, 그땐 제대로 했던게 아니라서,, 정확히 어떤식으로 했는지 기억이 나진 않는다.. 그래서 그 이후를 반성해서 배운 걸 정리하고 앞으로를 위해서 추가적으로 학습하는 시간을 가져보려고 한다.

 

 

 

인증 방식의 종류

 

쿠키/ 세션 기반인증

 

HTTP는 기본적으로 Stateless한 특성을 지닌다. 클라이언트가 특정 요청을 보내면, 서버가 알맞은 응답을 보내는 게 다인데, 이전 요청에 대한 정보나, 클라이언트에 대한 정보를 다음 요청에서 포함하도록 설계되어있지는 않다. 이러한 특성을 해결하기 위해 쿠키와 세션을 이용한다.

 

인증 절차

 

  • 클라이언트가 로그인을 요청하면, 세션 ID를 부여하고, 세션 ID 및 클라이언트 정보를 서버측에 저장한다.
  • 서버는 세션 ID를 쿠키에 설정하여 다음 요청부터 세션 ID를 확인할 수 있게 한다.
  • 클라이언트는 다음 요청부터 세션 ID가 쿠키에 담긴채로 요청을 보내게 된다.
  • 서버는 클라이언트의 세션 ID가 존재하는지 저장소에서 확인을 한 후, 존재할시 정상적으로 요청에 대한 응답을 하고, 아닐시 에러를 응답한다.
  • 세션 ID가 있다하더라도, 클라이언트의 권한이 해당 Resource에 대해 없으면 에러를 응답한다. (인가)
  • 세션 ID를 통해 매번 Client의 인증 상태 정보를 확인하고, 다른 상태 정보도 저장하고 있으므로, Stateful 하다고 말할 수 있다.

 

 

 


쿠키(Cookie)
클라이언트(브라우저)에 저장 되는 작은 데이터 조각으로, 주로 클라이언트의 상태 정보를 저장하기 위해 사용한다.
서버에서 전송이 되어 클라이언트에 저장되고 이후 같은 서버에서 요청이 있을 때마다 자동적으로 서버에 전송된다.
이름, 값, 유효 시간, 도메인, 경로 정보가 포함된다.

 


세션 (Session)
세션은 서버 측에서 클라이언트의 상태를 유지하는 기술로, 클라이언트에게 고유한 세션 ID를 부여하여 클라이언트 정보를 관리한다. 이 때, 세션 ID를 부여하기 위해 일반적으로 쿠키를 사용합한다.

ID를 쿠키에 부여하면 서버측에 매 요청마다 전송이 되니 확인하기 쉽다.
서버는 세션 ID 외의 클라이언트 정보를 서버 측 메모리나 별도 저장소를 이용하여 저장한다.

 
 

장점
클라이언트 관련 정보를 모두 서버에서 관리한다는 측면에서 보안에 좋다. 
세션 ID만이 왔다갔다 하므로, 트래픽을 적게 사용한다.


단점
확장성이 좋지않다. 사용자가 많아지면, 보통 서버를 한 대가 아니라 여러 대를 두게 된다. 세션 정보는 보통 서버 애플리케이션 측 메모리에 저장하는데, 이때 클라이언트가 기존에 요청하던 서버가 아닌 다른 서버에 요청하면 해당 서버는 클라이언트의 세션 ID가 없다고 판단하게 된다. 이를 방지하기 위해, 서버측 메모리가 아닌 별도의 저장소(데이터베이스)를 둘 순 있으나, 이 때에는 매 요청마다 저장소를 통하여 세션 ID를 확인하는 작업이 추가로 들어가기에, 매우 비효율적이다.

 

 

 

토큰 기반 인증

 

인증정보를 서버측에서 저장하고 있지 않고, 토큰이라는 데이터에 저장하여, 클라이언트가 토큰을 갖고 요청을 하게끔 하는 방식이다.
서버는 토큰을 생성하고, 클라이언트는 토큰을 저장을 한 후 요청시에 서버에 제공한다. 브라우저에는 토큰을 저장할 수 있는 로컬 스토리지와 같은 저장소가 있다.
서버에서 정보를 저장하지 않고 클라이언트에서 저장을 하므로, 서버는 토큰을 받았을시, 해당 토큰이 정말 서버에서 발급한 토큰인지 검사를 해야한다. 그렇기 때문에 토큰을 검증하기 위한 방식을 추가적으로 설정한다.

 

 

인증 절차

 

 

  • 클라이언트가 로그인을 요청하면, 서버에서 토큰을 생성하여 응답으로 전달한다.
  • 클라이언트는 자체적으로 토큰을 저장한다.
  • 클라이언트가 요청시에 토큰을 함께 보낸다. 일반적으로, HTTP Header에 넣어 토큰을 함께 전송한다.
  • 서버는 해당 토큰이 정말 자신이 생성한 토큰인지 검증한다.
  • 자신이 생성한 토큰이라 검증이 되었을 때 정상 응답을 보내고, 아닐시에 에러를 응답한다.

 

 

장점
서버에서 토큰을 저장하지 않고, 세션 상태를 유지하지 않기 때문에 Statless하다고 할 수 있다. 그렇기에 확정성이 좋다.
토큰 기반이기 때문에, 별도의 시스템이더라도 검증 방식만 공유 된다면, 다른 로그인 시스템에도 동일한 토큰으로 인증을 할 수 있다.

 

단점
토큰 자체에 유저의 중요한 정보를 담기에는 보안상 취약할 수 있다.
토큰은 아무래도 세션 ID에 비해 데이터의 사이즈가 커, 인증 요청이 많아진다면 네트워크 부하가 발생할 수 있다.

 

단점 보완

  1. 로그인시 토근 만료가 짧은 access 토큰 1개, 토근 만료가 긴 refresh 토큰 1개를 발급한다.
  2. refresh 토큰은 DB에 저장한다.
  3. access 토큰의 수명이 다하면 다시 refresh 토큰에 보낸다.
  4. 서버는 DB의 값과 대조하고 확인.

 

간단하게 말해서 쿠키/세션 기반 인증과 토큰 기반 인증의 차이점이다.

 

 

 

인증 방식 종류에 대해서 간편하게 배웠다.. 전엔 세션 쿠키 방식으로 좀 배웠던거 같은데,, 이번엔 토큰 방식에 JWT를 배운다니까 좋았다.. 새로운 걸 배울 수 있는 기회가 있어서??

열심히 해보장 아자아자