0. 회원가입 플로우1. 소셜 로그인을 진행하고 KakaoId 혹은 GoogleId를 최종적으로 가져온다.2. 소셜ID + ACTIVE 유저가 DB에 있다면 로그인 처리를 진행한다.3. 소셜ID + INACTVIE or 해당 소셜ID로 조회되지 X -> 회원가입 진행을 한다.- 이때 소셜ID를 담고 INACTIVE인 임시 유저를 생성하고 회원가입 단계에서 점차 사용자 정보를 update한다.4. 인증 코드를 받을 학교 이메일을 입력한다.5. 인증 코드를 입력한다.6. 약관 동의를 한다.7. 사용자 추가 정보를 입력한다.- 이때 최종적으로 유저 상태를 ACTIVE로 전환 1. 카카오, 구글 소셜 로그인 구현 중카카오와 구글 로그인을 구현하는 도중 개발하는 서비스 특징 상 고민거리가 발생했다.가치택시에서는 ..

설명가치택시 Spring Security로 인증 인가를 구현하는 중..... 필터 단에서 일어나는 인증 예외를 CustomAuthenticationFilter로 처리하고 있었다. 이때, 불효자 코드로 인해 엣지 케이스가 발생해버리고 마는데....그것은 바로 허용한 경로 permitAll()에 요청할 때, 만료된 토큰을 가지고 있으면 요청이 거부되는 케이스를 발견했다! 기본적으로 Jwt 관련 발급, 검증, 추출 그리고 비지니스 로직은 다음 그림처럼 사용되도록 설계했다. 그리고 JwtExtractor 코드는 다음과 같다. @Componentpublic class JwtExtractor { private static final String ID_CLAIM = "id"; private static f..

1. 세션HTTP는 기본적으로 상태가 없는(stateless) 프로토콜이기 때문에, 서버는 각 요청마다 사용자를 식별할 수 있는 방법이 필요하다.이를 위해 사용자가 로그인하면 "로그인 정보"를 서버(DB)에 저장했다.사용자 식별 문제를 해결됐지만, 서비스 규모가 커지면서 다른 문제가 생겨난다. 단일 서버 하나로는 방대한 사용자 요청을 처리할 수 없다는 것.단일 서버의 크기를 늘리기에는 한계가 있다.이때 고려되는 가장 효율적인 방법은 비슷한 크기의 서버를 여러대 두는 것. 한 서버에 요청이 과도하게 몰리면 다른 서버에 트래픽을 이동시키면 되니까! 이때, 사용자를 식별하는 "로그인 정보"는 각 서버마다 존재하므로, 세션 별 로그인 정보에 불일치 문제가 발생한다.즉, 로그인 요청을 A서버가 처리하면 B서버에서..