2025-08-21

1일 1아티클

데보션

Spring Security 보완방법

문제 상황

• 여러 필터의 연계 및 우선순위 조정 어려움
  • Form Login, Basic Auth, OAuth 등 여러 인증 수단을 사용해도 동일 수준의 접근 제어 및 세션 관리 규칙 적용 필요
    • ex. 한 서비스에 UserDetails 기반의 Username/Password 인증 방식과 Spring Authorization Server 기반 OAuth 인증 방식 통합 시 필터 체인 우선순위 및 인증 흐름 재정렬 필요
  • 직접 구현 시 프로젝트마다 복잡한 보안 설정 반복, 서비스 증가에 따른 유지보수 부담 급증
  • 통합적이고 일관된 인증·인가 체계 구축 어려움

Fortel

• SK 사내 전용 Spring Security 확장 라이브러리
• 작동 순서
  1. 세션을 먼저 검증하는 SessionResolver → 세션 정책(동시 로그인 제한, 미인증 접근 처리 등) 선적용
  2. AuthenticationConverter → AuthenticationManager → Authorization 순서로 인증 및 인가 수행
     • AuthenticationConverter : Form/Basic/OAuth 등 다양한 인증 입력도 단일 파이프라인으로 수용
     • Authentication의 principal : UserDetails 기반 도메인 모델로 일관된 사용
• 특징
  • YAML 기반 인증·인가 구성
  • 여러 인증 방식(Form/JSON Login, Basic Auth, OAuth) 지원
  • 세션 및 리소스 제어 내장
  • AccessGateFilter 중심 구조
  • Spring Security에 자연스러운 통합 (FilterChain 재정의 X)

  서비스마다 다른 인증 방식을 사용해도 일관된 보안 정책 유지 가능
  → 개발자는 복잡한 설정 작업을 줄이고, 핵심 비즈니스 로직 및 사용자 경험에 집중 가능

이전에 했던 프로젝트에서, 이분처럼 일반 로그인과 OAuth 로그인에 대해 동일한 인증 및 인가 정책을 처리하기 위해 Spring Security를 뜯어보고, 사용자 정의 Filter를 추가하고 UserDetails를 통해 단일화하는 작업을 했었다. 이 과정에서 많은 시간적 비용이 소모되었던 경험이 있는데, 이를 확장하여 라이브러리화하는 것이 어떻게 보면 객체를 추상화하듯 하는 느낌이 들었다.

오늘 배운 것

1. 알고리즘
   • 위상정렬
   • swea 1267 작업 순서
   • ‘최단’ → bfs 고려 (dfs는 완탐)
   • bfs(초기값 방문, 큐 순회 과정에서 방문)와 dfs(들어가서 바로 방문) 때 방문 처리 위치 확인

내일 할 일

1. 상담 피드백 바탕으로 포트폴리오 수정 (주말까지는 완료)

참고자료

• Fortel: 사내 인증 표준화 및 단순화를 위한 Spring Security 확장 라이브러리