JWT 공부를 시작했을 때 JWT를 왜 사용하는지를 한동안 고민에 잠겼고 결론에 대해서 정리하고 싶어서 작성하게 되었다.
JWT의 STATELESS 상태에 대한 집착
@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {
private final CustomUserDetailsService customUserDetailsService; // 기본 세션 로그인
private final CustomOauth2UserService customOAuth2UserService; // OAuth2 등록
// AuthenticationManager가 인자로 받을 AuthenticationConfiguraion 객체 생성자 주입
private final AuthenticationConfiguration authenticationConfiguration;
private final JWTUtil jwtUtil; //JWTUtil 주입
// AuthenticationManager Bean 등록
// AuthenticationConfiguration 인자를 또 받기 때문에 주입
@Bean
public AuthenticationManager authenticationManager(AuthenticationConfiguration configuration) throws Exception {
return configuration.getAuthenticationManager();
}
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests(authorize -> authorize
.requestMatchers("/login", "/", "/join").permitAll()
.requestMatchers("/admin").hasAuthority("ADMIN")
.anyRequest().authenticated()
)
.formLogin(form -> form.disable())
.httpBasic(auth -> auth.disable())
.sessionManagement(session -> session // jwt 방식에서는 session --> STATELESS
.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
.userDetailsService(customUserDetailsService)
.csrf(csrf -> csrf.disable())
// --> 우리는 formLogin 을 disable 해놨기 때문에 UsernamePasswordAuthenticationFilter 을 직접 커스텀 해야한다.
.addFilterBefore(new JWTFilter(jwtUtil), LoginFilter.class)
.addFilterAt(new LoginFilter(authenticationManager(authenticationConfiguration), jwtUtil), UsernamePasswordAuthenticationFilter.class)
.cors(httpSecurityCorsConfigurer -> httpSecurityCorsConfigurer.configurationSource(configurationSource())
);
return http.build();
}
@Bean
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder();
}
@Bean
public CorsConfigurationSource configurationSource(){
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOrigin("*");
config.addAllowedHeader("*");
config.addAllowedMethod("*");
config.setAllowedMethods(List.of("GET","POST","DELETE"));
source.registerCorsConfiguration("/**",config);
return source;
}
}
위의 시큐리티 JWT config를 구성한 코드를 보면
SessionCreationPolicy.STATELESS 상태가 등장하는 것을 볼 수 있다.
그래서 나는 이 STATELESS 상태에 초점이 맞추어 생각을 했다. --> JWT 구현을 위해 STATELESS 상태가 필요하지만 STATELESS에 초점을 잡고 생각을 하니 문제가 많아졌다. --> 아래를 읽다보면 왜 문제인지 알 수 잇을 것이다.
문제 상황
일단 기본적으로 JWT를 사용하면 토큰 탈취의 문제로 기존 Access 토큰과 함께 Refresh 토큰의 도입을 이야기한다.
따라서 Refresh, Access라는 2가지의 토큰을 발급해주는데, Refresh 토큰 요청는 Access 토큰 만료보다 주기 자체가 길기 때문에 탈취 당할 확률은 낮다고는 하지만 어찌되었든 탈취 당할 수 있다.
그래서 이 탈취 당할 확률을 방지하기 위해 서버측에서 어떠한 방법을 구현해야 하는데 이 부분에 대해서 많은 고민을 했다.
레디스, 데이터베이스의 도입
만약, 토큰이 탈취 되었을때 서버의 제어권과 로그아웃 문제 등 을 생각해보자.
일단 토큰이 탈취되면 토큰의 만료 기간 까지 서버측은 고통을 받을 것이다.
따라서 아예 서버를 꺼버리거나 서버 비밀키를 변경하는 상황까지 가는 불상사가 발생할 것이다.
혹은 프론트 서버측 로그아웃을 구현할 수도 있는데 이때 이미 해커가 토큰을 복제 했다면 해커는 그 토큰을 가지고 계속 서버에 접속할 수 있기 때문에 여전히 문제가 있다.
그래서 서버측에서 이러한 문제에 대해서 구현해줘야 하는데 이를 위해 서버측 Redis와 같은 저장소에 발급한 Refresh 토큰을 저장해서 로그아웃을 하거나 토큰이 탈취 당했을 때 블랙리스트를 도입하여 블랙리스트에 저장한다는 구현들이 많았다.
그래서 로그아웃 상태거나 탈취된 토큰은 Redis 서버에서 제거하여 앞으로 Access 토큰 재발급이 불가능하도록 설정하는 것이었다.
하지만 모순...
위처럼 서버에서 레디스같은 저장소를 도입하는 것을 이야기 했지만 나는 그것은 모순이라고 생각했다.
Refresh들을 저장하기 위한 Redis를 도입해버리면 사실상 세션 클러스터링을 작업하고 세션 방식을 사용하는 것이 좋지 않을까? 라는 생각을 하게 된 것이다.
왜냐면 나는 jwt config 를 작성하면서 앞 단에서 세션 STATELESS 작업을 했는데, 뒷단인 다른 곳에서 상태 저장이 생겨버리는 것이 아닌가 라는 생각이 든 것이다.
그래서 탈취를 막으면서도 Redis를 도입하지 않을 방법에 대해서 고민을 했지만.....
시원한 해답은 얻지를 못했다. 아래처럼 계속 둘레에 빠져 한 곳만 바로보고 있던 것이다. STATELESS → 그런데 Redis → 그럼 차라리 세션 → 왜 JWT를 사용했지?
결론 : JWT를 왜 사용하는가?
우리는 우리가 할려는 일에 대해서 목표가 무엇인지 판단해야 한다. 우리가 JWT의 목적을 확인하지 않고 구현에만 열중한다면 무엇을 하는지도 모르는 것에 불과하다. 따라서 JWT의 STATELESS한 상태에만 목적을 두는 것이 아닌 JWT가 왜 필요한지를 생각했고 해답을 찾았다.
JWT를 사용한 이유
모바일 앱
JWT가 사용된 주 이유는 결국 모바일 앱의 등장이다.
모바일 앱의 특성상 주로 JWT 방식으로 인증/인가를 진행한다.
그렇기 때문에 결국 세션 STATLESS는 앱의 등장으로 인해 부수적인 효과인 것이다.
장시간 로그인과 세션
장기간 동안 로그인 상태를 유지하려고 세션 설정을 하면 서버 측 부하가 많이 가기 때문에 JWT 방식을 이용하는 것도 한 방법이다.
위의 이런 이유때문에 jwt가 만들어졌고 JWT의 목적이 STATELESS가 아니기 때문에 나중에 로그아웃에 대해서 레디스나 디비에 리프레시 토큰을 저장하는 로직을 추가하는 것이 올바르다고 판단을 내렸다.
public class GoogleResponse implements OAuth2Response{
private final Map<String, Object> attribute;
public GoogleResponse(Map<String, Object> attribute) {
this.attribute = attribute;
System.out.println("google attributes: " + attribute);
}
@Override
public String getProvider() {
return "google";
}
@Override
public String getProviderId() {
return attribute.get("sub").toString();
}
@Override
public String getEmail() {
return attribute.get("email").toString();
}
@Override
public String getName() {
return attribute.get("name").toString();
}
}
구글에 대해서는 카드 인증이 필요해서 귀찮기 때문에.. 하지는 않았지만 정리를 위해 작성했다. 실제 구글 oauth2는 신청하지 않았기에 사용하지 않았다.
3. OAuth2User
CustomOAuth2User.java
public class CustomOAuth2User implements OAuth2User {
private final OAuth2Response oAuth2Response;
private final String role;
public CustomOAuth2User(OAuth2Response oAuth2Response, String role) {
this.oAuth2Response = oAuth2Response;
this.role = role;
}
// 현재는 null 했지만 이 값을 지정하면
// 카카오,네이버 등 로그인했으면 거기에 맞는 프로필 사진이나 가져올 수 있음
@Override
public Map<String, Object> getAttributes() {
return null;
}
// role에 해당하는 값
@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
Collection<GrantedAuthority> collection = new ArrayList<>();
collection.add(new SimpleGrantedAuthority(role));
return collection;
}
@Override
public String getName() {
return oAuth2Response.getName();
}
// 사용안함
public String getUsername() {
return oAuth2Response.getProvider()+" "+oAuth2Response.getProviderId();
}
}
카카오, 네이버, 구글 서비스로부터 받은 특정 사이트의 응답 값과 롤에 대한 값을 받는 클래스이다.
이 클래스를 통해 특정 값과 롤에 대해 정의한다.
4. SecurityConfig
@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {
private final CustomUserDetailsService customUserDetailsService; // 기본 세션 로그인
private final CustomOauth2UserService customOAuth2UserService; // OAuth2 등록
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests(authorize -> authorize
.requestMatchers("/api/users/signup", "/api/users/login").permitAll()
.requestMatchers("/oauth-login/admin").hasRole("ADMIN")
.requestMatchers("/oauth-login/info").authenticated()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/api/users/login") // 로그인 페이지의 경로
.loginProcessingUrl("/login") // 로그인 폼이 제출되는 URL
.defaultSuccessUrl("/api/users/home")
.permitAll()
)
.logout(logout -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/")
)
.sessionManagement(sessionManagement -> sessionManagement
.maximumSessions(1)
.maxSessionsPreventsLogin(true)
)
.userDetailsService(customUserDetailsService)
.csrf(csrf -> csrf.disable())
.cors(httpSecurityCorsConfigurer -> httpSecurityCorsConfigurer.configurationSource(configurationSource()))
// OAuth 등록
.oauth2Login(oauth2 -> oauth2
.loginPage("/api/users/login") // 커스텀 로그인 방식 지정
// customOAuth2UserService 등록
.userInfoEndpoint(userInfoEndpointConfig ->
userInfoEndpointConfig.userService(customOAuth2UserService))
.failureUrl("/loginFailure")
.defaultSuccessUrl("/api/users/info")
.authorizationEndpoint(authorization -> authorization
.baseUri("/oauth2/authorization")
)
.permitAll()
);
return http.build();
}
@Bean
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder();
}
public CorsConfigurationSource configurationSource(){
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOrigin("*");
config.addAllowedHeader("*");
config.addAllowedMethod("*");
config.setAllowedMethods(List.of("GET","POST","DELETE"));
source.registerCorsConfiguration("/**",config);
return source;
}
}
Oauth2 설정을 해준다.
5. OAuth2UserService 구현
OAuth2UserService.java
@Service
@RequiredArgsConstructor
@Slf4j
public class CustomOauth2UserService extends DefaultOAuth2UserService {
// DefaultOAuth2UserService는 OAuth2UserService의 구현체라서
// DefaultOAuth2UserService 또는 OAuth2UserService 아무거나 상속해도 된다.
private final UserRepository userRepository;
private final RoleRepository roleRepository;
// loadUser --> 네이버나 카카오의 사용자 인증 정보를 받아오는 메서드
// userRequest 를 통해 카카오, 네이버, 구글 등등 인증 데이터가 넘어 올 것이다.
@Override
public OAuth2User loadUser(OAuth2UserRequest userRequest) throws OAuth2AuthenticationException {
OAuth2User oAuth2User = super.loadUser(userRequest);
System.out.println("OAuth2User attributes: " + oAuth2User.getAttributes());
// 네이버, 구글, 깃허브 등등 어떤 어떤 인증 값인지 구별하기 위해 인증 제공자를 구분
String registrationId = userRequest.getClientRegistration().getRegistrationId();
// 각 사이트마다 인증 데이터 규격이 다르기 때문에 OAuth2Response 를 만들어 구별
// 인증 제공자에 따라 OAuth2Response를 생성
OAuth2Response oAuth2Response = null;
// 그 값이 네이버면
if (registrationId.equals("naver")) {
log.info("naver 로그인");
oAuth2Response = new NaverResponse(oAuth2User.getAttributes());
// 그 값이 카카오면
} else if (registrationId.equals("kakao")) {
log.info("kakao 로그인");
oAuth2Response = new KakaoResponse(oAuth2User.getAttributes());
// 둘다 아니면
} else {
System.out.println("로그인 실패");
throw new IllegalArgumentException("지원하지 않는 로그인 제공자입니다.");
}
// 데이터 베이스 저장 관련 구현
String provider = oAuth2Response.getProvider();
String providerId = oAuth2Response.getProviderId();
String username = provider + " " + providerId;
Optional<User> userOptional = userRepository.findByUsername(username);
String roleName = "USER";
Optional<Role> roleOptional = roleRepository.findByName(roleName);
Role role;
if (roleOptional.isEmpty()) {
role = new Role(roleName);
role = roleRepository.save(role); // Save the new role and get the persisted instance
} else {
role = roleOptional.get();
}
User user;
if (userOptional.isEmpty()) {
user = User.builder()
.username(username)
.email(oAuth2Response.getEmail())
.roles(Set.of(role))
.loginId(oAuth2Response.getProviderId())
.provider(oAuth2Response.getProvider())
.password("defaultPassword")
.registrationDate(LocalDateTime.now())
.usernick(oAuth2Response.getName())
.build();
userRepository.save(user);
} else {
user = userOptional.get();
user.setUsername(username);
user.setEmail(oAuth2Response.getEmail());
user.setLoginId(oAuth2Response.getProviderId());
user.setProvider(oAuth2Response.getProvider());
user.getRoles().add(role);
user.setRegistrationDate(LocalDateTime.now());
user.setUsernick(oAuth2Response.getName());
userRepository.save(user);
roleName = user.getRoles().iterator().next().getName();
}
System.out.println("User saved: " + user);
// 특정 사이트의 응답 값과 역할을 받는 CustomOAuth2User 클래스
// 인증된 사용자 정보를 반환
return new CustomOAuth2User(oAuth2Response, roleName);
}
}
Spring Security의 OAuth2 인증을 처리하는 커스텀 서비스이다.
주로 네이버, 카카오, 구글 등의 OAuth2 제공자에서 사용자 인증 정보를 받아와 데이터베이스에 저장하거나 업데이트하는 역할을 한다.
loadUser는 네이버나 카카오의 사용자 인증 정보를 받아오는 메서드이다.
외부 사이트로부터 사용자 정보를 받아오고 그 값을 디비에 저장하는 클래스이다.
6. 컨트롤러
UserController.java
@Controller
@RequiredArgsConstructor
@RequestMapping("/api/users")
@Slf4j
public class UserController {
private final UserServiceImpl userServiceimpl;
private final CustomUserDetailsService customUserDetailsService;
@GetMapping("/signup")
public String signup(Model model) {
model.addAttribute("user", new UserDto());
return "/user/singupform";
}
@PostMapping("/signup")
public String signup(@ModelAttribute("user") UserDto userDto,
RedirectAttributes redirectAttributes) {
try {
userServiceimpl.signUp(userDto);
redirectAttributes.addFlashAttribute("success", " 성공적으로 회원가입 됐습니다.");
return "redirect:/api/users/login";
} catch (Exception e) {
log.error("회원가입 오류 : {} " , e.getMessage());
redirectAttributes.addFlashAttribute("error", "회원가입에 실패했습니다." + e.getMessage());
e.printStackTrace();
}
return "redirect:/api/users/login";
}
@GetMapping("/login")
public String showLoginForm() {
return "/user/loginform";
}
// 일반 로그인 회원의 정보 가져오기
@GetMapping("/home")
public String index(Model model, Authentication authentication) {
String username = authentication.getName();
Optional<User> userOptional = userServiceimpl.findByEmail(username);
if (userOptional.isPresent()) {
model.addAttribute("user", userOptional.get());
return "user/home"; // user/home.html 템플릿으로 이동
}
return "redirect:/api/users/login";
}
// oauth2 유저의 정보 가져오기
@GetMapping("/info")
public String info(Model model, Authentication authentication) {
CustomOAuth2User userDetails = (CustomOAuth2User) authentication.getPrincipal();
model.addAttribute("name", userDetails);
return "/user/info";
}
}
원래의 나라면 Service는 Class로 만들었을 테지만, 팀원 중 한명이 유지보수에 좋다고 해서 분리해보겠다.
UserServiceImpl.java
@Service
@RequiredArgsConstructor
public class UserServiceImpl implements UserService {
private final UserRepository userRepository;
private final RoleRepository roleRepository;
private final PasswordEncoder passwordEncoder;
@Override
@Transactional
public void signUp(UserDto userDto) {
if (!userDto.getPassword().equals(userDto.getPasswordCheck())) {
throw new RuntimeException("비밀번호가 다릅니다.");
}
if (userRepository.existsByEmail(userDto.getEmail())) {
throw new RuntimeException("이메일이 존재합니다.");
}
if (userRepository.existsByUsernick(userDto.getUsernick())) {
throw new RuntimeException("닉네임이 존재합니다.");
}
Role role = roleRepository.findByName(userDto.getUsername().equals("admin") ? "ADMIN" : "USER");
User user = new User();
user.setRoles(Collections.singleton(role));
user.setEmail(userDto.getEmail());
user.setUsernick(userDto.getUsernick());
user.setUsername(userDto.getUsername());
user.setPassword(passwordEncoder.encode(userDto.getPassword()));
userRepository.save(user);
}
@Override
public Optional<User> findByEmail(String email) {
return userRepository.findByEmail(email);
}
@Override
public void deleteUser(String email) {
Optional<User> emailOptional = userRepository.findByEmail(email);
if (emailOptional.isPresent()) {
userRepository.delete(emailOptional.get());
} else {
throw new RuntimeException("삭제할 사용자가 존재하지 않습니다.");
}
}
}
signUp 메서드를 보면 username이 admin이면 Role을 ADMIN으로 주고 그게 아니면 USER로 주는 것으로 진행했다.
5. 컨트롤러
Usercontroller.java
@Controller
@RequiredArgsConstructor
@RequestMapping("/api/users/")
@Slf4j
public class UserController {
private final UserServiceImpl userServiceimpl;
private final CustomUserDetailsService customUserDetailsService;
@GetMapping("/signup")
public String signup(Model model) {
model.addAttribute("user", new UserDto());
return "/user/singupform";
}
@PostMapping("/signup")
public String signup(@ModelAttribute("user") UserDto userDto,
RedirectAttributes redirectAttributes) {
try {
userServiceimpl.signUp(userDto);
redirectAttributes.addFlashAttribute("success", " 성공적으로 회원가입 됐습니다.");
return "redirect:/users/login";
} catch (Exception e) {
log.error("회원가입 오류 : {} " , e.getMessage());
redirectAttributes.addFlashAttribute("error", "회원가입에 실패했습니다." + e.getMessage());
e.printStackTrace();
}
return "redirect:/api/users/login";
}
@GetMapping("/login")
public String showLoginForm() {
return "/user/loginform";
}
// @PostMapping("/login")
// public void login(@ModelAttribute User user, RedirectAttributes redirectAttributes) {
// try {
// UserDetails userDetails = customUserDetailsService.loadUserByUsername(user.getUsername());
// Authentication authentication = new UsernamePasswordAuthenticationToken(userDetails, user.getPassword(), userDetails.getAuthorities());
// SecurityContextHolder.getContext().setAuthentication(authentication);
// } catch (Exception e) {
// redirectAttributes.addFlashAttribute("error", "아이디 또는 비밀번호가 올바르지 않습니다.");
// }
// }
// 일반 로그인 회원의 정보 가져오기
@GetMapping("/home")
public String index(Model model, Authentication authentication) {
String username = authentication.getName();
Optional<User> userOptional = userServiceimpl.findByEmail(username);
if (userOptional.isPresent()) {
model.addAttribute("user", userOptional.get());
return "user/home"; // user/home.html 템플릿으로 이동
}
return "redirect:/api/users/login";
}
}
userDto로부터 회원가입에 필요한 정보를 받아서 회원가입을 한다.
여기서 애를 먹었는데, @Postmapping("/login")에서 로그인이 들어오면 그 정보를 가지고 있었는데 저부분 때문에 자꾸 로그인이 안됐다.
@Postmapping("/login") 메소드에서 CustomUserDetailsService를 통해 사용자를 로드하고 Authentication을 설정하려고 하지만, 이 방식은 Spring Security의 기본 인증 방식과 충돌할 수 있다.
Spring Security는 기본적으로 formLogin을 사용하여 로그인 처리를 자동으로 수행하므로, 수동으로 인증을 설정할 필요는 없다.
로그인 처리를 Spring Security의 기본 메커니즘에 맡기기 위해, UserController의 login 메소드를 제거하고, 로그인 페이지에서 제공한 폼 데이터를 Spring Security의 formLogin을 통해 처리하게 하는 것이 좋다.
6. UserDetails
CustomUserDetails.java
public class CustomUserDetails implements UserDetails {
private final String email;
private final String password;
private final Collection<? extends GrantedAuthority> authorities;
public CustomUserDetails(String email, String password, Set<Role> roles) {
this.email = email;
this.password = password;
this.authorities = roles.stream()
.map(role -> new SimpleGrantedAuthority(role.getName()))
.collect(Collectors.toList());
}
@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
return authorities;
}
@Override
public String getPassword() {
return password;
}
@Override
public String getUsername() {
return email;
}
@Override
public boolean isAccountNonExpired() {
return true;
}
@Override
public boolean isAccountNonLocked() {
return true;
}
@Override
public boolean isCredentialsNonExpired() {
return true;
}
@Override
public boolean isEnabled() {
return true;
}
}
spring Security의 UserDetails 인터페이스를 상속하여 정의한다.
이 클래스가 하는 역할은 Spring Security는 이 클래스를 사용하여 사용자 인증 및 권한 부여를 처리한다.
일단 시큐리티를 사용하면 우리가 직접 로그인 처리를 안해도 된다.
POST /login 에 대한 요청을 security가 가로채서 로그인 진행해주기 때문에 우리가 직접 @PostMapping("/login") 을 만들지 않아도 됨!
토큰 방식이 아닌 기존 세션방식으로 시큐리티 로그인에 성공하면 Security Session을 생성해 준다.(Key값 : Security ContextHolder)
Security Session(Authentication(UserDetails)) 이런 식의 구조로 되어있는데 지금 작성한 CustomUserDetails에서 UserDetails를 설정해준다고 보면 된다.
7. UserDetailsService
CustomUserDetailsService.java
@Service
@RequiredArgsConstructor
@Slf4j
public class CustomUserDetailsService implements UserDetailsService {
private final UserRepository userRepository;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
log.info("로그인이 들어왓나?");
log.info("조회할 이메일: {}", username);
Optional<User> userOptional = userRepository.findByEmail(username);
if (userOptional.isEmpty()) {
log.info("사용자가 없다");
throw new UsernameNotFoundException("사용자가 존재하지 않습니다: " + username);
}
User foundUser = userOptional.get();
Set<Role> roles = foundUser.getRoles();
return new CustomUserDetails(
foundUser.getEmail(),
foundUser.getPassword(),
roles
);
}
}
사용자가 로그인할 때, CustomUserDetailsService의 loadUserByUsername 메서드가 호출되어 사용자 정보를 데이터베이스에서 조회한다.
만약, 사용자가 존재하지 않는 경우 UsernameNotFoundException 예외를 발생시키고 사용자가 존재하는 경우, UserDetails 객체를 생성하고 반환한다.
Spring Security는 UserDetails 객체를 사용하여 사용자의 비밀번호와 권한 정보를 확인한다.
CustomUserDetails 객체는 사용자의 비밀번호와 권한 정보를 Spring Security에 제공한다.
Spring Security는 이 정보를 바탕으로 사용자가 인증되었는지 확인하고, 권한에 따라 접근을 제어한다.
즉, loadUserByUsername 메서드는 로그인을 진행할 때 주어진 사용자 이름(email, 로그인 진행 시 아이디)을 기반으로 사용자의 세부 정보를 검색하고 반환하는 역할을 한다.
jwt 방식을 사용한다면 이 방식은 필요없다.
7. SecurityConfig
SecurityConfig.java
@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {
private final CustomUserDetailsService customUserDetailsService;
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests(authorize -> authorize
.requestMatchers("/api/users/signup", "/api/users/login", "/api/users/home").permitAll()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/api/users/login") // 로그인 페이지의 경로
.loginProcessingUrl("/login") // 로그인 폼이 제출되는 URL
// .usernameParameter("email") // 변경된 필드명
// .passwordParameter("password")
.defaultSuccessUrl("/api/users/home")
.permitAll()
)
.logout(logout -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/")
)
.sessionManagement(sessionManagement -> sessionManagement
.maximumSessions(1)
.maxSessionsPreventsLogin(true)
)
.userDetailsService(customUserDetailsService)
.csrf(csrf -> csrf.disable());
return http.build();
}
@Bean
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder();
}
}
HttpSecurity로 대부분 구현한다고 생각하면 된다. 참고로 현재는 WebSecurityConfigurerAdapter는 사용을 안한다.
먼저 config 패키지에 SecurityConfig라는 시큐리티 설정 파일을 만들어 주고 필요한 @bean들을 추가해 사용할 수 있다. --> 사진을 찾다보니 현재 WebSecurityConfigurerAdapter는 시큐리티3부터 사용을 안하지만 HttpSecurity에 대한 설명이 나와있어서 사용했다. 현재 WebSecurityConfigurerAdapter 를 상속하지 않는다!
이제는 @Bean 으로 SpringSecurityFilterChain 을 구현한다.
config 클래스에@EnableWebSecurity 어노테이션을 달아서 시큐리티 설정을 해준다.
@Configuration
@EnableWebSecurity
public class SecurityConfig{
// 패스워드 암호화 관련 메소드
@Bean
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder();
}
// 특정 HTTP 요청에 대한 웹 기반 보안 구성
// 시큐리티 대부분의 설정을 담당하는 메소드
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf(AbstractHttpConfigurer::disable)
.httpBasic(AbstractHttpConfigurer::disable)
.authorizeHttpRequests((authorize) -> authorize
.requestMatchers("/signup", "/", "/login").permitAll()
.anyRequest().authenticated()
)
// Form 로그인을 활용하는경우 (JWT에는 필요없음)
.formLogin(form -> form
.loginPage("/loginform")
.loginProcessingUrl("/login")
.defaultSuccessUrl("/")
.permitAll()
)
.logout((logout) -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/")
.invalidateHttpSession(true)
)
.sessionManagement(sessionManagement -> sessionManagement
.maximumSessions(1)
.maxSessionsPreventsLogin(true)
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
)
);
return http.build();
}
// 이외에도 등록해서 사용하면 된다..
}
코드설명
filterChain() : 특정 Http 요청에 대해 웹 기반 보안 구성. 인증/인가 및 로그아웃을 설정한다.
.csrf(Cross site Request forgery) : 공격자가 인증된 브라우저에 저장된 쿠키의 세션 정보를 활용하여 웹 서버에 사용자가 의도하지 않은 요청을 전달하는 것. 즉, 정상적인 사용자가 의도치 않은 위조요청을 보내는 것을 의미한다.
REST API를 이용한 개발을 진행 할 예정일 때, Rest Api 환경에서는 Session 기반 인증과 다르기 때문에 서버에 인증 정보를 보관하지 않고, 권한 요청시 필요한 인증정보(OAuth2, Jwt토큰 등)요청을 포함하기 때문에 굳이 불필요한 csrf 보안을 활성화할 필요가 없다.
따라서 csrf는 disable 처리
.HttpBasic()
HttpBasic() : Http basic Auth 기반으로 로그인 인증창이 뜬다.
.authorizeHttpRequests() : 인증, 인가가 필요한 URL 지정
anyRequest() : requestMatchers에서 지정된 URL 외의 요청에 대한 설정
authenticated() : 해당 URL에 진입하기 위해서는 인증이 필요함
requestMatchers("Url").permitAll() : requestMatchers에서 지정된 url은 인증, 인가 없이도 접근 허용
Url에 /**/ 와 같이 ** 사용 : ** 위치에 어떤 값이 들어와도 적용 (와일드 카드)
hasAuthority() : 해당 URL에 진입하기 위해서 Authorization(인가, 예를 들면 ADMIN만 진입 가능)이 필요함
.hasAuthority(UserRole.ADMIN.name()) 와 같이 사용 가능
formLogin() : Form Login 방식 적용
loginPage() : 로그인 페이지 URL
defaultSuccessURL() : 로그인 성공시 이동할 URL
failureURL() : 로그인 실패시 이동할 URL
logout() : 로그아웃에 대한 정보
invalidateHttpSession() : 로그아웃 이후 전체 세션 삭제 여부
sessionManagement() : 세션 생성 및 사용여부에 대한 정책 설정
SessionCreationPolicy() : 정책을 설정
SessionCreationPolicy.Stateless : 4가지 정책 중 하나로, 스프링 시큐리티가 생성하지 않고 존재해도 사용하지 않는다. (JWT와 같이 세션을 사용하지 않는 경우에 사용)
BCryptPasswordEncoder
BCrype 인코딩을 통하여 비밀번호에 대한 암호화를 수행한다.
password를 암호화해줌
Spring Security에서 비밀번호를 안전하게 저장할 수 있도록 비밀번호의 단방향 암호화를 지원한다. -> PasswordEncoder 인터페이스와 구현체들
encode() : 비밀번호를 암호화(단방향)
matches() : 암호화된 비밀번호와 암호화되지 않은 비밀번호가 일치하는지 비교
upgradeEncoding() : 인코딩된 암호화를 다시 한번 인코딩 할 때 사용 (true일 경우 다시 인코딩, default=false)
PasswordEncoder가 제공하는 구현 클래스
StandardPasswordEncoder : SHA-256을 이용해 암호를 해시한다. (강도가 약한 해싱 알고리즘이기 때문에 지금은 많이 사용되지 않는다.)
BCryptPasswordEncoder : bcrypt 강력 해싱 함수로 암호를 인코딩
NoOpPasswordEncoder : 암호를 인코딩하지 않고 일반 텍스트로 유지(테스트 용도로만 사용.)
SCryptPasswordEncoder : scrypt 해싱 함수로 암호를 인코딩한다.
@Bean // 패스워드 암호화 관련 메소드
public PasswordEncoder passwordEncoder(){
return new BCryptPasswordEncoder();
}
현재 사용되는 알고리즘에서 취약성이 발견되어 다른 인코딩 알고리즘으로 변경하고자 할 때 대응하기 좋은 방법은 DelegatingPasswordEncoder을 사용하는 것
@Bean // DelegatingPasswordEncoder: 여러 인코딩 알고리즘을 사용할 수 있게 해주는 기능
public static PasswordEncoder passwordEncoder() {
return PasswordEncoderFactories.createDelegatingPasswordEncoder();
}
기타 참고용
Configure 작성 문법 바뀐 부분
스프링 3.0 이상의 버전부터는 스프링 시큐리티 버전도 바뀌어서 기존의 Configuration과는 다르게 작성해야 한다. WebSecurity, HttpSecurity 모두 큰 변화를 맞이 했는데, 그중 하나가 lambdas 형식의 작성법이다.
http
.authorizeHttpRequests(authorizeRequest -> authorizeRequest
// 해당 경로는 모든 권한을 허용한다.
.requestMatchers(HttpMethod.GET, "/login**", "/web-resources/**", "/actuator/**").permitAll()
// 해당 경로는 어드민 권한이 있어야한다.
.requestMatchers(HttpMethod.GET, "/admin/**").hasAnyRole("ADMIN")
// 해당 경로는 유저 권한이 있어야 한다.
.requestMatchers(HttpMethod.GET, "/order/**").hasAnyRole("USER")
// 나머지는 모두 권한이 필요하다.
.anyRequest().authenticated()
requestMatchers
특정 리소스에 대해서 권한을 설정한다.
permitAll
리소스의 접근을 인증절차 없이 허용한다.
authenticated
리소스의 접근을 인증절차를 통해 허용한다.
hasAnyRole
해당 권한을 가진 사용자만 접근을 허용한다.
anyRequest
모든 리소스를 의미하며, anyMatcher로 설정하지 않은 리소스를 말한다.
HttpSecurity - 로그인처리 설정
로그인 FORM 페이지를 이용하여 로그인하는 방식을 사용하려고 할때 여러가지 설정을 할 수 있다.
// Form 로그인을 활용하는경우 (JWT에는 필요없음)
// .formLogin(Customizer.withDefaults()); // Security가 제공하는 로그인 방식 사용
.formLogin(formLogin -> formLogin
.loginPage("/login")
.loginProcessingUrl("/loginProc")
.usernameParameter("userId")
.passwordParameter("userPw")
.permitAll())
JwtAuthenticationFilter 사용
HttpSecurity - 커스텀 필드 등록 ⭐
커스텀 필터를 생성해서 등록할 수 있다!
.addFilterBefore(jwtAuthenticationFilter,
UsernamePasswordAuthenticationFilter.class)
// UsernamePasswordAuthenticationFilter가 기존 시큐리티 세션 방식의 로그인 필터이기 때문에
// UsernamePasswordAuthenticationFilter 앞에 커스텀한 필터 체인을 넣어준다.
3편에서는 RefreshToken과 BlackListToken에 대해서 엔티티와 레포지토리, 서비스를 작성했다.
4편에서는 본격적으로 JWT 코드를 짜볼 것이다.
코드도 많이 길고 복잡하다..
<- 대략적인 파일 구조
<- 파일 구조에 맞게 세팅한다.
1. 사용자 인증 및 권한 관리를 위해 설정할 것
1.1 CustomUserDetails.java
public class CustomUserDetails implements UserDetails {
private final String userName; // 이름
private final String password; // 비밀번호
private final List<GrantedAuthority> authorities; // 권한 목록
// 생성자
public CustomUserDetails(String userName, String password, List<String> roles){
this.userName = userName;
this.password = password;
this.authorities = roles.stream() // 권한 관련 작업을 하기 위한 role return
.map(SimpleGrantedAuthority::new)
.collect(Collectors.toList());
}
`
` // 사용자가 가진 권한 반환
// SimpleGrantedAuthority 객체를 사용하여 역할을 권한으로 변환
@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
return authorities;
}
// 사용자의 비밀번호를 반환
@Override
public String getPassword() {
return password;
}
// 사용자의 이름을 반환
@Override
public String getUsername() {
return userName;
}
// 사용자의 계정 만료 상태
@Override
public boolean isAccountNonExpired() {
return true;
}
// 잠금 상태
@Override
public boolean isAccountNonLocked() {
return true;
}
// 자격 증명 만료 상태
@Override
public boolean isCredentialsNonExpired() {
return true;
}
// 활성화 상태
@Override
public boolean isEnabled() {
return true;
}
}
spring Security의 UserDetails 인터페이스를 상속하여 정의한다.
이 클래스가 하는 역할은 Spring Security는 이 클래스를 사용하여 사용자 인증 및 권한 부여를 처리한다.
SimpleGrantedAuthority 는 역할 이름을 그대로 사용한다는 의미로 데이터베이스에 ROLE_ADMIN, ROLE_USER 이렇게 되어 있다면 이걸 그대로 사용하겠다는 의미이다.
List<String> 형태의 역할을 생성자로 받고, 이를 GrantedAuthority로 변환하며 신원을 증명하는 데 사용하는 정보 --> 비밀번호나 토큰
일단 시큐리티를 사용하면 우리가 직접 로그인 처리를 안해도 된다.
POST /login 에 대한 요청을 security가 가로채서 로그인 진행해주기 때문에 우리가 직접 @PostMapping("/login") 을 만들지 않아도 됨!
토큰 방식이 아닌 기존 세션방식으로 시큐리티 로그인에 성공하면 Security Session을 생성해 준다. (Key값 : Security ContextHolder)
Security ContextHolder 의 내부는 Security Session(Authentication(UserDetails)) 이런 식의 구조로 되어있는데 지금 작성한 CustomUserDetails가 UserDetails를 설정해준다고 보면 된다.
1.2 CustomUserDetailsService.java
일단 이 클래스는 Spring Security의 UserDetailsService 인터페이스를 상속받아 구현한다.
나는 UserDetailsService 인터페이스를 구현한 CustomUserDetailsService 라는 클래스를 구현했다.
이전까지는 UserService에서 findUserByLoginId 이런 식으로 User을 불러왔었다.
하지만, 위에서 말했듯 기존 세션 방식에서의 Security는 UserDetails 가 필요하기 때문에 따로 설정이 필요하다. => 위에서 만든 CustomUserDetails 를 return하거나 org.springframework.security.core.userdetails.User를 불러와 리턴하는 방법이 있다.
둘의 방식과 쓰임은 똑같다.
Q. CustomUserDetailsService.java 는 어떻게 사용될까?
사용자가 로그인할 때, CustomUserDetailsService의 loadUserByUsername 메서드가 호출되어 사용자 정보를 데이터베이스에서 조회한다.
만약, 사용자가 존재하지 않는 경우 UsernameNotFoundException 예외를 발생시키고
사용자가 존재하는 경우, UserDetails 객체를 생성하고 반환한다.
Spring Security는 UserDetails 객체를 사용하여 사용자의 비밀번호와 권한 정보를 확인한다..
UserDetails 객체는 사용자의 비밀번호와 권한 정보를 Spring Security에 제공한다.
Spring Security는 이 정보를 바탕으로 사용자가 인증되었는지 확인하고, 권한에 따라 접근을 제어한다.
UserDetailsService 를 작성하는 방법은 다양하게 작성이 가능하고 나는 그 중 아래 2가지로 구현을 해봤다.
1.2.1. UserBuilder를 사용하여 반환
@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {
private final UserRepository userRepository;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
Optional<User> user = userRepository.findByUserName(username); // 데이터베이스에서 사용자 이름을 기준으로 사용자를 조회
if (!user.isPresent()) {
throw new UsernameNotFoundException("해당 사용자가 존재하지 않습니다. : " + username);
}
// UserBuilder를 사용하여 UserDetails 객체를 생성 --> 사용자 정보를 쉽게 생성하고 구성
// withUsername(username)를 호출하여 사용자 이름을 설정
UserBuilder userBuilder = org.springframework.security.core.userdetails.User.withUsername(username);
userBuilder.password(user.get().getPassword()); // 암호화된 비밀번호를 설정
userBuilder.roles(user.get().getRole().stream()
.map(role -> role.getRoleName().name())
.toArray(String[]::new));
return userBuilder.build();
}
}
첫 번째 방법은 UserBuilder를 사용하여 UserDetails 객체를 생성하는 방법이다.
Spring Security에서 제공하는 UserBuilder는 UserDetails 객체를 유연하게 생성하고 설정할 수 있도록 도와준다.
UserBuilder는 org.springframework.security.core.userdetails.User 클래스 내부에 정적 메서드로 정의되어 있다.
org.springframework.security.core.userdetails.User클래스의 withUsername 정적 메서드를 사용하여 UserBuilder 인스턴스를 생성한다.
이때 사용자 이름, 암호화된 비밀번호, 역할을 설정하여 UserBuilder를 반환한다.
이를 통해 UserDetails 객체를 커스텀 하지 않고도 쉽게 생성할 수 있다. -> 즉, 위에서 만든 CustomUserDetails 클래스는 사용 하지 않고도 시큐리티가 제공하는 기능을 사용하여 사용자 정보를 데이터베이스에서 꺼낼 수 있다.
이 방식은 간결하고 가독성이 높아, UserDetails객체를 쉽게 생성할 수 있다.
1.2.2 CustomUserDetails 클래스에 직접 값 반환
@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {
private final UserRepository userRepository;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
Optional<User> userOptional = userRepository.findByUserName(username); // 데이터베이스에서 사용자 이름을 기준으로 사용자를 조회
if (!userOptional.isPresent()) {
throw new UsernameNotFoundException("해당 사용자가 존재하지 않습니다. : " + username);
}
User foundUser = userOptional.get();
Set<Role> roles = foundUser.getRoles();
List<String> roleNames = roles.stream()
.map(role -> role.getRoleName().name()) // "ROLE_" 접두사를 제거하지 않음
.collect(Collectors.toList());
return new CustomUserDetails(
foundUser.getUsername(),
foundUser.getPassword(),
roleNames
);
}
}
두 번째 방법이다.
위에서 만든 CustomUserDetails에 사용자 이름, 암호화된 비밀번호, 역할을 담아 반환해주는 것이다.
어찌됐던 두 개의 사용법은 다 똑같고 반환 부분도 거의 비슷하다.
하지만 첫 번째 방법과 달리 위에서 만든 CustomUserDetails 클래스를 사용하면 사용자 정보를 추가하거나 커스텀할 수 있다.
특정 요구 사항에 맞게 클래스와 메서드를 자유롭게 정의할 수 있다.
Q. 위의 코드들을 보면 org.springframework.security.core.userdetails.User 클래스를 호출하거나, CustomUserDetails 클래스를 불러오던데 무슨 차이인지?
A.
org.springframework.security.core.userdetails.User 클래스는 UserDetails 인터페이스를 시큐리티 자체적으로 구현하고 있다.
즉, org.springframework.security.core.userdetails.User 클래스는 UserDetails 인터페이스를 구현한 기본 제공 구현체로, 사용자 이름, 비밀번호, 권한 정보를 포함하고 있다.
CustomUserDetails 클래스를 안불러와도 사용이 가능하다는 뜻이다.
위에서도 설명했듯이 기존 세션방식으로 시큐리티 로그인에 성공하면 Security Session을 생성해 준다. --> (Key값 : Security ContextHolder)
이때 Security Session(Authentication(UserDetails)) 이런 식의 구조로 되어있는데 CustomUserDetails 클래스에서 UserDetails를 설정해준다고 보면 되고 org.springframework.security.core.userdetails.User 클래스는 자체적으로 UserDetails 값을 가지고 있다고 보면 된다.
Q. 어떤 방법이 적절한가? --> 실무에서는?
단순한 요구 사항: 간단한 사용자 인증을 처리해야 하고, 특별한 커스터마이징이 필요 없다면 UserBuilder를 사용
확장성 필요: 사용자 정보에 추가적인 필드를 포함하거나, 커스터마이징된 사용자 정보를 사용해야 한다면 CustomUserDetails를 사용 --> 선호!
실무에서는 UserDetails를 상속하여 새로운 커스텀 UserDetails 를 만드는 것을 선호한다.
2. JWT 설정
이제 본격적으로 JWT 리프레시 토큰, 엑세스 토큰 발급을 위한 코드를 작성하겠다.
2.1 JwtAuthenticationToken.java
public class JwtAuthenticationToken extends AbstractAuthenticationToken {
private String token; // JWT 토큰
private Object principal; // 사용자 정보
private Object credentials; // 자격 증명 정보
// 인증이 된 사용자 정보와 권한을 설정
public JwtAuthenticationToken(Collection<? extends GrantedAuthority> authorities , Object principal, Object credentials) {
super(authorities); // 권한 설정
this.principal = principal; // 사용자를 식별하는 고유한 엔티티 --> 사용자의 사용자 이름, ID
this.credentials = credentials; // 사용자가 자신의 신원을 증명하는 데 사용하는 정보 -> 비밀번호, 토큰
this.setAuthenticated(true); // 사용자가 가질 수 있는 권한이나 역할 --> ROLE_USER, ROLE_ADMIN
}
// 인증되지 않은 상태로 JWT 토큰을 설정
public JwtAuthenticationToken(String token){
super(null); // 권한 없음
this.token = token;
this.setAuthenticated(false); // 인증되지 않은 상태 설정
}
// 자격 증명 정보를 반환
@Override
public Object getCredentials() {
return this.credentials;
}
// 사용자 정보를 반환
@Override
public Object getPrincipal() {
return this.principal;
}
}
JWT 기반으로 한 인증을 나타내는 토큰을 구현하는 클래스이다.
AbstractAuthenticationToken을 상속받아 인증 정보를 반환하는 메서드를 제공한다.
인증되지 않은 상태와 인증된 상태를 구분하여 생성자 제공한다.
Principal 사용자를 식별하는 고유한 엔티티 --> 사용자의 사용자 이름 또는 ID
Credentials 사용자가 자신의 신원을 증명하는 데 사용하는 정보 --> 비밀번호나 토큰
Authorities 사용자가 시스템에서 가질 수 있는 권한이나 역할 --> ROLE_USER나 ROLE_ADMIN
사용자가 시스템에 로그인을 시도하면, Credentials를 통해 자신의 신원을 증명하고, 시스템은 Principal을 통해 사용자를 식별하며, 이후 Authorities를 통해 사용자가 어떤 작업을 수행할 수 있는지를 결정한다.
2.2 JwtTokenizer.java
@Component
@Slf4j
@Getter
public class JwtTokenizer {
private final byte[] accessSecret; // Access Token 서명에 사용할 비밀키
private final byte[] refreshSecret; // Refresh Token 서명에 사용할 비밀키
public static Long ACCESS_TOKEN_EXPIRE_COUNT = 30 * 60 * 1000L; // Access Token의 만료 시간 (30분)
public static Long REFRESH_TOKEN_EXPIRE_COUNT = 7 * 24 * 60 * 60 * 1000L; // Refresh Token의 만료 시간 (7일)
public JwtTokenizer(@Value("${jwt.secretKey}") String accessSecret,
@Value("${jwt.refreshKey}") String refreshSecret){
this.accessSecret = accessSecret.getBytes(StandardCharsets.UTF_8);
this.refreshSecret = refreshSecret.getBytes(StandardCharsets.UTF_8);
}
// JWT 토큰을 생성하는 메서드
private String createToken(Long id, String email, String username, List<RoleName> roles, long expireCount, byte[] secret) {
Claims claims = Jwts.claims().setSubject(email); // JWT 클레임 설정
claims.put("userId", id); // 사용자 ID 클레임 추가
claims.put("username", username); // 사용자 이름 클레임 추가
claims.put("roles", roles); // 사용자 권한 클레임 추가
Date now = new Date();
Date expiration = new Date(now.getTime() + expireCount); // 만료 시간 계산
return Jwts.builder() // JWT 빌더
.setClaims(claims) // 클레임 설정
.setIssuedAt(now) // 발급 시간 설정
.setExpiration(expiration) // 만료 시간 설정
.signWith(SignatureAlgorithm.HS256, getSigningKey(secret)) // 서명 설정
.compact(); // JWT 생성
}
// Access Token을 생성하는 메서드
public String createAccessToken(Long id, String email, String username, List<RoleName> roles) {
return createToken(id, email, username, roles, ACCESS_TOKEN_EXPIRE_COUNT, accessSecret);
}
// Refresh Token을 생성하는 메서드
public String createRefreshToken(Long id, String email, String username, List<RoleName> roles) {
return createToken(id, email, username, roles, REFRESH_TOKEN_EXPIRE_COUNT, refreshSecret);
}
// secretKey - byte형식
public static Key getSigningKey(byte[] secretKey) {
return Keys.hmacShaKeyFor(secretKey); // 서명에 사용할 키 생성
}
// Jwt 토큰을 복호화하여 토큰에 들어있는 정보를 꺼내는 메서드
// 토큰에서 유저 아이디 얻기
public Long getUserIdFromToken(String token) {
Claims claims = parseToken(token, accessSecret); // 토큰 파싱
return Long.valueOf((Integer) claims.get("userId")); // 사용자 ID 반환
}
// 토큰 복호화
public Claims parseToken(String token, byte[] secretKey) {
return Jwts.parserBuilder()
.setSigningKey(getSigningKey(secretKey)) // 서명 키 설정
.build()
.parseClaimsJws(token) // 토큰 파싱
.getBody(); // 클레임 반환
}
// accessToken 토큰 복호화
public Claims parseAccessToken(String accessToken) {
return parseToken(accessToken, accessSecret);
}
// refreshToken 토큰 복호화
public Claims parseRefreshToken(String refreshToken) {
return parseToken(refreshToken, refreshSecret);
}
public boolean isTokenExpired(String token, byte[] secretKey) {
try {
Jwts.parserBuilder()
.setSigningKey(getSigningKey(secretKey)) // 서명 키 설정
.build()
.parseClaimsJws(token);
return false; // 토큰이 유효할 때 false를 반환해야 함
} catch (ExpiredJwtException e) {
log.error("Token expired", e);
} catch (Exception e) {
log.error("Token invalid", e);
}
return true; // 토큰이 만료되었거나 유효하지 않을 때 true를 반환
}
public boolean isAccessTokenExpired(String accessToken) {
return isTokenExpired(accessToken, accessSecret);
}
public boolean isRefreshTokenExpired(String refreshToken) {
return isTokenExpired(refreshToken, refreshSecret);
}
// 주어진 Refresh Token을 사용하여 새로운 Access Token 생성
public String refreshAccessToken(String refreshToken) {
Claims claims = parseRefreshToken(refreshToken); // Refresh Token 파싱
Long userId = claims.get("userId", Long.class); // 사용자 ID 추출
String email = claims.getSubject(); // 이메일 추출
String username = claims.get("username", String.class); // 사용자 이름 추출
List<RoleName> roles = (List<RoleName>) claims.get("roles"); // 사용자 권한 추출
return createAccessToken(userId, email, username, roles); // 새로운 Access Token 생성
}
}
JWT 토큰을 생성하고 파싱하는 역할을 하는 클래스이다.
이 클래스에 JWT를 활용하는데에 필요한 메서드들을 한 데에 모아놓았다.
Access Token 및 Refresh Token의 생성 메서드를 제공하며 토큰 만료 여부를 확인하는 메서드도 제공한다.
Refresh Token을 사용하여 Access Token이 만료된 경우 새로운 Access Token을 생성하는 메서드를 제공한다.
(Access Token : 30분 //Refresh Token : 7일)로 토큰의 만료시간을 정했다.
앞서 1편에서 기본 파일 구조와 기본 세팅을 했고, 2편에서 security 보안 설정을 했다.
이번 3편에서는 jwt 패키지에 대해서 작성할 것이다.
일단.. 엔티티, 레포지토리, 서비스를 먼저 만들어 주자.
refreshToken, blackListToken 관리하기 위한 엔티티, 레포지토리, 서비스 생성
<- jwt의 대략적인 파일 구조
1. 엔티티 생성
RefreshToken
@Entity
@Table(name = "refresh_token")
@Getter
@Setter
public class RefreshToken {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id; // 리프레시 토큰의 고유 식별자
@Column(name = "user_id")
private Long userId; // 이 리프레시 토큰과 연관된 사용자의 식별자
private String value; // 리프레시 토큰의 실제 값 -> 이 값은 서버가 클라이언트의 요청을 인증하는 데 사용
}
위 엔티티는 주로 액세스 토큰의 재발급을 위한 리프레시 토큰을 저장하는 데 사용된다.
Q. 리프레시 토큰이 뭔데?
A. 리프레시 토큰은 일반적으로 액세스 토큰보다 긴 유효 기간을 가지도록 설정하며 엑세스 토큰이 만료가 되면 클라이언트는 리프레시 토큰을 사용하여 새로운 액세스 토큰을 요청한다.
즉, 서버는 리프레시 토큰을 검증하고, 유효한 경우 새로운 액세스 토큰을 발급한다.
JwtBlacklist
@Entity
@Table(name = "jwt_blacklist")
@Getter
@Setter
@NoArgsConstructor
public class JwtBlacklist {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id; // 블랙리스트 항목의 고유 식별자
private String token; // 블랙리스트에 포함된 JWT 문자열
@Column(name = "expiration_time")
private Date expirationTime; // 블랙리스트에 있는 JWT의 만료 시간
public JwtBlacklist(String token, Date expirationTime) {
this.token = token;
this.expirationTime = expirationTime;
}
}
사용자가 로그아웃하거나 토큰이 만료된 경우, 해당 토큰을 블랙리스트에 추가하여(이 때 token 필드에 JWT 문자열을 저장) 더 이상 사용되지 않도록 한다.
JWT 인증 필터에서 요청이 들어올 때, 토큰이 블랙리스트에 있는지 확인하여 유효성을 검사한다. (token 필드를 사용하여 검증 수행)
블랙리스트에 있는 토큰은 서버에서 인식할 수 없으며, 인증 요청 시 해당 토큰이 블랙리스트에 포함되어 있으면 인증을 거부한다.
Q. 왜 블랙리스트를 써야하나?
사용자가 로그아웃을 요청했을 때, 클라이언트 측에서는 캐시에 저장된 jwt를 제거하지만 서버에서는 jwt를 무력화할 수단이 없다.
때문에 서버에서는 Jwt에 대한 블랙 리스트를 만들어 Jwt의 유효기간이 만료될 때 까지 Redis와 같은 DB에서 관리하는것을 말한다.
만약 사용자가 Jwt를 이용하여 인가를 요청했을 시, Black List의 조회를 통해 사용자가 로그아웃한 Jwt인지 아닌지를 판별하는 것이다.
public interface JwtBlacklistRepository extends JpaRepository<JwtBlacklist, Long> {
boolean existsByToken(String token); // JWT 토큰이 블랙리스트에 존재하는지 여부 확인
}
각 메서드에 대해서 주석으로 설명함
3. Service 설정
RefreshTokenService
@Service
@RequiredArgsConstructor
public class RefreshTokenService {
private final RefreshTokenRepository refreshTokenRepository;
// 리프레시 토큰 추가
@Transactional
public RefreshToken addRefreshToken(RefreshToken refreshToken) {
return refreshTokenRepository.save(refreshToken);
}
// 리프레시 토큰 조회
@Transactional
public Optional<RefreshToken> findRefreshToken(String refreshToken) {
return refreshTokenRepository.findByValue(refreshToken);
}
// 리프레시 토큰 삭제
public void deleteRefreshToken(String refreshToken) {
refreshTokenRepository.findByValue(refreshToken).ifPresent(refreshTokenRepository::delete);
}
// 사용자 기반 리프레시 토큰 삭제
public void deleteRefreshToken(Long userId) {
refreshTokenRepository.findByUserId(userId).ifPresent(refreshTokenRepository::delete);
}
// 리프레시 토큰 유효성 검증
public boolean isRefreshTokenValid(String refreshToken) {
return refreshTokenRepository.existsByValue(refreshToken);
}
}
RefreshTokenService는 리프레시 토큰(Refresh Token)을 관리하는 데 관련된 기능을 제공한다.
리프레시 토큰은 사용자가 인증된 상태를 유지하도록 돕는 역할을 하고 새로운 액세스 토큰을 발급받기 위해 사용된다.
관련 메서드
리프레시 토큰 추가 (addRefreshToken)
RefreshToken 객체를 데이터베이스에 저장하여 새로운 리프레시 토큰을 추가한다.
이 메서드는 리프레시 토큰을 발급하고 저장하는 데 사용된다.
리프레시 토큰 조회 (findRefreshToken)
주어진 리프레시 토큰 값을 사용하여 데이터베이스에서 해당 리프레시 토큰을 찾는다.
리프레시 토큰이 유효한지 확인하고 관련 정보를 반환하는 데 사용된다.
리프레시 토큰 삭제 (deleteRefreshToken)
주어진 리프레시 토큰 값을 사용하여 데이터베이스에서 해당 리프레시 토큰을 삭제한다.
사용자가 로그아웃하거나 토큰을 무효화할 때 사용된다.
사용자 기반 리프레시 토큰 삭제 (deleteRefreshToken(Long userId))
특정 사용자 ID에 연관된 리프레시 토큰을 삭제한다.
사용자가 로그아웃하거나 리프레시 토큰을 관리할 때 사용된다.
리프레시 토큰 유효성 검증 (isRefreshTokenValid)
주어진 리프레시 토큰이 데이터베이스에 존재하는지 확인하여 유효성을 검증한다.
유효한 리프레시 토큰인지 여부를 반환한다.
JwtBlacklistService
@Service
@RequiredArgsConstructor
public class JwtBlacklistService {
private final JwtBlacklistRepository jwtBlacklistRepository;
// 블랙리스트에 추가
public void save(JwtBlacklist blacklist) {
jwtBlacklistRepository.save(blacklist);
}
// 블랙리스트 저장
public void addToBlacklist(String token, Date expirationDate) {
JwtBlacklist blacklist = new JwtBlacklist(token, expirationDate);
jwtBlacklistRepository.save(blacklist);
}
// 토큰 블랙리스트 확인
public boolean isTokenBlacklisted(String token) {
return jwtBlacklistRepository.existsByToken(token);
}
}
JwtBlacklistService는 블랙리스트에 관리되는 JWT의 기능을 제공하여, 사용자가 로그아웃하거나 특정 JWT를 무효화할 때 사용하는 서비스이다.
블랙리스트는 특정 JWT가 더 이상 유효하지 않다는 것을 기록한다.
관련 메서드
블랙리스트에 추가 (addToBlacklist)
주어진 JWT와 만료 시간을 사용하여 새로운 JwtBlacklist 항목을 생성하고, 이를 데이터베이스에 저장한다.
이 메서드는 특정 JWT를 블랙리스트에 추가하여 더 이상 유효하지 않게 만든다.
블랙리스트 저장 (save):
JwtBlacklist 객체를 데이터베이스에 저장한다.
이 메서드는 블랙리스트 항목을 생성하고 저장하는 데 사용된다..
토큰 블랙리스트 확인 (isTokenBlacklisted):
주어진 JWT가 블랙리스트에 포함되어 있는지 확인한다.
이 메서드는 JWT가 블랙리스트에 있는 경우 true를 반환하여, 해당 토큰이 더 이상 유효하지 않음을 알린다.
