Spring Security 설정과 필터 체인, OAuth2·JWT 기반 인증·인가 아키텍처를 실무 관점에서 다룹니다.
현대 웹 애플리케이션에서 소셜 로그인(Social Login)은 선택이 아닌 필수 기능이 되었습니다. 사용자 입장에서는 귀찮은 회원가입 절차를 건너뛸 수 있어 편리하고, 서비스 제공자 입장에서는 비밀번호 관리의 부담을 덜고 검증된 사용자 정보를 얻을 수 있다는 확실한 이점이 있기 때문입니다. 하지만 개발자 입장에서 소셜 로그인을 처음 구현하려고 하면 마주치는 장벽이 꽤 높습니다. “OAuth 2.0 프로토콜은 무엇이고, 리다이렉트 URI는 … 더 읽기
지난 포스팅들을 통해 우리는 사용자의 신원을 증명하는 인증(Authentication) 과정을 마스터했습니다. 세션과 JWT 중 아키텍처를 선택하고, 필터 체인을 커스텀하여 토큰을 검증하는 단계까지 구축했습니다. 이제 우리는 “이 사용자가 누구인가?”라는 질문을 넘어, “이 사용자가 무엇을 할 수 있는가?“라는 인가(Authorization, 권한 부여)의 영역으로 진입해야 합니다. 많은 초급 개발자들이 인증과 인가를 혼동하거나, 단순히 hasRole(‘ADMIN’) 정도의 간단한 설정으로 보안을 마무리하곤 합니다. 하지만 실무 비즈니스 로직은 … 더 읽기
Spring Security의 진입 장벽이 높은 가장 큰 이유는 바로 ‘필터 체인(Filter Chain)‘이라는 독특한 아키텍처 때문입니다. 이 구조를 이해하지 못하면 단순히 코드를 복사해서 붙여넣는 수준을 벗어날 수 없습니다. 오늘은 이 블랙박스를 열어 내부 구조를 파악하고, 원하는 위치에 나만의 로직을 심는 방법을 마스터해 보겠습니다. Spring Boot로 개발을 진행하다 보면, spring-boot-starter-security 의존성을 추가하는 순간 모든 API 요청이 차단되고 로그인 페이지로 … 더 읽기
지난 포스팅에서 우리는 MSA 및 모바일 환경에서의 확장성을 위해 JWT(Json Web Token) 기반의 인증 아키텍처를 선택하는 것이 유리함을 확인했습니다. 하지만 동시에 JWT가 가진 치명적인 약점인 ‘한번 발급되면 서버가 제어할 수 없다(Stateless)’는 딜레마에 대해서도 논의했습니다. 만약 유효기간이 긴 Refresh Token이 해커에게 탈취당한다면 어떻게 될까요? 해커는 그 토큰이 만료될 때까지 유유히 Access Token을 재발급받으며 사용자의 계정을 마음대로 … 더 읽기
웹 서비스의 규모가 커지고 아키텍처가 모놀리식(Monolithic)에서 마이크로서비스(MSA)로 진화함에 따라, 개발자들이 가장 먼저 마주하는 난관 중 하나는 바로 ‘인증(Authentication) 시스템의 설계‘입니다. 과거 단일 서버 시절에는 별다른 고민 없이 사용하던 세션(Session) 방식이, 서버가 여러 대로 늘어나고 도메인이 분리되는 통합 계정 환경에서는 확장성의 발목을 잡는 주범이 되기도 합니다. 이에 대한 대안으로 JWT(Json Web Token)가 표준처럼 자리 잡았지만, JWT가 만능열쇠는 아니며 … 더 읽기