| 구분 | 설명 |
|---|---|
| 인증 (Authentication) | 사용자의 신원을 확인하는 절차 (로그인 시 아이디/비밀번호 입력) |
| 인가 (Authorization) | 인증된 사용자에게 허용된 권한을 부여하는 절차 (관리자는 글 삭제 가능, 일반 사용자는 불가) |
가장 기본적인 웹 인증 방식이다.
로그인 시 서버가 인증 정보를 담은 쿠키를 클라이언트에게 발급한다.
클라이언트는 매 요청마다 이 쿠키를 자동 전송한다.
서버는 쿠키의 값을 기반으로 인증 여부를 판단한다.
쿠키가 탈취되면 그대로 인증이 뚫린다.
따라서 쿠키에 민감한 정보를 직접 담는 것은 매우 위험하다.
HTTPS 사용은 사실상 필수이다.
쿠키 인증 방식의 보안 문제를 보완한 구조이다.
서버가 사용자 정보를 메모리에 저장한다.
클라이언트는 해당 정보를 가리키는 세션 ID만 쿠키로 저장한다.
요청 시 세션 ID를 보내면 서버가 해당 사용자를 조회해 인증한다.
| 흐름 |
|---|
| 로그인 → 서버 세션 생성 → 세션 ID 발급 → 클라이언트 쿠키 저장 → 요청마다 세션 ID 포함 → 서버가 사용자 확인 |
세션 ID가 탈취되면 인증이 뚫릴 수 있다.
사용자가 많을수록 서버의 메모리 부담이 커진다.
HttpSession session = request.getSession();
session.setAttribute("user", user);
JWT(JSON Web Token) : 가장 널리 사용되는 토큰 기반 인증 방식이다.
로그인 시 서버가 서명된 토큰 문자열을 클라이언트에게 발급한다.
클라이언트는 이 토큰을 저장하고 요청마다 헤더에 담아 전송한다.
서버는 토큰만으로 사용자를 검증한다.
서버는 사용자 상태를 저장하지 않는다. (Stateless)
인증 정보는 토큰 내부에 Base64 인코딩된 형태로 포함된다.
서버는 토큰을 복호화하고 서명을 검증함으로써 인증 여부를 판단한다.
토큰 인증 방식은 단순히 Base64로 인코딩된 문자열일 뿐 암호화된 것이 아니다.
누구든지 토큰을 디코딩하면 내용을 볼 수 있다.
민감한 정보(ID, 주민번호 등)는 절대 토큰에 넣으면 안된다.
| 항목 | 세션 인증 방식 | 토큰 인증 방식 (JWT) |
|---|---|---|
| 상태 | 상태 유지 (Stateful) | 무상태 (Stateless) |
| 서버 저장소 | 세션 메모리 필요 | 저장 불필요 |
| 클라이언트 저장 | 세션 ID (쿠키) | 토큰 (헤더 또는 localStorage) |
| 보안 위협 | 세션 ID 탈취 위험 | 토큰 탈취 시 내용 노출 가능 |
| 확장성 | 서버 메모리 부담 ↑ | 분산 구조, 확장성에 유리 |
| 상황 | 추천 방식 |
|---|---|
| 내부 시스템, 사용자 수 적음 | 세션 인증 방식 |
| 모바일 앱, SPA, 분산 서버 환경 | JWT 기반 토큰 인증 방식 |
+HTTPS 사용은 필수이다.
토큰 만료 시간을 짧게 설정해야 한다.
리프레시 토큰 전략을 함께 사용하면 보안을 강화할 수 있다.
인증: “너 누구야?”
인가: “너 이거 해도 돼?”
인증 방식은 쿠키 → 세션 → 토큰 순으로 발전해왔다.
세션은 서버가 상태를 기억하고, 토큰은 클라이언트가 들고 다닌다.
JWT는 암호화가 아닌 인코딩이므로, 노출되면 내용이 그대로 보일 수 있다.