Develop

32일차_Spring-security 인증/인가 실습 본문

백엔드/KDT_Programmers

32일차_Spring-security 인증/인가 실습

230801 2025. 4. 17. 02:06

안녕하세요 .ᐟ

 

오늘은 데브코스 32일차 (7주3일차) 입니다.

말로만 듣던 스프링 시큐리티로 인증/인가 실습을 진행해보았는데요 .ᐟ 신기했습니다.

메서드명이 엄청길고 ..오 회원가입을 이렇게 처리하는구나 , 접근권한을 이렇게 막는구나 를 느꼈습니다.

디펜던시 주입하고, 필터 걸고, 코드작성하고, 역할별로 인덱스 페이지 다르게하고, 테스트코드 작성하고, 로컬에서 url 로 접근해보고 했습니다.

 

 


 

스프링 시큐리티

인증 및 인가 정보를 보관하고 관리하는 구조로, 스프링 시큐리티는 이 모든 과정을 서블릿 필터 체인 기반으로 처리하며 DispatcherServlet 이전 단계에서 보안 필터들이 먼저 작동한다

  • 인증: 리소스 접근 사용자의 신원 파악
  • 인가: 인증된 사용자가 특정 권한을 가지고 있는지 판단

 

왜 써야 하는가

기존의 세션 기반 인증 방식에는 한계가 존재

  • 세션은 서버 내부에서만 접근 가능
  • API Gateway나 서버 다중 구성 환경에서는 세션 공유가 어렵고 비효율적
  • 사용자 정보를 서버가 직접 보관하지 않고, 토큰 인증 방식으로 외부화할 필요가 있음
  • 시스템 아키텍처가 바뀌어도 핵심 인증 로직을 바꾸지 않기 위해 스프링 시큐리티 도입 => 유연한 인증 인가 처리를 위함

 


 

인증(Authentication)

1. 회원가입 → 사용자 등록

  • SignupForm.java: 사용자 입력 폼 데이터를 담고 @Valid로 유효성 검증
  • MemberService.java:
    • PasswordEncoder를 사용해 비밀번호를 BCrypt 방식으로 암호화
    • MemberRepository를 통해 DB에 회원 정보 저장
    • 추가로 MemberInfo도 함께 저장하여 부가 정보 관리

 

2. 로그인 요청 → 인증 시도

  • signin.jsp: 사용자 입력으로 로그인 요청
  • UsernamePasswordAuthenticationFilter: 필터가 username/password 추출 후 AuthenticationManager에 인증 위임

 

3. 사용자 정보 조회 → 인증 객체 생성

  • AuthService.java: UserDetailsService 구현체, DB에서 사용자 조회
  • Principal.java: UserDetails 구현체, Spring이 내부적으로 사용하는 사용자 정보 제공

 

4. 인증 성공 → 보안 컨텍스트 저장

  • SecurityContextHolder: 인증된 Authentication 객체를 저장해 이후 요청에도 사용

 


 

인가 (Authorization)

1. 권한 부여

  • Role.java: ROLE_USER, ROLE_ADMIN 등 권한 Enum 정의
  • MemberService.java: 회원가입 시 사용자 권한 부여

 

2. 요청 시 권한 체크

  • SecurityConfig.java: authorizeHttpRequests()로 경로별 권한 제한 설정
  • 예: /admin/**hasRole("ADMIN")
  • FilterSecurityInterceptor: 최종 권한 검사 담당 (Spring Security 내부 필터)

 

3. 인가 실패 → 예외 처리

  • ExceptionTranslationFilter:
    • 인증 안 된 사용자 → 로그인 페이지로 리다이렉트
    • 권한 없는 사용자 → 403 에러 발생

 

4. 화면에서 권한 기반 처리

  • JSP에서 권한 체크

 

아 왜 비슷비슷해보이죠..

정처기 라이브 특강 4시간 듣고 블로그 쓰려니까 눈에 너무 안들어오네요

 

오늘도 고생하셨습니다..