작업 일지#5 서비스에 Security를 적용해보자 -1-

개요

프로젝트를 진행하면서, 자연스럽게, 사용자 보안 인증에 대해 관심이 가게 되었다. 기본적으로 블로깅을 해보니, 인증 방식은 대부분 JWT 혹은 form으로 아이디/비밀번호를 받아, 세션ID를 쿠키에 저장하는 방식이다. 둘 중에 하나를 선택하면 될 것 같았지만, 세션 ID를 쿠키에 저장하자니, 앱 환경에서는 인증이 어려운 상황이고, JWT의 경우는 세션 서버를 따로 운영할 필요가 없지만, 토큰에 인증정보를 포함하면서, 생기는 보안의 취약점이 신경 쓰였다. 그래서 결국엔 세션ID를 Token에 포함하여, 인증을 세션 서버를 통해, 비교적 안전하게 진행하는 방식을 채택하기로 했다.

인증 방식의 종류와 차이점

자세한 내용은 이전에 정리했던 문서를 참고해보면 좋다. https://postwithmemory.tistory.com/7

session과 JWT의 차이를 한 문장으로 정리해보면, 인증을 타이트하게 하느냐, 느슨하게 하느냐.. 따라서 세션 DB가 필요하느냐 아니냐의 차이라 할 수 있을 것 같다.

Spring Security란?

스프링 시큐리티는 종합적인 보안 솔루션을 제공하는 Pivot의 보안 관련 프레임워크로, 인증, 인가, 리소스 필터링 등, 여러가지 보안 관련 api를 제공한다. 자세한 내용과 컨셉은 공식 문서를 참고하도록 하자

https://docs.spring.io/spring-security/site/docs/current/reference/html5/#introduction

Security를 프레임워크로 진행한 이유?

사실 Security가 없어도, 인증 서비스를 제공하는 것은 가능하다. 게다가 대부분 Security 관련 프레임워크는 생각보다 복잡하고, 프레임워크를 익히기 위한 러닝커브가 발생한다. 그래서 어떻게 보면, Security 프레임 워크를 적용하느라, 프레임워크를 학습하는 것 자체가 시간 낭비일(?) 수 있다. 그럼에도 Security 프레임워크를 적용하게 된 이유는 다음과 같다.

• 여타 다른 웹기반의 프레임워크를 적용하는 이유와 동일하게, 서비스 로직에 집중하기 위함이다.
• 보안 자체를 이해하고 적용하기엔, 범위가 너무 넓은데, 이미 프레임워크로 솔루션이 제공된 상황에서, 스스로 보안 로직을 따로 구현하는 것은 결과적으로 바퀴를 재발명하는 것과 크게 다를 게 없다.
• Spring Security의 경우, 어렵지만, 튼튼하고, 안정적이고, 추상화가 잘 되어 있어, 보안 이라는 횡단 관심사를 서비스와 분리시키는게 좀 더 편리하다.

Security가 필요한(혹은 관여하는) 부분은?

크게 보면 다음과 같을 수 있다.

• 인증
  • 로그인
  • 회원가입
• 인가
  • 리소스 접근 권한(인증 정보가 필요한 리소스, 혹은 특정 권한을 요구하는 리소스)

Security 로직 플로우 차트

위에서 정리한 Security가 필요한(혹은 관여하는) 부분들을 시큐리티에 직접 적용하기 전에, 먼저 다음과 같이 플로우 차트를 정리해 보았다.

로그인

회원가입

인증을 요구하는 리소스 접근

마무리

이번 문서에서는 Spring Security에 대해 간단히(매우 간단히...) 정리 해보고, 왜 적용 해야하는지, 그리고 무엇을 적용 해야하는지에 대해, 간단히 정리를 해보았다. 현재는 이 정리한 문서를 바탕으로 Security 로직을 적용하고 있는데, 생각보다, 시간이 지체되어, 문서를 이렇게 끊어서 올리게 되었다. 다음 일지에는 Security의 구성요소와 이 구성요소를 나의 로직에 어떻게 적용했는지에 대한 내용을 정리 해보겠다.