이전에 했던 영화 리뷰 커뮤니티 프로젝트에서의
Spring Security 로그인 과정을 흐름을 통해 개념을 확고히 해보자.
스프링 시큐리티
스프링 시큐리티는 다양한 방식으로 사용자 정보를 유지할 수 있는 방법을 제공하는데, 스프링 부트와 결합하면 최소한의 설정만으로도 처리할 수 있습니다. 해당 프로젝트에서는 세션을 기반으로 사용자 정보를 서버에서 보관하고, 필요한 경우에 설정을 통해서 제어하도록 구성합니다.
스프링 시큐리티 용어와 흐름
스프링 시큐리티의 동작에는 여러 개의 객체가 서로 데이터를 주고받으며 이루어진다.
간단한 흐름
- Authentication Manager(인증 매니저) : 핵심 역할
- Authentication Provider : 인증 매니저가 어떻게 동작해야 하는지를 결정
- UserDetailsService : 실제 인증이 이루어진다.
// 인증(Authentication) : 자신을 증명하는 것
// 인가 : 일종의 허가
필터와 필터 체이싱
- 필터(Filter)는 서블릿이나 JSP에서 사용하는 필터와 같은 개념이다. But 스프링 시큐리티 에서는 스프링의 빈과 연동할 수 있는 구조로 설계되어있다.(일반적인 필터는 스프링의 빈을 사용할 수 없기 때문에 별도의 클래스를 상속받는 형태가 많다.)
- 스프링 시큐리티의 내부에는 여러 개의 필터가 Filter Chain이라는 구조로 Request를 처리하게 된다.
- 개발 시에 필터를 확장하고 설정하면 스프링 시큐리티를 이용해 다양한 형태의 로그인 처리가 가능하게 된다.
- 스프링 시큐리티의 주요 필터
인증을 위한 AuthenticationManager
-
필터의 핵심적인 동작은 AuthenticationManager를 통해 인증(Authentication)이라는 타입의 객체로 작업하게 된다.
-
AuthenticationManager가 가진 인증 처리 메서드는 파라미터도 Authentication 타입으로 받고 리턴 타입 역시 Authentication이다.
-
전달된 ID/PW로 실제 사용자에 대해 검증하는 행위는 AuthenticationManager(인증매니저)를 통해 이루어진다.
-
실제 동작에서 전달되는 파라미터는 UsernamePasswordAuthenticationToken과 같이 토큰이라는 이름으로 전달된다. => 스프링 시큐리티 필터의 주요 역할이 인증 관련된 정보를 토큰이라는 객체로 만들어 전달
-
예제 코드
-> request를 이용해 사용자의 ID/PW를 받아 UsernamePasswordAuthenthenticationToken 이라는 객체를 만들고 이를 AuthenticationManager의 authenticate()에 파라미터로 전달한다. AuthenticationManager는 다양한 방식으로 인증처리 방법을 제공해야 한다.
AuthenticationManager는 이런한 처리를 AuthenticationProvider로 처리한다.
AuthenticationProvider는 전달되는 토큰의 타입을 처리할 수 있는 존재인지 확인하고 이를 통해 authenticate()를 수행하게 된다
- AuthenticationProvider와 하위 구현 클래스
- AuthenticationProvider는 내부적으로 UserDetailsService를 이용한다.
UserDetailsService는 실제로 인증을 위한 데이터를 가져오는 역할을 한다.
인가(Authorization)와 권한/접근제한
- 인가(Authorization)는 '승인'
* 필터에서 호출하는 AuthenticationManager에는 authenticate()라는 메서드가 있는데 이 메서드의 리턴값은 Authentication이라는 '인증' 정보이다.- 이 인증 정보 내에는 Roles라는 '권한'에 대한 정보가 있다. 이 정보로 사용자가 원하는 작업을 할 수 있는지 '허가'하게 되는데 이러한 행위를 Access-Control(접근 제한) 이라 한다.
- AuthenticationProvider에서 만일 올바른 사용자라고 인증되면 사용자의 정보를 Authentication 타입으로 전달한다. 전달된 객체로 사용자가 적절한 권한이 있는지 확인하는 '인가' 과정을 거치게 된다.
배운점
기존의 만들었던 로그인 과정보다 스프링 시큐리티를 사용하니 Thymeleaf의 스프링 시큐리티 함수를 사용하여 로그인 여부를 html 부분에서 확인할 수 있는 것처럼 확장성 면에서 장점을 느꼈다. 스프링 시큐리티를 사용하지 않는다면 인터셉터, 필터 기반의 보안 기능을 구현하여야 하는데 훨씬 개발에 용이하지 않았나싶다.
하지만 다시봐도 로그인 과정을 완전히 이해하기는 쉽지 않은 것 같다. 좀 더 이 부분은 반복 학습을 해야겠다.
