[TIL] Spring Security에 JWT 필터 추가하기

오늘 포스팅에서는 spring security 모듈을 적용하고 그 안에 JWT 인증 필터를 추가하여 JWT토큰으로 인증을 구현해 본 내용을 포스팅하겠습니다.

 

 

spring security는 front-end 팀원분과 개인 공부를 위해

 

기본적인 crud와 회원가입 및 로그인 인증이 구현된 간단한 게시물 웹사이트를 만들기 위해 공부했습니다.

---

Spring Security

spring security 디펜던시를 추가해보면 6.1 버전이 23년 6월에 종료되어서 새로 코드에 대해 이해를 해야 했습니다.

 

먼저 spring security 자체가 어떻게 작동하는지 공부하고 이를 어떻게 커스터마이징 해야 할지부터 고민했습니다.

 

 

spring security 디펜던시를 적용하지 않더라도 spring framework 자체에는 sevlet filterChain이 존재합니다.

 

이 곳에서 수많은 올바르지 않은 request들을 걸러주고, CORS , CRSF 등과 같은 기본적인 보안들이 의존성 주입되어 책임지도록 보장되어 있습니다.

 

spring security를 추가하면 DelegatingFilterProxy에 security Filter Chain 묶음이 추가됩니다.

 

이 filter는 예전에는 기본적인 Security Filter에 대한 Interface가 제공되어 편하게 가져와 사용했지만,

 

Spring에서 이를 변경하여 직접 customizing해서 사용하도록 변경하였습니다.

 

그래서 저는 Bean 어노테이션으로 spring container에 security filter chain 를 추가하기 위해 의존성 주입 코드를 추가했습니다.

 

 

.csrf()는 Customizer로 커스터마이징 하니까 작동하지 않아서 일단 disable한 상태입니다.

 

front-end와 협업하면서 가장 늦게 발생한 CORS 문제를 해결하기 위해, Cors를 customizing 했습니다.

 

CORS는 cross-origin에 대한 데이터를 제한하는 제한 방침으로서, 내가 localhost로 돌린다면, 나의 Origin은 localhost가 됩니다.

 

 

그래서 frontend가 본인의 localhost에서 제 인스턴스에 올라온 이 WAS 서버에 요청을 보낸다면 CORS의 제한을 확인하고 클라이언트 단에서 Deny 시킵니다.

 

따라서 제 WAS 서버에서 localhost:3000번을 origin으로 가진 서버에서 요청을 보낼 시 CORS를 허용해주도록 설정했습니다.

 

처음엔 여기 저기서 찾아본 방법을 찾아봤으나 CORS문제를 해결하지 못했습니다.

 

 

Spring Security의 CORS 문서를 읽어보니 CORS는 pre-flight 통신 순서에서는 쿠키가 없기 때문에, spring security의 filter보다 먼저 수행되어야 한다고 되어있습니다.

 

따라서 SpringSecurity에서는 disable()로 끄면서, cors설정을 따로 의존성 주입을 수행하는 것을 권장하고 있습니다.

 

허용을 할때는 마냥 "*" 를 통해서 전체 허용을 하는 코드들이 많이 돌아다니는 듯 한데,

 

현재는 저도 테스트용으로 코드를 작성한 것이기 때문에 header와 Methods를 전체 허용했지만, 프로젝트가 좀더 본격적으로 수행되고,

 

front-end도 Nginx에 묶인 서버로 돌아간다면 해당 Nginx 서버만 Origin을 허용한다던지의 다른 고려가 필요할 것 같습니다.

 

 

CORS를 허용한 코드 이후에는 인증절차가 필요한 API 범위를 설정해줬습니다.

 

login과 회원가입을 제외한 모든 API는 우리 서비스의 CRUD를 직접적으로 제어할 수 있는 API 이기에 인증 여부를 확인하도록 했습니다.

 

그 이후 JWT 토큰을 사용할 것이기 때문에 Stateless로 state를 설정했고,

 

마지막으로 customizing한 jwtfilter를 사용자의 인증을 확인하는 UsernamePasswordAuthenticationFilter 이전에 삽입했습니다.

 

만약 인증이 되면 UsernamePasswordAuthenticationFilter에서는 인증 여부를 확인하지 않고 바로 넘어가도록 되어있기 때문에 이때 인증을 확인하도록 했습니다.

 

 

 

참고로 @Configuration 어노테이션을 해당 SecurityConfig 클래스에 추가하지 않으면 @Bean 어노테이션을 스프링이 수행하지 않습니다.

 

해당 Bean을 읽게 하려면 반드시 Configuration을 추가해야 합니다.

 

 

JWT 토큰 발급 및 인증 절차

 

 

다음으로 중요한 TokenProvider Class입니다.

 

해당 클래스에서는 token을 생성하면서 동시에 decoding 절차를 통해 해당 token이 올바른지 확인하도록 하는 Dependency를 활용했습니다.

 

해당 dependency는 

 

 

이를 활용했습니다.

 

로그인 인증 절차는 api service 로직에서 올바른 회원인지를 확인하고 token을 발급해 주어야 합니다.

 

access 토큰을 생성해주는 메소드

 

refresh 토큰을 생성해주는 메소드

 

해당 클라이언트에서는 front-end에서 스토리지에 access token을 저장해뒀다가 매번 api를 요청할 때,

 

header에 access 토큰을 추가해서 요청하도록 합니다.

 

그리고 만약 access 토큰이 만료되어 403 deny된다면 refreshToken을 헤더에 추가하여 재 요청합니다.

 

그러면 refresh를 인식하여 spring filter에서는 새로운 new access token을 발급하도록 구현했습니다.

 

try-catch문으로 만약 만료된 토큰에 의한 예외처리는 reissue Access Token을 통해 refresh를 확인하도록 구현

reissue AccessToken에서 Refresh-Token 헤더를 해독하는 모습

저는 refresh가 올바른 토큰인지 확인하기 위해 DB에 refreshToken을 기억하도록 했습니다.

 

이 방식이 완전히 stateless한 모습은 아니지만, refresh 토큰이 올바른지 확인하기 위해서는

 

1. 만료된 토큰의 해독된 사용자 정보

2. refresh 토큰의 해독된 사용자 정보

3. DB 서버에 기억된 사용자 토큰

 

이 세가지가 모두 일치하도록 하여 보완을 강화해보고자 했습니다.

 

이 세가지가 모두 같은 사용자를 가리킨다면 올바른 토큰으로 판단하여 'SecurityContextHolder'에 현재 인증된 유저의 권한이 부여됬음을 표시하기 위해 'getContext().setAuthentication(authenticated)' 코드를 수행합니다.

 

해독하는 코드는 다음에서 수행합니다.

Jwts class는 jwt 디펜던시에서 제공하는데, 이 내부 인터페이스 메소드인 parseClaimsJwt에서 해당 token을 해독합니다.

 

이 부분에서 토큰을 해독하면서 해당 토큰이 만료되었는지, 토큰을 생성했을 때와 같이 성공적으로 해독되었는지, 올바른 토큰인지에 대한 예외처리를 모두 수행해줍니다.

 

나머지 내부 메소드들은 "Bearer "을 파싱해주거나 토큰의 유저 정보를 담고 있는 "Sub" 키에 대한 값을 비교하는 코드들입니다.

 

---

 

회고

이번 2주동안 스프링에 대해 정말 깊이있게 공부할 수 있어서 매우 좋았습니다.

 

특히 Spring 공식 문서를 읽으면서 Spring security를 공부한 경험은 되게 의미있었던 것 같습니다.

 

그리고 JWT의 refreshToken을 front-end와 협업할 때,

 

로컬 스토리지에 저장하면 보안적으로 위험하다는 사실을 알게되어 refresh token을 어디에 두어야 할지 고민해봐야 할 것 같습니다.

 

그리고 빠른 인증 처리를 위해 서버의 캐시를 활용하여 refresh가 올바른지 확인하는 방법 등, 개선 가능한 측면을 생각해보면서 앞의 5주동안 수행할 나만무 프로젝트에서 보완해 나가야 할 것 같습니다.