sunm2n.log

[Auth] 로그인 구현 대신 SaaS 서비스 도입에 대한 고찰

이번 UMC 데모데이를 하면서 로그인 구현 파트를 담당했다. 이번에 인증/인가에 대해 제대로 알고 완벽하게 구현을 해보자! 라는 생각으로 구현을 시작했다. | 항목 | 설명 | 상태 ||------|------|------|| OAuth CSRF 보호 | state 파라미터로 요청 검증 (Redis 저장, 일회성 사용) | 일회성 코드 교환 | 토큰이 URL에 노출되지 않음, getAndDelete()로 atomic 처리 | AT 블랙리스트 | 로그아웃 시 AT 즉시 무효화 | RT 재사용 공격 방지 | Redis 저장된 RT와 불일치 시 즉시 무효화| RT 유효성 검증 | JWT 서명, 만료시간, Redis 존재 여부 3단계 검증 | SecureRandom 코드 생성 | 예측 불가능한 인증 코드 | 짧..

로그인 화면의 주도권을 백과 프론트 중 어디에서 가지고 있을 것인가에 대해서 auth2 로그인을 할 때 구현 방식이 달라진다. 서버 사이드 리다이렉트(302 응답)과 JSON으로 URL 반환(프론트에서 이동) 이렇게 2가지의 방식으로 분류할 수 있다. 최근 SPA(React, vue등)에서는 후자의 방식이 더 좋다고 한다. 왜 그런지 알아보자 1. 두 방식의 작동 원리 비교1-1. 서버 사이드 리다이렉트 (Server-Side Redirect) - 전통적인 방식Spring Security의 기본 설정(oauth2-client)이 주로 이 방식이다. Front: 사용자가 '구글 로그인' 버튼( 태그)을 클릭한다.href="http://api.server.com/oauth2/authorization/go..

https://sunm2n.tistory.com/78 [Test] H2 대신 Testcontainers 도입하기보통 나와 같은 학생들이 프로젝트를 진행할 때 테스트 코드를 짤 때 어떤걸 고려하면 좋을까? 일단 안짠다. (마감 기한 맞추고 버그 잡다보면 테스트 코드는 뒷전이다.) 하지만 테스트 코드는sunm2n.tistory.com 저번에 Testcontainers 도입을 하였다. 그 당시에는 필자는 postgres만 도입을 한 상태였고 추후에 redis도 필요하여 redis도 추가하게 되었는데 동일하게 하면 되겠지? 했지만 약간의 추가적인 세팅이 필요했다. 동작 방식에 대해서 알아보고 왜 세팅에서 차이가 발생했는지 알아보자. 1. @ServiceConnection의 내부 동작 원리// 1단계: Spr..

보통 나와 같은 학생들이 프로젝트를 진행할 때 테스트 코드를 짤 때 어떤걸 고려하면 좋을까? 일단 안짠다. (마감 기한 맞추고 버그 잡다보면 테스트 코드는 뒷전이다.) 하지만 테스트 코드는 굉장히 중요하고 요즘 바이브 코딩이 대세가 되면서 오히려 테스트 코드를 먼저 작성하여 AI가 짜준 코드를 검증하는 도구로 많이 사용한다. (TDD 방식) 테스트 시 가장 기본적인 것은 운영 환경의 데이터베이스에 절대 접근을 하면 안되고 별도로 분리된 테스트 용 데이터베이스에 접근을 해야하는 것이 기본중에 기본이다. 그리고 이를 위해 보통 가벼운 H2를 많이 쓴다. 하지만 오늘은 다른 방식으로도 테스트 용 데이터베이스를 설정하는 방법을 소개해보고자 한다. https://testcontainers.com Testconta..

일반적인 RDBMS(예: MySQL, Oracle)를 사용해 왔다면 다소 의아할 수 있지만, PostgreSQL에서는 VARCHAR(n)보다 TEXT (혹은 길이 제한 없는 VARCHAR)를 사용하는 것을 권장하거나, 적어도 성능상의 불이익이 전혀 없다고 한다. 왜 그럴까? 이유를 보자 1. 내부 구현의 동일성 (Under the Hood)가장 핵심적인 이유는 PostgreSQL 내부에서 두 타입이 처리되는 방식이 완전히 똑같기 때문이다.구조: PostgreSQL 엔진 입장에서 VARCHAR(n), VARCHAR, TEXT는 모두 내부적으로 동일한 데이터 구조(varlena)를 사용한다.차이점: 유일한 차이점은 VARCHAR(n)의 경우 데이터를 저장할 때 "길이가 n을 넘는지 확인하는 CPU 사이클(유..

우리가 프로젝트를 하면 보통 토큰 기반 방식의 로그인을 가장 많이 구현한다. 현재 가장 일반적으로 쓰는 방식은 리프레시 토큰 전략이다. 이때 내가 이쪽 파트 개발을 맡았다면 엑세스 토큰과 리프레시 토큰을 각각 어디에 저장해야 할지 고민해야 한다. 먼저 크게 저장 방식을 3가지로 나눠서 비교 분석을 해보겠다. 1. 토큰 저장 전략별 비교 분석방식 1: 둘 다 DB(RDB)에 저장가장 전통적이고 데이터의 지속성(Persistence)을 중시하는 방식이다.장점: 데이터가 안정적으로 보관되며, 사용자의 로그인 이력이나 기기 정보 등 상세한 감사(Auditing) 데이터를 함께 관리하기 쉽습니다. 갑작스러운 서버 장애에도 로그인이 유지된다.단점: 매 요청(Access Token 검증 시) 혹은 리프레시 요청 시마..