[2025백엔드] 스프링인액션 독서 #7 - 4장. 스프링 시큐리티 2

사진이없어요오늘의마치

어디선가~ 블로그에~

첨부사진 없으면~

마마마마마마치 엄청난 기운이~

---

마저합시다

저번에는 스프링 시큐리티와 JDBC, LDAP 방식으로 값을 조회하는 방법을 알았다.

 

이제는 사용자 인증을 커스터마이징 해 볼 때다.

---

UserDetails

User 도메인에 UserDetails를 적용할 수 있는데, UserDetails는 스프링 시큐리티가 기본제공하는 인터페이스이다. 이를 통해 구현된 User 클래스의 정보가 스프링에 전달된다.

 

UserDetails와 이의 메서드에 관한 게시글이 있다

https://programmer93.tistory.com/68

Spring Security UserDetails, UserDetailsService 란? - 삽질중인 개발자

아무튼 이렇게 User를 정의하고나면 레포지토리 인터페이스를 정의할 수 있다. JPA를 활용한 CrudRepository를 활용할 수 있다.

 

그리고 나서 UserDetailsService를 작성할 수 있는데

public interface UserDetailsService {
	UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;

이렇게 인터페이스를 작성하면 UserDetails 객체가 반환되거나 에러가 발생한다.

 

구현체는 내가 직접 작성해야하는데, 별거없이 유저레포지토리에서 findByUsername을 실행하고 받아온 값이 null이 아닐 때 User 객체를 반환하고, try-catch 문으로 예외처리하고.. 이게 다다.

 

이후 로그인 할 때 서비스에서 자동으로 스프링에게 넘겨주게끔 Config 문서만 수정하면 된다.

아까 AuthenticationManagerBuilder auth를 메서드 인자로 넘겨준 메서드에서

auth.userDetailsService(userDetailsService);

이렇게 설정하면 된다. userDetailsService 메서드를 호출한다.

 

추가로 비밀번호 암호화 코드도

.passwordEncoder(encoder());

로 수정하면 된다.

---

사용자 등록하기

지금까지 배운 스프링 시큐리티는 보안도 관리하고, 로그인 시 정보확인 절차도 시행한다...만 사용자 등록은 개발자가 직접 처리해야한다. 즉 회원가입 절차는 따로 구현해야한다.

 

..앞부분에서 HTML 문서를 작성하고 이의 요청을 받는 부분은 뺐다. 나는 HTML도 안 쓸거고 DTO로 모든 요청을 처리할 것이기 때문에.. 다만 비밀번호를 저장할 때는 

passwordEncoder.encode(password)

로 설정해야한다.

 

암튼 회원가입은 비밀번호 암호화 외엔 딱히 건들게 없다.

---

웹 요청 보안처리

이 부분은 내가 미리 작성해놓은 부분이고 스프링5에서 6으로 넘어오면서 바뀐 코드도 있기 때문에 간단하게 훑어보기만 할 예정이다.

---

authorizeRequests()

ExpressionInterceptUrlRegistry 객체를 반환한다. 이를 통해 URL 경로, 패턴, 요구사항을 구성할 수 있다.

                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/**").permitAll()
                        .anyRequest().authenticated()
                )

이거 약간 잘못된 코드다.

 

여기서는 antMatchers와 hasRole 메서드 모두 스프링6에서는 동작하지 않는다. 저걸로 대체. 람다 DSL 방식이라고한다. 헤드퍼스트자바에서는 람다가 없었는데 왜 안알려주지...? 람다 좀 알고싶다. 파이썬도 람다는 잘 몰라서..

 

암튼 스프링6에서 올라온 방식으로는

.requestMatchers("/design").hasRole("ROLE")

방식을 사용한다.

 

그리고 위의 requestMatchers("/**") 작성하면 내가 지정한 URL을 제외하고 전부 통과시켜줄 수 있다.

다만 /** URL의 통과를 먼저 설정하면 모든 URL 요청이 통과되므로 URL의 ROLE 설정이 무시된다. <- 이게 antMatchers 기준인데, requestMatchers도 효력이 있을지까지는 모르겠다. 테스트를 안해봐서

 

이외의 요청 경로의 보안처리를 위한 메서드로는 스프링인액션 4장 149쪽을 보면 된다.

첫 번째 코드들의 메서드 정보를 보면

 

- permitAll() - 무조건 접근허용

- anyRequest() - 앞서 requestMatchers로 설정되지 않은 URL에 대한 모든 요청을 포괄적으로 다룬다.

- authenticated - 인증된 사용자만 접근가능

 

access

access 메서드를 통해 configure() 메서드를 좀 더 쉽게 적용할 수 있다.

 

.requestMatchers("/design")
	.access("hasRole('ROLE_USER')")
.requestMatchers("/**").access("permitAll")l

이런식으로..

 

이런 방식 이외에도 SpEL을 사용할 수 있다. 이전에 내가 @Value 어노테이션에서 사용한 $ 방식도 SpEL의 일종이다.

SpEL은 스프링 표현식 언어인데... 이건 좀 어렵기도하고 언어를 또 배워야하니까 SQL 배우고 나서 할까요?

---

어디로 로그인할까요?

.formLogin(AbstractHttpConfigurer::disable)
                .oauth2Login(oauth2 -> oauth2
                        .defaultSuccessUrl("/api/login/success", true)

                )

내 프로그램(?)에서 가져온 코드

인증구성 간 연결은 .and 메서드를 통해 연결시켰으나 스프링6부터는 and 메서드를 거의 쓰지 않는다.

 

formLogin 메서드는 사용자지정 로그인 폼을 구성하기 위해 호출하고, 그 url 경로를 loginpage로 연결시킨다.

저 위에 AbstractHttpConfigurer가 disable 되어있으므로 사용하지 않고, oauth2 로그인만 사용한다. 그 거지같은 oauth 로그인창만 나오는 이유가 이거였어..

 

.formLogin(form -> form.loginPage("/api/login/"))

스프링6에서는 람다 형식으로 이렇게 처리하면 된다.

---

어디로 로그아웃 할까요?

 

                .logout(logout -> logout
                        .logoutSuccessUrl("/")
                );

이역시 스프링6으로 넘어오면서 바뀌었다.

직관적으로 뚜렷하게 알 수 있듯이 로그아웃 시 /로 url을 이동시킨다.

 

그리고 저 코드는 /logout의 POST 요청을 가로챈다. 폼에서 이를 구현해야하는데 이거는 나중에 나온다고

---

막아라 CSRF

CSRF.. 코딩애플님이 한 번 다뤘을 것 같은데 유튜브에 역시 있다.

https://www.youtube.com/watch?v=FG1h4ik53eg

 

CSRF는 Cross-Site Request Forgery (크로스 사이트 요청 위조)의 약어다.

책의 내용과 영상의 내용을 합쳐보면.. 로그인 상태에서 악의적인 코드가 삽입된 페이지를 열고 요청을 보내면 공격대상인 웹사이트에 공격을 보낼 수 있고, 공격대상 웹사이트는 해당 공격요청을 신뢰하게 되는 문제다.

 

영상의 내용을 살펴보자면, 상대방이 자기 사이트에 버튼을 만들고 내 사이트에 회원정보를 탈취하는 코드를 심어놓으면 (버튼에 사용자정보를 가져오는 코드를 넣어두던가...) 내 사이트가 CSRF에 무방비상태라면 그 코드를 신뢰하고 진행시켜버리고, 회원정보를 제공하게 된다.

 

영상에도 나왔지만 이를 방지하는 방법으로 CSRF 토큰을 생성할 수 있다.

토큰 생성 후 로그인 시에는 제출되는 폼에 토큰을 담아 서버로 전송되고, 서버에서는 원래 생성된 토큰과 비교하여 처리한다.

 

비활성화도 가능한데 절대 그러지 말라고한다.

.csrf(csrf -> csrf.disable())

 

 

단, REST API의 경우에는 비활성화해야한다. 그 이유가 CSRF 공격의 전제조건이 맞지 않다는 이유

CSRF 공격은 세션이나 쿠키를 활용하며 폼을 통해 유저의 정보를 받을 때 일어나는데, 내가 개발하는 상황은 세션이나 쿠키를 활용하지 않는 JWT토큰 방식이고, 폼이 아닌 JSON을 통해 유저의 정보를 받는 REST API 개발환경이라 CSRF 공격의 전제조건이 일어나지 않기 때문이다.

 

그리고 CSRF 토큰을 사용하면 이를 프론트 측에서도 알려주고 요청 보낼 때 토큰을 담으라고 요청해야하는데, 이미 JWT 토큰도 보내야하셔서 좀 일만 괜히 늘리는 것 같고.. 암튼 CSRF 토큰을 비활성화하기로 한다.

 

암튼 이정도로 하고...

일대다 관계에서 객체를 여러 메서드에 저장하는 방법도 있는데 그 부분까지는 읽지 않고 5장으로 넘어갈 생각이다.

JDBC를 처음 봤을 때처럼 막 어렵지는 않은데 LDAP 내용이 좀 어려웠다. 하지만 그래도 언젠가는 쓸만한 유용한 기능인 것 같다. LDAP... LDAP의 구조 등 LDAP에 대한 배경지식도 좀 알아놓으면 좋을 것 같다.

 

우선 내일은 JPA도 적용시키고 오늘 배운 시큐리티도 적용시켜볼 예정이다.

한 수요일쯤에 다 완성하고 목금토에 투표서비스까지 개발해서 가면 될듯하다.

 

너무 로그인에만 신경쓰는거 아닌가.. 거의 한 달을 붙잡고 있긴한데

투표 기능부터 개발해야할 것 같기도하다. 로그인은 JDBC를 JPA로 변경시키기만하면 되는데 로그인은 시큐리티도 좀 수정해야하고 기능이 좀 복잡하기에.. 개발도 빨리되는 투표 기능부터 해봅시다.

 

지금은 약간 느리지만 9월이 되면 CRUD16을 얼른얼른 해봅시다.