반응형 Spring/Security8 [Spring Security] 관리자 접근 제어의 모든 것: 인증(401)과 권한(403)의 철저한 격리 및 이중 방어 전략 1. 도입부 (Introduction)백엔드 엔지니어링을 수행하면서 스프링 시큐리티(Spring Security)를 다룰 때 가장 흔하게 범하는 실수는 인증(Authentication)과 인가(Authorization)를 혼동하여 예외 처리를 대충 뭉뚱그려 반환하는 일이다. 사용자가 "자신이 누구인지"를 증명하는 인증 작업(Authentication)과 "증명된 사용자가 특정 자원에 접근할 자격이 있는지" 확인하는 인가 작업(Authorization)은 논리적으로 완전히 격리된 단계다.이 두 개념이 정교하게 분리되지 않으면, 클라이언트(프론트엔드)는 토큰이 만료되어 재로그인 처리를 해야 하는 상황(401 Unauthorized)과 사용자의 권한이 부족하여 권한 부족 안내 토스트를 띄워야 하는 상황(403.. 2026. 5. 22. [Spring Security] ProviderAwareAuthorizationRequestResolver로 구현하는 정교한 OAuth2 보안 전략 1. 도입부 (Introduction)OAuth2 로그인을 구현할 때 많은 개발자가 간과하는 부분이 있다. 바로 "인가 요청(Authorization Request)을 생성하는 시점"이다. 단순히 라이브러리가 만들어주는 URL로 사용자를 리다이렉트시키는 것만으로는 부족하다.플랫폼마다(Google, Naver, Kakao 등) 요구하는 특수 파라미터가 다를 수 있고, 특히 보안이 취약한 환경(모바일, SPA)에서는 PKCE(Proof Key for Code Exchange)라는 추가적인 방어막이 필수적이다. 오늘은 인가 요청이 생성되기 직전, 최전방에서 요청을 가공하고 보안을 강화하는 ProviderAwareAuthorizationRequestResolver의 내부 동작과 그 중요성을 심층 분석해 본다. .. 2026. 5. 14. [Spring Security] OAuth2 로그인 최종장: 토큰 정책과 앱 이동 흐름 이전 게시물에서 유저가 누구인지 판별하고 USER 혹은 NEW_USER라는 깃발(Authority)을 꽂았다면, 이제는 그 깃발을 보고 실제 어떤 열쇠(Token)를 줄 것인지, 그리고 유저를 어떤 문(Redirect)으로 보낼 것인지 결정할 차례다. 이 과정에서 성공 핸들러와 서비스의 완벽한 협업이 핵심이다. [Spring Security] OAuth2 로그인 성공 후: 신규와 기존 사용자를 가르는 설계의 모든 것OAuth2 인증 성공은 끝이 아니라 새로운 데이터 흐름의 시작이다. 서버는 공급자(Google, Naver 등)가 던져준 원본 데이터를 받아서 우리 시스템의 사용자 모델로 연결하고, 상태에 따라 다른 토큰을myblog01150.tistory.com 1. 전체 구조 조망 (The Orches.. 2026. 5. 11. [Spring Security] OAuth2 로그인 성공 후: 신규와 기존 사용자를 가르는 설계의 모든 것 OAuth2 인증 성공은 끝이 아니라 새로운 데이터 흐름의 시작이다. 서버는 공급자(Google, Naver 등)가 던져준 원본 데이터를 받아서 우리 시스템의 사용자 모델로 연결하고, 상태에 따라 다른 토큰을 쥐여줘야 한다. 1. 전체 구조 조망데이터가 어떤 컴포넌트를 거쳐 흘러가는지 전체적인 숲을 보자. 상세 시퀀스 다이어그램이 코드가 돌아가는 순서를 엄격하게 정의하면 다음과 같다. 2. 설계의 5가지 핵심 이론 (Concepts & Theory)단순히 코드를 짜는 것보다 '왜' 이렇게 설계했는지가 중요하다. 이 로직에는 5가지 중요한 아키텍처 원칙이 녹아 있다.정규화 (Normalization): Google과 Naver의 응답 JSON 구조는 완전히 다르다. 이걸 서비스 로직에서 직접 다루면 i.. 2026. 5. 11. [Spring Security] JwtAuthenticationFilter 해부: 인증 문지기의 설계와 역할 분리 Spring Security에서 JWT를 연동할 때 가장 핵심이 되는 컴포넌트는 JwtAuthenticationFilter다.매 요청마다 토큰을 검사하고 사용자를 식별하는 이 '문지기'가 어떻게 동작하고, 왜 즉시 에러를 내뱉지 않는지 그 설계 철학을 정리한다. 1. 핵심 개념 1: OncePerRequestFilter (중복 방어)1) 개념 정의Spring Security 필터 체인 내에서 "하나의 요청당 단 한 번"만 실행되도록 보장하는 필터다. 2) 왜 필요한가?인증 로직은 토큰 파싱, 서명 검증, DB 조회 등 비용이 발생하는 작업이다. 서블릿 내부 포워딩이나 에러 페이지 이동 시 인증 필터가 여러 번 실행되면 불필요한 리소스가 낭비되고, 인증 상태의 일관성이 깨질 위험이 있다. 3) 실무 포인트.. 2026. 5. 9. [Spring Security] 운영 보안 설계 : subject 규약과 Access/Refresh 토큰 분리 단순히 토큰이 "동작한다"는 수준을 넘어, 사용자가 탈퇴하거나 토큰이 탈취되는 등 다양한 실패/공격 시나리오에 대응할 수 있는 운영 가능한 JWT 정책을 정리한다. 1. 핵심 개념 1: subject 규약 (provider:oauthId)1) 개념 정의JWT의 sub(subject)는 토큰의 주인을 나타내는 식별자다. 우리 프로젝트에서는 이를 PROVIDER:OAUTH_ID 형식으로 고정한다.예: GOOGLE:10923847, APPLE:000123.abcxyz 2) 왜 필요한가? (식별의 영속성)공급자별 식별 체계 통합: OAuth 공급자마다 ID 체계가 다르다. 이메일은 사용자가 변경할 수 있고, 탈퇴 후 재가입 시 같은 이메일을 사용할 수도 있어 영구 식별자로 쓰기에 위험하다.충돌 방지: provi.. 2026. 5. 9. 이전 1 2 다음 반응형
