1. 인증/인가

1-1. 인증 (Authentication)

• 해당 유저가 실제 유저인지 인증하는 개념
• 사용자의 신원을 검증하는 프로세스
• ex) Id, Pw 로 로그인 하는 행위

1-2. 인가 (Authorization)

• 인증 이후의 프로세스
• 인증된 유저가 어떠한 자원에 접근할 수 있는지 확인하는 절차
• ex) 관리자 페이지– 관리자 권한

2. 웹 어플리케이션 인증의 특수성

• 일반적으로 서버-클라이언트 구조로 되어있다.
• Http 프로토콜을 이용하여 통신한다.
  ➔ 비연결성(Connectionless), 무상태(Stateless)의 특징을 지닌다.
  

비연결성(Connectionless)

• 서버와 클라이언트가 연결되어 있지 않다.
• 서버와 클라이언트가 계속 연결되어 있다면, 서버의 비용이 기하급수적으로 늘어난다.
• 리소스의 절약을 위해 서버는 하나의 요청에 하나의 응답을 보내고 연결을 끊는다.

무상태(Stateless)

• 서버가 클라이언트의 이전 상태를 저장하지 않는다. 클라이언트가 직전에 무슨 요청을 보냈었는지 알지 못한다.
• 기존의 상태를 저장하는 것은 서버의 비용과 부담을 증가시키기 때문에 기존의 상태가 없다고 가정하는 프로토콜을 구현한다.

사용자 상태를 저장하고 확인할 방법이 필요하다
➔ 대표적인 기술이 쿠키/세션/JWT

3. 쿠키 (Cookie)

클라이언트(브라우저)에 저장되는 작은 데이터 조각

• 서버가 응답 시 Set-Cookie 헤더를 보내면 브라우저가 저장
• 이후 같은 도메인 요청 시 자동으로 쿠키를 Request Header에 포함
• 용도 : 로그인 유지, 사용자 맞춤 설정, 장바구니 정보 등
• 단점
  • 브라우저에 저장 -> 보안 취약 (노출/변조 가능)
  • 데이터 용량 제한 (약 4kb)
  • 요청마다 자동 전송되어 트래픽 증가

4. 세션 (Session)

서버가 사용자 상태를 서버 메모리나 DB에 저장

• 서버는 로그인 시 세션 ID를 생성 ➔ 브라우저에 쿠키 형태로 저장
• 이후 클라이언트 요청 시 JSESSIONID로 세션을 식별
• 특징
  • 실제 인증 정보는 서버에 있음 (보안 ↑)
  • 브라우저가 꺼지면 세션 만료
• 단점

  - 사용자가 많으면 서버 메모리 부담 커짐 (확장성 ↓)
  - 서버 간 세션 공유 어려움 (로드밸런싱 시 문제 발생)

  

5. JWT (Json Web Token)

인증 정보를 토큰 형태로 인코딩해 클라이언트가 직접 보관

• 구조: Header.Payload.Signature

• 동작원리
  1. 로그인 성공 -> 서버가 JWT 발급
  2. 클라이언트는 JWT를 로컬스토리지나 쿠키에 저장
  3. 이후 요청마다 JWT를 Authorization:Bearer <token> 헤더로 전송
  4. 서버는 서명(Signature)검증으로 사용자 확인 (DB 조회x)

• 장점

  • 서버 확장성 뛰어남 (stateless 인증)
  • 다른 도메인 서비스 간 인증 공유 쉬움

• 단점

  • 토큰 크기가 큼 (매 요청 시 부하)
  • 만료 전 탈취 시 보안 위험
  • 중간에 강제 로그아웃 어렵다

  

6. 쿠키 vs 세션 vs JWT

7. 보안 이슈 및 대응

• 쿠키 탈취 -> HttpOnly, Secure, SameSite 옵션 설정
• 세션 하이재킹 -> 세션 만료 시간 설정, HTTPS 필수
• JWT 탈취 -> 짧은 만료 시간 + Refresh Token 필요

8. 실무 적용

• 전통적인 웹 (Spring MVC, JSP) -> 세션 기반 인증
• SPA / 모바일 앱 (React, Vue, Flutter 등) -> JWT 기반 인증
• 하이브리드 구조
  • JWT로 stateless 인증
  • Refresh Token을 DB에 저장해 보안을 보완