sunm2n.log

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

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

[데모데이] 회고 #0

어느덧 데모데이를 시작한지 약 1달의 기간이 지났다. 사실 매주 회고를 적으려고 했지만 바쁜 회사 생활과 병행을 하다보니 까먹었다. 뒤늦게나마 반성을 하면서 지금까지의 회고 및 나의 솔직한 심정을 이야기 하고자 한다. 1. 팀원을 잘 만나야 한다.여름 방학때 멋사 부트캠프를 하면서 절실하게 느꼈다. 어떤 프로젝트를 하느냐도 중요하지만 어떤 사람들과 함께 하는지가 가장 중요하다는 것을 항상 느꼈다. 부트캠프때도 그렇고 이번 데모데이에서도 팀을 고를 때 나의 0순위는 무조건 어느 팀에 가야 좋은 사람들을 만날 수 있을까가 나의 최대 관심사였다. 지금하고 있는 프로젝트의 PM을 PM데이 뒤풀이때 처음 만났고 그때 프로젝트 아이디어에 대해서 잠깐 이야기를 가졌었다. 짧은 시간이였지만 이 프로젝트를 준비하는데..

로그인 화면의 주도권을 백과 프론트 중 어디에서 가지고 있을 것인가에 대해서 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..

요즘 많은 부트캠프들에서 그리고 사이드 프로젝트를 하면서 redis를 많이 쓰곤 한다. 정작 redis에 대해서 정말 잘 알고 쓰는 거일까? 라는 생각이 들었다. 대답은 아니요 이다. 많은 사람들 뿐만 아니라 나 또한 redis를 왜 쓰는지 redis는 어떻게 동작하는지 알고 쓰지는 않았던 거 같다. 이러한 지난 날을 반성하고 redis가 무엇인지 정확히 알고자 이 해체 분석기 시리즈를 작성하기로 마음먹었다. 1. Redis 넌 도대체 누구냐Redis(Remote Dictionary Server)는 오픈소스 기반의 인메모리 데이터 구조 저장소이다. 모든 데이터를 RAM(메모리)에 저장하여 디스크 I/O 없이 초고속 데이터 접근을 제공한다. 일반 관계형 데이터베이스가 아닌 Key-Value 구조의 NoS..

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 검증 시) 혹은 리프레시 요청 시마..

알고리즘 문제를 풀면서 하나의 문자열이 다른 문자열 안에 포함되어 있는지 확인하는 문제들을 종종 볼 수 있다. https://school.programmers.co.kr/learn/courses/30/lessons/120908 프로그래머스SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.kr 물론 위의 문제는 굉장히 쉬운 문제이다. 필자 같은 경우는 과거에는 문자열 길이가 너무 길지 않다면 그냥 하나의 문자열을 기준을 잡고 한 칸씩 오른쪽으로 밀면서 비교를 해서 풀었던 거 같다. 물론 브루스 포스 방식이 꼭 나쁘진 않고 이 안에서도 첫 번째 글자가 우리가 찾는 글자가 맞는지 확인을 하는 조건을 추가한다면 나름 나쁘지 않게 구현을..

나는 대략 8월부터 클로드 코드를 사용하여 바이브 코딩을 본격적으로 하기 시작했다. 그리고 약 4개월이 지난 시점에서 바이브 코딩으로 2개의 팀 프로젝트와 2개의 개인 프로젝트를 진행하였다. 그리고 매주 쓰레드와 같은 SNS에서 바이브 코딩으로 유명한 사람들의 글들을 수백개를 읽었다. 이 글은 그냥 나의 경험과 지식을 바탕으로한 매우 개인적인 견해이다. 내 글이 절대 정답이 아닐 수도 있고 공부를 하는 학생이기 때문에 아직 모르는 부분도 많아 틀릴 확률도 매우 높다. 그러나 내가 말하는 부분들이 맞다 틀리다를 판단하는 것 자체도 좋지만 왜 이런 생각을 하게 되었을까 고민해보면서 글을 읽어주면 더 좋지 않을까 하는 생각이다. 1. 개발자 취업 이제 망한거 아닌가?정말 많이 들었던 말이다. 그리고 나도 정..