지금까지 모든 코드는 user_id 나 개인 정보 등을 uri 혹은 body 에 저장하여 패킷을 왔다갔다 했다.
JWT 토큰을 사용하면 토큰 생성 시에 해당 정보를 토큰에 갖고 있기 때문에 암호화된 헤더 토큰 상태로 왔다갔다하면서 해당 토큰에서 정보를 뽑아내어 사용 가능하다.
그러기 위하여 JWT 토큰을 검증하는 코드 라인 작성이 필요하다.
우리의 모든 엔드포인트에서 JWT 토큰을 검증하고 access와 refresh를 통한 검증이 들어가게 된다.
이 모든 코드를 엔드포인트에 실제로 구현하게 되면 코드가 너무 가독성이 떨어지고 복잡하게 보인다.
그렇기 때문에 우리는 사용자의 request가 백엔드로 닿기 전 지나가게 되는 미들웨어에서 이를 제어한다.
미들웨어에서 토큰 검증 및 재생성 관련된 로직을 불러오는 코드를 작성하게 된다. (해당 미들웨어에서 로그 관련된 출력도 컨트롤 하게 된다)
그렇게 되는 경우, 미들웨어에서 토큰 검증 로직을 넣게 되고 특정 엔드포인트만 해당 검증 로직에서 자유롭게하여 코드 중복을 피하고 검증의 일관성을 유지하게 된다.
또한 user_id 등의 개인정보 또한 uri 등에 포함하는 것이 아닌, JWT을 통하여 미들웨어 정제가 일어나고 각 엔드포인트에서 의존성 주입의 형태로 Depends를 통하여 런타임 시에 결정되게 구현한다.
그렇게 하면 미들웨어 단계에서 토큰을 통하여 검증이 일어나게 되고, 직접적으로 보안에 관련한 정보들을 토큰에 숨겨 전달 가능하다.
또한 해당 의존성 또한 Depends를 통하여 간접적으로 진행하기 때문에 역할의 분리 또한 가능하다.
시험 준비와 캡스톤 (졸업 프로젝트) 준비 등으로 코드를 전부 완성하지는 못했다.
지금 못한 부분으로 인식되는 부분은 JWT 토큰 생성과 검증을 하는 코드를 현재 Access와 refresh 로 호출 형태부터 분리를 해 뒀다.
하지만, 이 부분의 경우 Type에서 분기를 시키고 함수는 하나로 합쳐도 문제 없다.
또한 각 user 별로 권한을 다르게 부여한다면, scope 등을 통해서 제어가 가능하고 이 부분에 대한 DB 도 필요할 수 있겠다는 생각이 들었다. 이 부분에 대한 구현이 들어가야 한다.
추가적으로 개발에 시간이 많이 사용되기 시작한 부분이 코드의 리팩토링을 진행하면서 시간이 걸리기 시작하였고, 검색 엔진을 만드는 부분에서 로직 개발에 시간을 때려박기 시작하면서 무한 삽질이 시작된 거 같다.
일단 완성 코드 부분에 대하여 클라우드 서버 등을 통한 배포 구성을 해야겠다.
| [Serendi] Webhook (4) | 2025.08.25 |
|---|---|
| [백엔드 논문] Zanzibar: Google's Consistent, Global Authorization System #2 (~2.3) (2) | 2025.07.27 |
| [Serendi] 검색 엔진(추천시스템) 만들기 (5) | 2025.07.27 |
| [Redis] 바이트 반환 값 (1) | 2025.07.24 |
| [백엔드 논문] Zanzibar: Google's Consistent, Global Authorization System #1 (2) | 2025.07.23 |