지난 글에서 Access Token은 짧게, Refresh Token은 길게 가져가는 이유를 정리했다. 티켓 예매 프로젝트(Ticket Run)의 재발급 API를 만들면서 바로 다음 고민이 생겼다.Refresh Token은 수명이 긴 만큼, 한 번 탈취되면 피해도 길다. 그래서 "브라우저의 어디에 두느냐"가 Access Token보다 훨씬 중요해진다.처음에는 localStorage, 쿠키, 메모리 중 하나를 고르는 문제처럼 보인다. 하지만 핵심은 브라우저 저장 위치는 크로스 사이트 스크립팅(Cross-Site Scripting, XSS)과 사이트 간 요청 위조(Cross-Site Request Forgery, CSRF) 같은 탈취 경로를 줄이는 문제이고, 서버 저장은 탈취 이후를 통제하는 문제라는 점이다..

최근 티켓 예매 프로젝트(Ticket Run)에서 소셜 로그인 이후의 인증을 JWT로 구현하면서 Access Token과 Refresh Token을 함께 발급하게 되었다.처음 접하면 "토큰 하나로 인증하면 되는데 왜 두 개나 필요할까?"라는 의문이 든다. 둘 다 서버가 발급하는 토큰이고, 둘 다 만료 시간이 있기 때문이다.하지만 핵심 차이는 Access Token은 API를 호출할 때 쓰고, Refresh Token은 Access Token을 다시 받을 때만 쓴다는 점이다.이 글에서는 Access Token만 쓸 때 생기는 문제를 기준으로 두 토큰이 무엇이고 왜 함께 쓰는지를 정리한다(저장 위치는 다음 글에서 다룬다).간단히 정리하면- Access Token : 보호된 API에 접근할 때 매 요청마다 ..

공연 예매 서비스 Ticket Run의 회원 기능을 만들면서, 자체 회원가입 없이 카카오와 구글 로그인만 제공하기로 했다. (Spring Boot 4.1, Spring Security 7.1 기준)처음 헷갈렸던 지점은 두 가지였다. 카카오와 구글이 같은 "소셜 로그인"인데 왜 처리 방식이 다른가, 그리고 소셜 로그인을 했는데 왜 토큰을 또 발급하는가였다.카카오는 OAuth 2.0으로, 구글은 그 위에 신원 확인을 얹은 OpenID Connect(OIDC)로 연동한다. 하지만 핵심 차이는 제공자별 방식이 아니라, 소셜 로그인이 "누구인지 확인"까지만 맡고 API 접근 자격은 우리 서버가 발급한 JWT로 따로 증명한다는 점이다.이 글에서는 카카오, 구글 앱 등록과 키 발급을 마쳤다는 가정하에, 제공자 연동부..

티켓 예매 서비스 프로젝트에 카카오, 구글 소셜 로그인을 붙이기로 하면서 OAuth 2.0을 먼저 정리하게 되었다. 실제 백엔드 적용은 다음 글에서 다룬다.이 글에서 다룰 개념은 다음과 같다.OAuth 2.0Resource Owner / Client / Authorization Server / Resource ServerAuthorization Code GrantAccess Token / Refresh Token / scopeOpenID Connect처음 접하면 "소셜 로그인 = OAuth 2.0"이라고 생각하기 쉽다. 그래서 OAuth 2.0을 로그인(인증) 기술로 오해하는 경우가 많다.하지만 핵심 차이는 OAuth 2.0이 "누구인지 확인하는" 인증이 아니라 "무엇을 해도 되는지 허락하는" 인가 프레..

최근 티켓 예매 프로젝트에서 JWT 로그인을 붙이기 전에, Spring Security 기본 설정과 인증 실패 응답을 먼저 정리하게 되었다.이 글에서 다룰 개념은 다음과 같다.Spring SecuritySecurityFilterChainAuthenticationEntryPoint / AccessDeniedHandler@EnableMethodSecurity처음 접하면 의존성만 추가해도 보안이 "알아서" 적용되기 때문에, 굳이 설정 클래스를 만들어야 하는 이유가 잘 보이지 않는다.하지만 핵심은 기본 설정이 폼 로그인과 세션 중심이라서, 토큰으로 인증하는 REST API 서버에는 그대로 맞지 않는다는 점이다.간단히 정리하면- Spring Security : 서블릿 필터 체인으로 인증과 인가를 ..

티켓 예매 프로젝트의 공통 패키지를 세팅하면서, 모든 엔티티가 상속할 BaseEntity 에 생성일과 수정일을 자동으로 채우도록 JPA Auditing을 설정하게 되었다. 이번 글에서 다룰 개념은 다음과 같다.@EnableJpaAuditing@EntityListeners(AuditingEntityListener.class)@CreatedDate, @LastModifiedDateJpaAuditingConfig (별도 @Configuration)@MockitoBean (테스트 쪽 우회 방법) 처음 설정할 때 헷갈리는 지점은 @EnableJpaAuditing 을 어디에 붙이느냐다. 검색하면 메인 클래스에 바로 붙이는 예제가 많고, 애플리케이션도 그대로 잘 실행된다. 그런데 컨트롤러 슬라이스 테스트인 @WebM..