인증
왜 계속 로그인 상태로 남을까. 세션과 JWT.
한눈에
- 인증(authentication) = 너 누구냐 (로그인, 클럽 입구 신분증)
- 인가(authorization) = 너 이거 해도 되냐 (권한, VIP룸 팔찌 색)
- 세션 = 서버가 명단을 든다 (손님은 번호표=세션ID, 강제 로그아웃 쉬움·서버 부담)
- JWT = 서명된 위조 방지 팔찌를 내가 차고 다닌다 (서버 무상태·확장 쉬움·회수 어려움)
- HttpSession·JSESSIONID = 세션 방식 그 자체 (Spring이 명단·번호표 대신 관리)
- HTTP는 무상태 = 요청 끝나면 나를 잊음 (그래서 세션·JWT로 기억 유지)
로그인은 한 번 하는데, 그다음부터는 페이지를 옮겨다녀도 계속 "로그인된 나"로 남는다. 그런데 HTTP는 원래 요청 하나가 끝나면 나를 까맣게 잊는 성격이다(무상태). 그런데도 어떻게 계속 기억할까. 이 **"기억하는 방법"**이 인증 유지고, 크게 두 갈래다. 서버가 명단을 들고 기억하는 세션, 내가 증표를 차고 다니는 JWT.
인증과 인가부터
먼저 자주 뭉뚱그려지는 두 단어를 갈라야 한다.
- **인증(authentication)**은 "너 누구냐"다 — 로그인. 이 사람이 정말 본인이 맞는지 확인하는 것.
- **인가(authorization)**는 "너 이거 해도 되냐"다 — 권한. 로그인은 됐는데, 관리자 페이지에 들어갈 자격이 있는지.
클럽으로 치면 인증은 입구에서 신분증 보고 들여보내는 것, 인가는 VIP룸 앞에서 팔찌 색을 보고 통과시킬지 정하는 것이다. 이 노트가 주로 다루는 세션과 JWT는 인증을 어떻게 유지하느냐의 이야기다.
세션, 서버가 명단을 든다
세션은 클럽 입장자 명단이다. 손님은 번호표만 들고 다니고, 진짜 정보는 서버가 명단에 적어 보관한다.
로그인에 성공하면 서버가 명단에 "3번 = 홍길동"이라 적고, 손님에게는 "3번"이라는 번호표(세션 ID)를 쿠키로 쥐여준다. 이후 요청마다 브라우저가 이 번호표를 자동으로 딸려 보내면, 서버는 명단을 뒤져 "아, 3번, 홍길동이군" 하고 알아본다.
장점은 통제가 쉽다는 것. 강제 로그아웃이 필요하면 명단에서 그 줄을 지우면 끝이다. 단점은 서버 부담이다. 손님이 많으면 명단이 커지고, 서버를 여러 대로 늘리면 그 명단을 어떻게 공유할지가 골칫거리가 된다.
JWT, 내가 증표를 차고 다닌다
JWT(JSON Web Token)는 위조 방지 팔찌다. 정보를 팔찌 자체에 적고, 서버가 서명(위조 방지 홀로그램)을 박아 손님에게 채워준다. 서버는 명단을 따로 안 쓴다.
로그인에 성공하면 "홍길동, 일반 등급"이라 적힌 팔찌에 서버 도장(서명)을 찍어 손님에게 준다. 이후 요청마다 손님이 팔찌를 보여주면, 서버는 명단을 뒤질 것도 없이 도장이 진짜인지만 확인한다. 진짜면 통과.
장점은 서버가 아무것도 기억하지 않아도 된다는 것 — 그래서 서버를 여러 대로 늘리기 쉽다(확장성). 단점은 한 번 채워준 팔찌는 회수가 어렵다는 것. 만료 전까지는 계속 유효하고, 뺏기면 그대로 위험하다. 그래서 실무에선 수명을 짧게 주고 갱신용 토큰(refresh)과 짝지어 쓴다.
Java 하던 사람 기준 다리
Spring으로 웹을 짜봤다면 이미 손으로 만져본 것들이다. 이름만 바꿔 대응시키면 된다.
특히 HttpSession과 JSESSIONID는 세션 방식 그 자체다. Spring이 뒤에서 명단을 관리하고 번호표 쿠키를 자동으로 붙여줬을 뿐, 원리는 위의 "클럽 명단"과 똑같다. JWT로 넘어갈 때 헷갈리는 지점도 바로 여기다 — 서버가 더 이상 명단을 들지 않으니, HttpSession에 뭘 담아두던 습관을 내려놓아야 한다.
우리 프로젝트에선
내 프로젝트에도 두 결이 다 보인다. **새김 AI**는 Firebase 인증을 쓴다 — 로그인과 토큰 발급·검증을 Firebase가 대신 맡아주는 방식이라, 위의 JWT 계열에 가깝다(서명된 토큰을 발급하고 그 진위를 검증한다).
지금 읽는 이 0to1 블로그의 관리자(Pages CMS)는 GitHub OAuth로 로그인한다 — "GitHub 계정으로 로그인" 버튼을 눌러, GitHub이 대신 신분을 보증해주는 것. 두 경우의 공통점은 인증을 직접 짜지 않고 검증된 서비스에 맡겼다는 점이다. 인증은 한 번 틀리면 바로 사고라, 바퀴를 새로 깎기보다 검증된 걸 얹는 게 정석에 가깝다.
더 읽기
인증·인가 개념부터 세션·JWT의 장단까지 정리해둔 글들. 하나씩 짚으면 그림이 맞는다.
- 세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가) — hudi.blog — 인증/인가 구분부터 두 방식의 장단까지 차분하게
- 세션 VS. 토큰! JWT가 뭔가요? — 얄코 — 그림과 비유로 세션·JWT를 초보 눈높이로
- 세션 기반 인증 vs JWT 기반 인증 — velog — 동작 원리와 장단점을 항목별로 정리