[본캠프] 인증,인가 와 세션,JWT

인증과 인가를 왜 구분해야 할까?

웹 서비스를 사용하다 보면 사용자는 여러 기능을 요청하게 된다.
예를 들어 회원가입, 로그인, 일정 생성, 일정 수정, 일정 삭제 같은 요청이 있다.
이때 서버는 단순히 요청만 받는 것이 아니라,
사용자가 누구인지, 그리고 “사용자가 이 작업을 해도 되는지”를 구분해서 확인해야 한다

이때 등장하는 개념이 바로 인증(Authentication) 과 인가(Authorization) 이다

인증은 사용자의 신원을 확인하는 과정이다.
인가는 확인된 사용자가 특정 작업을 수행할 권한이 있는지 검사하는 과정이다

즉, 인증과 인가는 비슷해 보이지만 역할이 다르다

1. 인증(Authentication)이란?

인증은 쉽게 말해 누구인지를 확인하는 과정이다

사용자가 로그인 화면에서 이메일과 비밀번호를 입력하면, 서버는 이 정보가 DB에 저장된 사용자 정보와 일치하는지 확인한다
일치하면 서버는 정상적으로 로그인한 사용자다 라고 판단한다

인증의 목적은 사용자를 식별하는 것이다

인증의 예시

• 이메일 + 비밀번호 로그인
• 휴대폰 문자 인증
• 소셜 로그인
• JWT 토큰 검증
• 세션 기반 로그인

인증에서 중요한 점

인증이 성공했다는 것은 단지 누군지 확인되었다 는 뜻
그 사용자가 모든 작업을 할 수 있다는 뜻은 아니다

예(로그인성공시):

• 남의 일정 수정
• 관리자 전용 기능 접근
• 다른 사용자의 정보 삭제

이런 것까지 자동으로 허용되는 것은 아니다
이 부분은 인가에서 검사해야 한다

2. 인가(Authorization)란?

인가는 쉽게 말해 이 작업을 할 수 있는 권한이 있니? 를 확인하는 과정이다

인증이 끝난 사용자라고 해도, 모든 자원에 접근할 수 있는 것은 아니기 때문에
요청한 기능에 대한 권한을 검사해야 한다

인가의 예시

• 로그인한 사용자만 일정 생성 가능
• 작성자 본인만 일정 수정 가능
• 작성자 본인만 일정 삭제 가능
• 관리자만 회원 목록 전체 조회 가능

예:

• 사용자가 로그인한다. → 인증 성공
• 로그인한 사용자가 /schedules/1 수정 요청을 보낸다.
• 서버는 이 일정의 작성자와 현재 로그인한 사용자가 같은지 확인한다.
• 같으면 수정 허용, 다르면 거부

정리

구분	인증(Authentication)	인가(Authorization)
의미	사용자의 신원을 확인	사용자의 권한을 확인
질문	누구야?	해도돼?
대표 예시	로그인	수정/삭제 권한 검사
확인 대상	이메일, 비밀번호, 세션, 토큰	작성자 여부, 관리자 여부
실패 시 대표 상태코드	401 Unauthorized	403 Forbidden

인증 방식이 필요한 이유

사용자가 로그인하면 서버는 인증된 사용자다 라는 사실을 기억해야 한다
하지만 HTTP는 무상태(Stateless) 프로토콜이기 때문에 요청이 끝나면 상태를 기억하지 못한다

이 문제를 해결하기 위해 등장한 방식이

• 세션(Session)
• JWT(Token)

3. 세션

세션 방식은 서버가 로그인 상태를 저장하는 방식이다

동작흐름

1. 로그인 요청 (email, password)
2. 서버에서 사용자 검증
3. 서버가 세션 생성
4. 세션에 사용자 정보 저장
5. JSESSIONID를 쿠키로 클라이언트에 전달
6. 이후 요청마다 쿠키 자동 포함
7. 서버가 세션 조회 → 사용자 식별

• 특징
  서버가 로그인 상태를 기억함
  클라이언트는 단순히 쿠키만 보냄

• 장점
  구현이 간단함
  보안적으로 안정적 (서버에 데이터 있음)
  로그아웃 처리 쉬움 (세션 삭제)

• 단점
  서버 메모리 사용 증가
  서버가 여러 대면 세션 공유 필요 (세션 클러스터링)
  확장성 떨어짐

4.JWT(Json Web Token) 기반 인증

JWT는 서버가 상태를 저장하지 않고, 토큰 자체에 정보를 담는 방식이다

동작흐름

1. 로그인 요청
2. 서버가 사용자 검증
3. JWT 토큰 생성
4. 클라이언트에게 토큰 전달
5. 이후 요청마다 Authorization 헤더에 토큰 포함
6. 서버는 토큰 검증 후 사용자 식별

• JWT 구조
  JWT는 3부분으로 구성됨:
  Header.Payload.Signature
  예:
  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJ1c2VySWQiOjF9 . abc123signature

• 특징
  서버가 상태를 저장하지 않음 (Stateless)
  토큰 자체에 사용자 정보 포함

• 장점
  서버 확장성 좋음 (서버가 상태 안 가짐)
  마이크로서비스 구조에 적합
  모바일/SPA에 적합

• 단점
  토큰 탈취 시 위험
  로그아웃 처리 어려움 (토큰 만료까지 유지됨)
  토큰이 커질 수 있음

정리

구분	세션(Session)	JWT
상태	Stateful (서버 저장)	Stateless (서버 저장 안함)
저장 위치	서버 메모리	클라이언트
전달 방식	쿠키 (JSESSIONID)	Authorization 헤더
확장성	낮음	높음
보안	상대적으로 안전	토큰 탈취 위험
로그아웃	쉬움	어려움