Spring

[Spring] 쿠키와 세션 인증 방식

Young_Han 2024. 10. 31. 09:45

1. 인증과 인가

 

인증(Authentication)

  • 해당 유저가 실제 유저인지 확인하는 개념이다.
  • 예) 스마트폰 지문인식, 주로 사용하는 사이트에 로그인

 

인가(Authorization)

  • 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념이다.
  • 예) 관리자는 관리자 권한으로 관리자 페이지에 접근할 수 있다.

 

 


2. 웹 애플리케이션 인증

 

 일반적으로 서버 - 클라이언트 구조로 되어있고 실제로 이 두 가지 요소는 멀리 떨어져 있다. Http라는 프로토콜을 이용하여 통신하는데 이로 인해 비연결성무상태가 이루어진다. (HTTP의 특징!)

 

비연결성(Connectionless)
서버와 클라이언트가 연결되어 있지 않다는 의미이다.
그 이유는 리소스를 절약하기 위해서인데 실제로 계속 연결되어 있다면 서버의 비용이 기하급수적으로 늘어나기 때문이다.

 

무상태(Stateless)
서버가 클라이언트의 상태를 저장하지 않는다는 의미이다.
서버에 기존의 상태를 저장하는 것도 비용과 부담이 증가된다. 따라서 기존의 상태가 없다고 가정하는 프로토콜을 이용하여 구현되어 있다. 

 

 

 하지만 우리가 사용하는 인터넷은 이전의 정보들이 잘 있는 것처럼 연속성있게 사용해 왔다. 사실 연속적으로 느껴지기 위해 개발자들이 노력을 하는 것이다.

 

 예를 들어 네이버 뉴스탭에 스포츠탭에 있는 특정 기사를 본다고 생각하면 

"/News/Sports/9"와 같이 url을 계층적으로 설계하고 다음 요청에 대한 api url을 이전 계층에만 둔다면 연속적으로 사용한다고 느낄 수 있다. 

 

 그렇다면 비연결성, 무상태 프로토콜에서 "유저가 인증되었습니다."라는 정보를 유지시켜야 하는 과제를 어떻게 해결했을까?

 


3. 인증 방식

 1. 쿠키 - 세션 방식

  1. 사용자가 로그인 요청을 보낸다.
  2. 서버에서 DB의 유저 테이블을 확인하여 아이디 비밀번호를 대조한다.
  3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 “세션 저장소”에 해당 유저가 로그인되었다는 정보를 넣는다.
  4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급한다.
  5. 서버는 로그인 요청의 응답으로 session-id를 내어준다.
  6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 세션아이디를 같이 보냅니다. (주로 HTTP header에 담아서 보낸다.)
  7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증한다.
  8. 만약 유저정보를 받아왔다면 이 사용자는 로그인이 되어있는 사용자임을 알 수 있다.
  9. 이후에는 로그인 된 유저에 따른 응답을 내어준다.

 

 2. JWT 기반 인증

 JWT(JSON Web Token)이란 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다. JWT기반 인증은 쿠키-세션 방식과 유사하게 JWT토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별한다.

 

  1. 사용자가 로그인 요청을 보낸다.
  2. 서버에서 DB의 유저 테이블을 확인하여 아이디 비밀번호를 대조한다.
  3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화해서 내보낸다.
  4. 서버는 로그인 요청의 응답으로 JWT토큰을 내어준다. (HTTP header)
  5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보낸다.
  6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증한다.
  7. 이후에는 로그인 된 유저에 따른 응답을 내어준다.

 


4. 쿠키(cookie)와 세션(session)

 1. 쿠키(cookie)란?

 쿠키는 웹 사이트에 접속할 때 생성되는 정보를 담은 임시 파일이다. 쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는데 사용자 인증이 유효한 시간을 명시할 수 있으며, 브라우저가 종료되어도 인증이 유지된다는 특징이 있다. 

 

쿠키의 데이터 형태는 Key와 Value로 구성되고 String 형태로 이루어져 있습니다.

 

 브라우저마다 저장되는 쿠키는 다르며 서버에서는 브라우저가 다르면 다른 사용자로 인식한다.

 

 쿠키는 서버를 대신하여 이러한 정보들을 웹 브라우저에 저장(정확히는 웹 브라우저를 사용하고 있는 컴퓨터에 저장)하고 사용자가 요청할 때 그 정보를 함께 보내서 서버가 사용자를 식별할 수 있게 해 준다.

 

 2. 쿠키의 사용 목적

1. 세션 관리(Session Management) : 로그인, 사용자 닉네임, 접속 시간, 장바구니 등의 서버가 알아야 할 정보들을 저장한다.

2. 개인화(Personalization) : 사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다.

3. 트래킹(Tracking) : 사용자의 행동과 패턴을 분석하고 기록한다.

 

 사용 예시)

  • ID 저장, 로그인 상태 유지 
  • 방문 사이트에서 로그인 시, '아이디와 비밀번호를 저장하겠습니까?' 팝업
  • 쇼핑몰의 '장바구니 기능'
  • 자동 로그인, 팝업에서 '오늘 더 이상 이 창을 보지 않음' 체크

 

 3. 쿠키의 구성 요소

  • 이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
  • 값 : 쿠키의 이름과 관련된 값
  • 유효시간 : 쿠키의 유지시간
  • 도메인 : 쿠키를 전송할 도메인
  • 경로 : 쿠키를 전송할 요청 경로

 

 4. 쿠키의 동작 방식

  1. 클라이언트가 페이지를 요청한다.
  2. 서버에서 쿠키를 생성한다.
  3. HTTP header에 쿠키를 포함시켜 응답한다.                                                                                                                (브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있다.)
  4. 다시 클라이언트가 요청을 할 경우 HTTP header에 쿠키를 함께 보낸다.
  5. 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP header에 포함시켜 응답한다.

 

5. 쿠키의 단점

1. 방문했던 웹 사이트에 대한 정보 및 개인정보가 기록되기 때문에 사생활을 침해할 소지가 있다.

    (이를 해소하기 위해 웹 브라우저  자체에 쿠키 거부 기능이 있다.)

 

2. 서버가 가지고 있는 것이 아니라 사용자에게 저장되기 때문에 임의로 고치거나 지울 수 없고 가로채기도 쉬워 보안이 취약하다.

 

 

이러한 단점을 보완해 주는 것이 세션이다.

 


5. 세션(session)

  세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다. 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다. 물론 접속 시간에 제한을 두어 일정 시간 응답이 없으면 정보가 유지되지 않게 설정이 가능하다.

 

 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다. 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.

 

 1. 세션의 동작 방식

 

  1. 클라이언트가 로그인을 요청한다. 이에 서버는 DB에 확인을 하여 ID, Password 정보가 유효하다면 세션을 생성한다.
  2. 서버의 메모리에 이를 저장한다. 이때 세션 식별키인 SessionId를 기준으로 정보를 저장하고 조회할 때도 사용한다.
  3. 서버는 로그인 요청의 응답으로 SessionId를 내어준다. 
  4. 클라이언트는 쿠키에 SeesionId를 담아 앞으로의 요청마다 SeesionId를 같이 보낸다(주로 HTTP header에 담아 보낸다.).
  5. 클라이언트의 요청으로 쿠키를 발견했으면 세션 저장소에서 쿠키를 검증한다. 만약 유저정보를 받아왔다면 클라이언트가 현재 로그인이 되어있다는 것을 알 수 있다.
  6. 이후 로그인된 클라이언트에 따른 응답을 보내준다.
세션 기반 인증방식을 사용하게 되면 사용자로부터 요청(request)을 받을 때, 사용자의 상태를 서버의 메모리에 저장하고 유지한다. 그리고 그 정보를 서비스 제공에 이용한다. (예시 :  로그인을 한 유저만 댓글을 등록할 수 있다.)
이렇게 동작하는 서버를 Stateful Server라고 한다.(이후 Server에서 따로 정리하겠다.)

 

 

 2. 세션의 장단점

 장점

  1. 쿠키에는 SessionId만 나오기 때문에 중요한 정보가 클라이언트 측에 직접적으로 노출되지 않는다.
  2. 쿠키의 용량 제한에 구애받지 않고 클라이언트의 상태를 저장하고 행동을 추적할 수 있다.
  3. 의심 징후가 탐지될 경우 서버 측에서 세션을 강제로 만료시킬 수 있다.

 

단점

  1.  서버의 부하 증가
  2. 서버에 클라이언트의 상태를 저장하기 때문에 분산 환경에서 세션에 대한 정합성을 보장하기 위한 별도의 기술이 필요하다.

 

 

 


 

[출처]https://interconnection.tistory.com/74

 

쿠키와 세션 개념

노션 페이지(아래 내용과 동일) 개요 쿠키와 세션은 개발자 말고도 인터넷 사용자라면 누구나 많이 들어본 단어입니다. 하지만 개념에 대해서는 많은 사람들이 헷갈려 하기에 쉽고 간단하게 정

interconnection.tistory.com

https://devuna.tistory.com/23

 

[web] 쿠키(cookie)와 세션(session)의 개념/차이/용도/작동방식

[web] 쿠키(cookie)와 세션(session)의 개념/차이/용도/작동 쿠키와 세션을 이해하기 위해서는 먼저 http의 특징에 대해 이해하면 도움이 됩니다. 비연결성(Connectionless) HTTP(Hypertext Transfer Protocol)는 인터

devuna.tistory.com

https://btcd.tistory.com/40

 

세션 vs 쿠키 vs 캐시 차이점

ABTCEFG 안녕하세요 여러분! BTC_주먹쥐고 일어서 입니다. IaC로 넘어가기전 기초 탄탄 인프라를 잡는 시간입니다. 다들 IT 멱살 잡고 한걸음 더 나아가 봅시다! 세션 vs 쿠키 vs 캐시 HTTP(상태 비저장

btcd.tistory.com

https://joie-kim.github.io/Session-Auth/

 

Session 기반 인증 방식

배운 것을 기록하는 습관! ✍️

joie-kim.github.io