[Spring] Spring Security?

IToriginal·2023년 3월 11일
0

Spring Boot

목록 보기
1/3
post-thumbnail

Web 프로젝트를 진행하며 Spring Security + JWT에 대해서 궁금증이 생겼다.

웹/앱 어디서든 회원의 관리를 하고, 그에 따른 인증과 인가에 대한 처리를 해주어야 한다. Spring에서는 Spring Security라는 별도의 프레임워크에서 관련된 기능을 제공하고 있다.

Spring Security

Spring Security는 Spring 기반의 애플리케이션의 보안(인증과 권한, 인가)을 담당하는 프레임워크 이다.
보안과 관련해서 체계적으로 많은 옵션을 제공해주기 때문에 개발자의 입장에서 일일이 보안 관련 로직을 만들지 않아도 되는 강점이 있다.
Spring Security는 '인증'과 '권한'에 대한 부분을 Filter 흐름에 따라 처리한다.

👨🏻‍💻 Spring Security를 사용하기 전에 알아야 할 개념

🧐 인증(Authenticatoin)이란 무엇일까?

해당 리소스에 대해서 작업을 수행할 수 있는 주체인지 확인하는 것이다.
예를 들어 어떤 커뮤니티가 있다. 이 커뮤니티에서는 사용자와 회원간에 보기 권한은 없다. 단지 쓰기에 대한 작업 권한이 회원이어야 한다는 차이는 가지고 있다.
이 커뮤니티에서는 사용자가 게시판의 글을 보는 것은 로그인을 하지 않아도 되지만, 댓글을 작성하려면 로그인을 해야 한다.
그런데, 사용자가 회원인지 아닌지를 어떻게 확인할 수 있을까?
이렇게 자격을 증명 하는 과정이 인증이다.
(Spring Security는 세션(session)과 쿠키(cookie)방식으로 인증한다.)

🧐 인가(Authorization)란 무엇일까?

인가는 인증 과정 이후에 일어난다. 인증 → 인가
커뮤니티를 관리하는 관리자 페이지에 접근하는 URL을 입력 했을 때 해당 URL은 커뮤니티의 관리자만 접근할 수 있어야 한다. 이때 접근하는 사용자가 인가된 회원인지를 검사하는 것으로 일반적으로 권한을 확인하는 작업이다. 쉽게 생각해서 유저 대한 권한을 줘서 허락 하는 개념으로 이해하면 쉬울 듯하다.

🧐 필터(Filter)란 무엇일까?

필터는 체인처럼 엮어있기 때문에 필터 체인이라고도 불린다. 모든 request는 이러한 필터 체인을 반드시 거치게 된다. (spring security는 filter 기반으로 동작하기 때문에(AOP) spring MVC와 분리되어 관리 및 동작한다.)
Filter는 Dispatcher Servlet으로 가기 전에 적용되므로 가장 먼저 URL 요청을 받지만, (Web Container에서 관리) Interceptor는 Dispatcher와 Controller 사이에 위치한다는 점에서 적용 시기의 차이가 있다.(Spring Container에서 관리)

Client (request) → Filter → DispatcherServlet → Interceptor → Controller
(실제로 Interceptor가 Controller로 요청을 위임하는 것은 아니고, Interceptor를 거쳐서 가는 것)


Spring Security는 기본적으로 인증 절차를 거친 후에 인가 절차를 진행하게 되는데 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지를 확인하게 된다.

👨🏻‍💻 Spring Security의 내부 구조

🧐 SecurityContextHolder

SecurityContext를 제공하는 static 메소드(getContext)를 지원한다.

🧐 SecurityContext

SecurityContext 는 접근 주체와 인증에 대한 정보를 담고 있는 Context 이다.

🧐 Authentication

Principal과 GrantAuthority를 제공한다. 인증이 이루어지면 해당 Athentication이 저장된다.

🧐 Principal

유저에 해당하는 정보이다.대부분의 경우 Principal로 UserDetails를 반환한다.

🧐 GrantAuthority

ROLE_ADMIN, ROLE_USER 등 Principal이 가지고 있는 권한 을 나타낸다.

prefix로 ROLE_이 붙는다.
인증 이후에 인가를 할 때 사용하고, 권한은 여러개 일수 있기 때문 Collection<(GrantedAuthority)>형태로 제공한다.
ex) ROLE_DEVELOPER, ROLE_ADMIN

👨🏻‍💻 Spring Security 로그인 인증처리 과정

[1] 사용자가 로그인 정보와 함께 인증 요청을 한다.(Http Request)
[2] AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성한다.
[3] AuthenticationManager의 구현체인 ProviderManager에게 생성한 UsernamePasswordToken 객체를 전달한다.
[4] AuthenticationManager는 등록된 AuthenticationProvider(들)을 조회하여 인증을 요구한다.
[5] 실제 DB에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨준다.
[6] 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보인 UserDetails 객체를 만든다.
[7] AuthenticationProvider(들)은 UserDetails를 넘겨받고 사용자 정보를 비교한다.
[8] 인증이 완료되면 권한 등의 사용자 정보를 담은 Authentication 객체를 반환한다.
[9] 다시 최초의 AuthenticationFilter에 Authentication 객체가 반환된다.
[10] Authenticaton 객체를 SecurityContext에 저장한다.

최종적으로 SecurityContextHolder는 세션 영역에 있는 SecurityContext에 Authentication 객체를 저장한다.
사용자 정보를 저장한다는 것은 Spring Security가 전통적인 세션-쿠키 기반의 인증 방식을 사용한다는 것을 의미한다.


🔗 Reference data

  1. https://velog.io/@mooh2jj/Security-%EC%9D%B8%EC%A6%9D%EC%9D%B8%EA%B0%80%EC%B2%98%EB%A6%AC
  2. https://mangkyu.tistory.com/76
  3. https://dev-coco.tistory.com/174
profile
👾ISTP의 개발자 도전기🧐

0개의 댓글