Spring Security의 간장공장공장장😱 Authentication? Authorization? Provider? Manager? FilterChain? 쉽게 정리하자

들어가며

  스스로의 학습능력에 근본적인 의문을 갖게 됐던 때를 꼽으라고 하면 아마 스프링 시큐리티를 배웠던 일주일을 얘기할 것 같다. 진지하고 심각하게 읽기능력에 중대한 문제가 생긴 게 아닌지 의심하게 만들던 스프링 시큐리티 섹션...무슨 텅트위스터도 아니고 비슷비슷한 용어에 조금씩 다른 흐름이 나를 미취게 만들었다ㅠㅠ 

 

  시간이 지나 전체적인 흐름을 이해하고, 용어에 익숙해지니 생각보다 괜찮은데 그때는 왜 그렇게까지 두려워했는지 모르겠다. Spring security-token-Oauth로 이어지는 학습이 러닝커브가 큰 편이라고 나중에야 알게 되었지만 지금 정리 안 하면 나중에 다시 봤을 때 그대로 어려울 것 같아 차근차근 정리해보려 한다. 

 

 

 

 

인증 vs 인가

Authentication=인증=신분증

Authorization=인가=입장권

이렇게 생각해보자. 

 

 

신분증을 내고 입장권을 받을 수는 있지만(혹은 신분증이 입장권 역할까지 할 수 있지만)

입장권을 내고 신분증을 받을 수는 없다.

 

이처럼 Authorization을 하기 위해서는 authentication이 먼저 필요하다는 걸 알 수 있다.

 

이 두 단어도 참 헷갈렸는데, 

 

authentic 진정한(검증된) ➡️ authentucation

 

authority권위(권한)➡️authorization 

 

이렇게 외웠다!

 

 

 

 

인증, 인가 처리 흐름과 필터

 

노션에 초대받아 글을 쓰려고 할 때 일어나는 일을 생각해보자. 

 

1. 로그인을 해야 작성할 수 있다

2. 요청한 페이지에 작성권한이 있어야 한다

 

이 두 가지를 내부적으로 검증하기 위해서 우선은 인증 관리자가 필요하다

 

 

인증 관리자

인증관리자는 로그인을 관리한다

알맞은 비밀번호를 입력했다면 통과한다.

이때 비밀번호를 크리덴셜이라고 한다

 

이제는 접근 결정 관리자에게 넘길 차례다.

 

접근 결정 관리자

알맞은 비밀번호를 입력한 사용자, 즉 유효한 크리덴셜을 보낸 사용자의 경우 

접근 권한을 가진 게 맞는지 확인해야 한다

 

 

필터

이렇게 인증 관리자, 접근 결정 관리자와 같이

중간에 요청을 가로채 어떤 처리를 수행하면 이를 필터라고 부를 것이다. 

 

 

 

 

서블릿 필터와 프록시

서블릿 필터

요청이 서블릿 기반 애플리케이션에 들어올 때 

요청이 처리하는 곳에 도달하기 전에 사전 처리를 하게 되는데, 이를 서블릿 필터라고 한다

 

Javax.servlet 패키지의 인터페이스로 정의되어 있고

여러 필터를 메서드 체인처럼 필터체인으로 연결해 쓴다.

 

 

 

 

 

 

DelegatingFilterProxy , FilterChainProxy

proxy 라고 붙어있더라도 둘 다 필터체인 역할을 한다

 

Delgating~: 스프링 시큐리티 필터의 시작점

FilterChainProxy: 스프링 시큐리티 필터의 진입점

 

잠깐 찾아보기로는 유저 요청을 구분하는 게 Delegating~프록시라고 하니

요청을 분류해 필터를 시작하고, 실제로 어떤 액션이 시작되는 지점은 FilterChain프록시구나 정도로 이해했다

 

 

이렇게 시작된 이후에 시큐리티 필터가 적용되면서 인증, 인가 처리가 시작된다.

 

 

 

 

 

인증 처리 흐름

Authentication Filter  위계

authentic한 신분증 검사, 즉 Authentication 과정에는 위계가 있다

상명하달처럼 Filter가 최상위에 있고

Manager

Provider

Service 

순서대로 내려갔다가 다시 올라오면서 인증 처리가 완료된다

 

Authentication 한장으로 정리하기

등장인물: 수험표 용지, 중앙시험관리본부, 감독관, 감독관의 응시자목록

 

수험표 용지= Authentication Token

중앙시험관리본부(감독관 관리사무소)= Authentication Manager (Provider Manager)

감독관= Authentication Provider

감독관의 응시자목록 = User Details

 

응시자가 작성한 수험표 용지( Authentication Token) 는

감독관(Authentication Provider)이 응시자목록(User Details)과 비교해 같을 때에만 인증된다.

 

신분증을 확인하려면 당연히 이름과 주민번호를 받아야 하듯이 

Authentication을 위해 Username과 Password를 받아온다.

 

토익 시험 칠 때 수험표에 인적사항을 적듯이

Username과 Password로 Authentication Token을 우선 생성한다. 

 

그러나 감독관 확인도장이 무조건 있어야 시험을 응시할 수 있는 것처럼 

이때의 Authentication Token은 인증되지 않은 상태다.

 

인증하려면 크리덴셜 저장소에서 조회된 UserDetails와 수험표(Authetication Token)이 대조되어야 한다

 

중앙 시험 본부가 ProviderManager라면, 각 교실의 감독관은 Provider다.

 

Provider인 감독관들에게는 응시자 목록 UserDetails를 조회해 비교하는 임무가 있고

 

만약 일치한다면 도장을 찍게 된다. 

 

이 도장찍힌 수험표도 이름은 Authentication Token으로 같지만, 9번 위의 그림에 나와있듯 Granted~ 로 하나가 더 추가됐다 

 

이렇게 provider가 처리했으니 provider manager로 타고 올라간 Authentication Token은 이후 SecurityContext에 저장된다.

 

 

 

 

 

 

인가 처리 흐름

SecurityContext에 저장된 Authentication을 받아와 두 번째 Authorization 필터가 시작된다.

인증 과정에 비해 훨씬 간단한데, Authentication을 가져와서 그에 match되는 권한을 주는 것이다.

 

방마다 문지기가 있다고 하면, 인증 정보에 따라 어느 문지기에게 가보세요~까지 해주는 게 MatcherManager의 역할이고,

이후 적당한 AuthorizationManager가 권한 부여가 된 사용자인지 체크하게 된다. 즉, 도장을 찍어줄지 말지를 위에서 Provider가 결정했던 것처럼 들여보낼지 말지 결정하는 건 MatcherManager보다 더 말단의 AuthorizationManager다.

 

 

 

 

 

전체 흐름 정리 

인증은 신분증 검사

인가는 입장권 검사다

 

시큐리티 흐름에서 Authentication은 Manager->Provider->UserDetailsService를 거쳐 확인받게 되고

Authorization은 RequestMatcher Manager->Authorization Manager를 거쳐 권한을 확인받는다.

 

 

 

나가며

Jwt에서도 꾸준히 헷갈렸던 용어들을 한번에 비유와 함께 정리하니 속이 다 시원하다..!

들었던 설명이나 비유가 잘 와닿았다면 기쁠 것 같다. 궁금한 부분이나 틀린 내용이 있다면 댓글 달아주시길..!!

나도 능숙하게 jwt와 Oauth까지 활용해서 로그인, 회원가입 구현하고 싶다.... 후

시큐리티 아자자!