인증과 인가, 그리고 JWT까지 완벽 정리

인증(Authentication)과 인가(Authorization), 그리고 JWT

인증(Authentication) vs 인가(Authorization)

• 인증: 사용자가 자신이 누구인지 증명하는 과정
  → 예: 아이디와 비밀번호 입력 후 로그인

• 인가: 인증된 사용자가 특정 자원에 접근 가능한지 판단하는 과정
  → 예: 일반 사용자가 관리자 페이지 접근 시 거부되는 것

• 인가는 역할(Role)과 권한(Permission)을 기준으로 관리됨

---

왜 인증 방식이 필요한가?

HTTP의 특성: 비연결성(Connectionless) + 무상태성(Stateless)

• 각 요청은 독립적으로 처리되며 서버는 이전 요청의 상태를 기억하지 않음
• 사용자의 로그인 상태 유지를 위해 인증 방식이 필요

---

인증 방식 요약: 세션, 쿠키, JWT

1. Session (서버 기반 인증)

• 사용자의 로그인 상태를 서버의 메모리나 DB에 저장
• 요청마다 서버에서 세션을 확인해 인증
• 보안성 높음, 단점: 서버 자원 사용, 확장성 떨어짐

2. Cookie (클라이언트 기반 상태 관리)

• 클라이언트 브라우저에 상태 정보 저장
• 서버는 Set-Cookie를 통해 쿠키 전달 → 이후 요청마다 쿠키 자동 포함
• 서버 자원 부담 ↓, 하지만 보안 이슈 ↑

---

JWT (JSON Web Token)

• JSON 포맷의 토큰으로, 클라이언트와 서버 간 정보 안전 전송에 사용
• 세션/쿠키 없이도 인증 상태 유지 가능

구성 요소

1. Header: 서명 알고리즘 정보 (Base64 인코딩)
2. Payload: 사용자 정보와 클레임 (암호화 X → 민감정보 X)
3. Signature: 위조 방지용 서명 (Header + Payload + Secret Key로 생성)

형식: Header.Payload.Signature

---

로그인과 상태 유지

• 사용자가 로그인하면 서버는 AccessToken과 RefreshToken을 발급
• 클라이언트는 이를 로컬스토리지/쿠키 등에 저장
• 이후 요청 시 AccessToken으로 인증, 만료되면 RefreshToken으로 재발급

---

Session vs Token(JWT)

항목	Session 방식	JWT 방식
저장 위치	서버 (메모리/DB)	클라이언트 (토큰 보관)
확장성	낮음	높음
보안성	높음 (서버 제어)	페이로드 유출 가능성
인증 처리	서버에서 세션 조회	토큰 검증만 수행

---

정리

• 인증: 본인 확인 → 로그인
• 인가: 권한 확인 → 기능 사용 가능 여부
• 세션/쿠키는 상태 유지 수단, JWT는 토큰 기반 인증 수단
• JWT는 확장성, 편리함은 뛰어나지만 보안 설계가 필수

---

✍ 추천 사용 시나리오

• 세션 방식: 내부 시스템, 보안 우선 서비스
• JWT 방식: 모바일/SPA/마이크로서비스 기반 API