Spring의 Session, 인증(Authentication)과 인가(Authorization)- JWT , 공통 관심 사항 - Servlet Filter

말하는 감자·2025년 3월 28일

Spring 내배캠 내일배움캠프

내일배움캠프

목록 보기

31/73

@SessionAttribute

기존 자바에서 세션을 사용하는 경우
request.getSession(true);와는 다르게 Session을 새로 생성하는 기능은 없다.

📌request.getSession(true);

true : 존재하는 세션이 없는 경우 새로운 세션을 만들어서 반환해줌
false : 존재하는 세션이 있는 경우만 있는 세션을 반환해줌

그러니 세션이 있는 경우에만 사용이 가능하다.

강의에서는 처음 로그인 할 때
get으로 JSSESSIONID=값을 url뒤에 붙여서 받아왔다.
내부적으로 Set-Cookie로 SessionID와 값을 넣어주기 때문에 해당 값이 필요가 없어진다.

get으로 JSSESSIONID=값 이 방법은

Cookie를 지원하지 않으면 URL을 통해 Session을 유지하는 방법에 사용된다.
- 하지만, 사용하려면 모든 요청 URL에 jsessionId값이 전달 되어야한다.

근데 우리는 로그인만 했지 JSSESSIONID는 어디서 나온걸까?
📌 Template Engine을 사용하면 jsessionId를 URL에 자동으로 포함한다.

url에 JSSESSIONID 노출이 싫다!!! 쿠키로만 id 주고받기

application.properties > server.servlet.session.tracking-modes=cookie 추가!!
해당 속성의 의미는 cookie로만 세션을 조회하겠다라는 뜻

postman으로 로그인하기

실제로 로그인을 하는 함수에 맞게 값을 준다...
근데 같은 @ModelAttribute인데 form-data랑 x-www-form-urlencoded랑 뭔차이지

여튼 정상적으로 로그인된거 확인 하면

다음 요청부터 헤더에 JSSESSIONID가 생긴다

세션에 기본으로 들어가 있는 정보들

session 정보
1. session.getId();
  - jsessionId 값을 조회할 수 있다.
2. session.getMaxInactiveInterval();
  - 세션의 유효시간
  - second 단위 default는 30분(1800초)이다.
3. session.getCreationTime();
  - 세션 생성시간
4. 🥪session.getLastAccessedTime();
  - 해당 세션에 마지막으로 접근한 시간
5. session.isNew();
  - 새로 생성된 세션인지 여부

4번빼고는 거의 값 변경이 없다

세션이 마냥 좋은가

Session은 logout 기능을 사용하여 session.invalidate();가 되어야 삭제되지만
대부분의 사용자들은 로그아웃을 굳이 하지않고, 브라우저를 종료한다.

나도 생각해보면 로그아웃 안누르고 그냥 창닫기 할떄가 종종...아니많음

그 외에도 여러 문제점이있다.

- JSESSIONID의 값을 탈취 당한 경우 해당 값으로 악의적인 요청을 할 수 있다.
- 세션은 서버 메모리에 생성되고 자원은 한정적이기 때문에 꼭 필요한 경우만 생성해야 한다.
(DoS같은 공격이나 사용자가 멀리면 서버가 펑~)

문제의 해결 방안

서버에 최근 Session을 요청한 시간을 기준으로 30분을 유지
Session 정보에서 LastAccessedTime 을 기준으로 30분이 지나면 WAS가 내부적으로 세션을 삭제한다.

완벽하게 악의적인 공격은 막기 어렵겠지만 30분 방치하면 다시 그 ID르 ㄹ사용할 수 없겠쥐

- 서버가 DB 혹은 메모리에 저장된 세션 정보를 매번 조회하여 오버헤드가 발생한다.
- 서버가 상태를 유지해야 하므로 사용자 수가 많아질수록 부담이 커진다.
- Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증을 처리할 수 없다.
- Scale Out(수평적 확장)에서 서버간 세션 공유가 어렵다.

수평적 확장

서버를 수평적으로 여러개 생성해서 관리한다
서버와 클라이언트 사이에 로드밸런서를 배치하고, 이 로드밸런서가 클라이언트-서버 매칭을 해준다.
로드밸런서를 한 서버에 트래픽이 몰리는 것을 방지하기 때문에
같은 사용자가 항상 같은 서버를 이용하는 것을 보장하지 않음
게다가 세션은 서버 안에 저장되다보니 세션 공유가 어렵다.

🔍정리

세션(Session)
- 용도
  - 로그인 정보, 사용자 활동 등을 서버 측에서 관리.
- 특징
  - 서버 측에서 저장되며, 세션 ID가 쿠키에 저장되어 클라이언트와 연결됨.
- 수명
  - 브라우저를 닫거나 일정 시간이 지나면 만료됨.
- 🥪Session 관리
  1. 세션은 메모리를 사용한다.
    - 세션이 많아지면 서버의 장애가 발생할 수 있다.(메모리 리소스 부족)
    - 최소한의 데이터만 저장해야 한다.
  2. HttpSession은 LastAccessedTime을 기준으로 30분의 생명주기를 가지고 있다.
  3. 세션의 시간을 너무 오래 유지하여도 메모리 리소스가 부족할 수 있다.
    - 적당한 시간 설정이 꼭 필요하다.(Default 30분)

인증(Authentication)과 인가(Authorization)

인증(Authentication)
- 사용자가 누구인지 확인하는 과정
ex) 로그인
인가(Authorization)
- 사용자가 어떤 권한을 가지고 있는지 결정하는 과정
- 반드시 인증이 선행되어야 한다.
ex) 회원만 조회 가능한 게시글, 본인이 작성한 게시글 수정

❓ 세션은 인증/인가 기능 하는거아닌가?

여기서 궁금한게 생겨서 지피티에게 물어봤다..

앞에는 세션과 토큰의 개념 설명해주고 특징들을 짚었는데 게시글 위아래로 그 내용이 있어서 제외하고
서로비교하는 표만 가져와봤다
어찌보면 세션도 인증 역할으 ㄹ하지만 인가는 추가 구현이 필요하다고함..
JWT가 토큰의 종류중에 하나구나

Token

🧀 Web Application이나 API에서 인증(Authentication)과 인가(Authorization) 과정에서 사용되며 사용자 또는 시스템의 신원과 권한을 증명하고 요청의 유효성을 검증하는 데 사용되는 디지털 문자열

역할: 인증/인가를 수행하기 위한 자체 포함(self-contained) 데이터 패키지.
- 사용자가 인증되었음을 입증하는 정보(서명)가 포함되어 있다.
- 겁나 큰 특징 : 서명이 포함되어 있어서 위조된 요청인지 판단 가능
저장소: 보통 클라이언트가 토큰을 보관하며, 각 요청마다 이를 서버에 포함해서 보냄
사용 목적: 토큰은 stateless(무상태)한 인증 방식에 사용.
서버는 클라이언트가 보낸 토큰을 검증함으로써 해당 요청이 유효한지 판단합니다.

<동작 방식>

이처럼 사용자의 인가를 데이터 베이스 접근 없이 검증할 수 있어서 오버헤드가 발생하지 않는다.

Token의 단점
1. Cookie/Session 방식보다 Token 자체의 데이터 용량이 많다.
  - 사용자 정보도 토큰에 포함되고 있기 때문!!
    - 요청이 많아지면 그만큼 트래픽이 증가한다.
2. Payload(전송되는 데이터)는 암호화되지 않아서 중요한 데이터를 담을 수 없다.
  - 토큰을 써도 중요한 정보를 보관할 수 없는 문제가 생긴다.
3. Token을 탈취당하면 대처하기 어려워 만료 시간(30분)을 설정한다.

JWT(JSON Web Token)

🍕 인증에 필요한 정보들을 암호화시킨 JSON 형태의 Token을 의미한다. JSON 데이터 포맷을 사용하여 정보를 효율적으로 저장하고 암호화로 서버의 보안성을 높였다.

자동으로 JWT를 Encoding / Decoding 해주는 사이트

💡 base64UrlEncode는 값을 URL에서 사용할 수 있도록 +, /를 각각 -, _로 표기한다.
-> base64 인코딩은 언제든지 복호화할 수 있어서 민감한 정보 절대 ❌❌❌

💡 Header와 Payload는 Encoding된 값이기 때문에 복호화 혹은 값을 수정할 수 있지만 Signature는 서버에서 관리하는 값이기 때문에 Secret Key가 유출되지 않는 이상 복호화 할 수 없다.

🥞Secret Key 관리가 매우매우매우매우매우매우매우매우매우 중요

JWT의 흐름

1️⃣ 로그인
사용자가 ID/PW로 로그인 요청
→ 서버는 사용자를 검증하고 JWT를 발급
→ 로그인에 성공했다면 Header, Payload에 Secret Key를 사용하여 Signature를 만든다.
→→ 이후 Base64로 Encoding + Cookie에 담아 클라이언트에게 JWT를 발급

2️⃣ JWT 저장
클라이언트(웹/앱)는 JWT를 저장

브라우저 : 로컬 스토리지 / 쿠키
모바일 앱 : Secure Storage

3️⃣ 요청 시 JWT 포함
클라이언트는 요청할 때 JWT를 HTTP 헤더에 포함하여 전송
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

4️⃣서버에서 JWT 검증
서버는 JWT의 서명을 확인하고, JWT 만료/위변조 여부를 검사한다.
✔ 유효하면 → 요청 정상 처리
✔ 만료되었거나 위조되었다면 → 401 Unauthorized 반환

📌JWT의 유효성 검사

Header, Payload를 서버의 Secret Key값을 이용해 Signature를 다시 만들어 비교한다.

Signature의 값 = Secret Key * (Header + Payload )
→만약에 중간에 탈취 당해서 Payload 값이 바뀌면 위조 된 것이라고 판별할 수 있다

따라서,

💡 JSON Web Token의 목적은 정보 보호가 아닌, 위조 방지에 있다.

JWT의 장단점

✅ 장점
✔ Signature로 서버의 보안성이 증가한다.
✔ Stateless (서버가 세션 저장 X) → 서버의 수평 확장성(Scale Out)이 높아진다.
✔ 서버에서 별도의 인증을 위한 저장을 하지 않아도 됨 (DB 조회 ❌, 저장소 사용 ❌)
✔ Cookie가 없는 다른 환경에서도 인증/인가를 적용할 수 있다.

❌ 단점
✔ Payload가 누구에게나 노출됨 (Base64 디코딩 가능) → 민감 정보 X
✔ 클라이언트 측에서 Token을 관리하기 때문에 탈취당하면 대처하기 어렵다. → 토큰에도 만료시간을 설정
✔ 토근형식이라 JWT 크기가 커서 네트워크 비용이 증가할 수 있음

이처럼, Token은 클라이언트에서 관리하여 탈취당할 위험성이 높기 때문에 만료 시간 설정이 필요하다.
이 때 발생하는 단점을 극복하기 위해 Access Token과 Refresh Token을 사용한다.

Token의 유형

Access Token
- Access Token은 보안을 위해 짧은 수명(30분~)을 가진다.
- 사용자 인증 후 서버가 발급하는 유저 정보가 담긴 토큰이다.
- 유효 기간 동안 API나 리소스에 접근할 때 사용한다.
Refresh Token
- Access Token이 만료된 경우 재발급 받기위해 사용한다.
  - Access Toke보다 수명이 길다 ( 1주일~ )
- 주로 데이터베이스에 유저 정보와 같이 저장한다.

✅ Access Token vs Refresh Token

📌 요약
✔ Access Token : API 요청 시 사용자 인증에 사용, 만료되면 Refresh Token으로 재발급
✔ Refresh Token : Access Token이 만료되었을 때 새로운 Access Token을 발급하는 용도로 사용
✔ 보안 고려 : Access Token은 자주 갱신되고, Refresh Token은 안전한 저장소에서 관리해야 함!!

공통 관심 사항을 처리하기 위한 서블릿 필터(Servlet Filter)

공통 관심 사항

같은 말로 횡단 관심사 라고 하며 여러 위치에서 공통적으로 사용되는 부가 기능이다!!!!

부가 기능

이거 교제 얘기하자마자 아 스프링 AOP 내용이구나 딱 왔다.
근데 강ㅇ의 들어보면 AOP랑 필터랑 또 다른 개념?? 그런느낌인 것 같은데 나중에 또 지선생의 도움을 받아야 겠다..
핵심기능은 이제 진짜 서비스하는 내용이고 디비 접근하는 등등 주 서비스 관련된 기능임
부가기능은 그거랑 별개로 로깅이나 보안같은 모든 핵심기능에서 사용되지만 주 서비스는 아닌 것들임

만약에 이렇게 핵심기능 안의 공통관심사인 부가기능에 대한 수정이 필요할 경우
해당 부가기능(로직)을 사용하는 메소드 를 모두 고쳐주어야 하는데,
이 해결 방법으로 Spring AOP , Servlet Filter나 Spring Intercepter를 사용한다.

이번에는 Servlet Filter에 대해서 ARABOJA

Servlet Filter

Servlet Filter는 보안, 로깅, 인코딩, 인증/인가 등 다양한 작업을 처리하기 위해 사용된다.

특징

✔ 공통 관심사 처리로 코드 중복 제거 및 유지보수 용이 ( 재사용성 ▲ )

모든 요청이 하나의 입구를 통해 처리되어 일관성을 유지한다.

✔ HTTP 요청/응답을 가로채어 변환, 검증, 로깅, 보안 설정 가능

✔ 체인 방식(Filter Chain)으로 여러 필터 순차 적용 가능

ilterChain.doFilter(request, response); 호출 시 다음 필터로 제어가 넘어감.

🔍 필터의 체인 방식 필터 체인 방식 이미지

Filter는 Chain 형식으로 구성된다.
Filter는 개발자가 자유롭게 추가할 수 있다.
Filter는 순서를 지정하여 추가할 수 있다.

✔ doFilter() 에서 다음 필터 또는 서블릿 실행을 결정 (※ 완전 중요)

doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
실제 필터링 작업을 수행하는 주요 메소드로 필터가 처리할 작업을 정의한다.
다음 필터로 제어를 넘길지 여부를 결정한다. ( 서블릿 필터에서 가장 중요한 역할을 담당함 )

자바에서는 필터를 구현할 수 있도록 서블릿 필터 인터페이스 제공중
=> 인터페이스이기 때문에 직접 내용은 구현해야 한다!!

주요 메서드

public class CustomFilter implements Filter {

📌 이거 Filter 관련된 라이브러리 임포트할때 항상 jakarta.servlet 을 임포트 해야함!!!

1️⃣ init()

default method이기 때문에 implements 후 구현하지 않아도 된다.

2️⃣ doFilter()
3️⃣ destroy()

필터 생성

필터 등록

사용해보면 알겠지만 서블릿 가기전에 필터를 거치기 때문에 url오류같은게 떠서 404를 반환하더라도 filter를 거침

Filter를 등록하는 방법은 여러가지가 있다.
- SpringBoot의 경우 FilterRegistrationBean 을 사용한다.

💡 @WebFilter 어노테이션은 필터 등록이 가능하지만 순서 조절이 안되니 잘 사용하지 않는다.

❓ 사용자 지정 필터 만들때 setOrder에 0번을 쓰지않는 이유가있니?

강의에서 사용자 지정 필터를 만들 때 1번부터 사용했었다.
이유가 뭐지 싶었는데 마지막에 Spring Security에 대해서 언급이 나온다.

Spring Security는 여러 개의 필터를 체인(Filter Chain)으로 실행하며, 각 필터는 특정한 보안 기능을 담당한다.

위에 들어간 필터 이름은 클래스 이름이다
따라서 원한다면 확장해서 사용가능함...

public class UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter {

이처럼 필터들은 강의에서 한 것 같이
직접 Filter 인터페이스를 구현하거나, Spring Security가 제공하는 필터 클래스를 상속받아서 사용 할 수 있음.

말하는 감자

대충 데굴데굴 굴러가는 개발?자

이전 포스트

객체 지향 설계에 대해서

다음 포스트

Spring의 Session, 인증(Authentication)과 인가(Authorization)- JWT , 공통 관심 사항 - Servlet Filter

내일배움캠프

@SessionAttribute

📌`request.getSession(true);`

url에 JSSESSIONID 노출이 싫다!!! 쿠키로만 id 주고받기

postman으로 로그인하기

세션에 기본으로 들어가 있는 정보들

세션이 마냥 좋은가

문제의 해결 방안

수평적 확장

🔍정리

인증(Authentication)과 인가(Authorization)

❓ 세션은 인증/인가 기능 하는거아닌가?

Token

JWT(JSON Web Token)

JWT의 흐름

📌JWT의 유효성 검사

💡 JSON Web Token의 목적은 정보 보호가 아닌, 위조 방지에 있다.

JWT의 장단점

Token의 유형

✅ Access Token vs Refresh Token

공통 관심 사항

부가 기능

Servlet Filter

특징

주요 메서드

필터 생성

필터 등록

❓ 사용자 지정 필터 만들때 setOrder에 0번을 쓰지않는 이유가있니?

객체 지향 설계에 대해서

Spring JPA 기본 개념

0개의 댓글

Spring의 Session, 인증(Authentication)과 인가(Authorization)- JWT , 공통 관심 사항 - Servlet Filter

내일배움캠프

@SessionAttribute

📌request.getSession(true);

url에 JSSESSIONID 노출이 싫다!!! 쿠키로만 id 주고받기

postman으로 로그인하기

세션에 기본으로 들어가 있는 정보들

세션이 마냥 좋은가

문제의 해결 방안

수평적 확장

🔍정리

인증(Authentication)과 인가(Authorization)

❓ 세션은 인증/인가 기능 하는거아닌가?

Token

JWT(JSON Web Token)

JWT의 흐름

📌JWT의 유효성 검사

💡 JSON Web Token의 목적은 정보 보호가 아닌, 위조 방지에 있다.

JWT의 장단점

Token의 유형

✅ Access Token vs Refresh Token

공통 관심 사항

부가 기능

Servlet Filter

특징

주요 메서드

필터 생성

필터 등록

❓ 사용자 지정 필터 만들때 setOrder에 0번을 쓰지않는 이유가있니?

객체 지향 설계에 대해서

Spring JPA 기본 개념

0개의 댓글

📌`request.getSession(true);`