Merged
Conversation
|
✅ Storybook 배포 완료! 🔗 https://67e4fd1fd2c7078dceec04a4-nekcamtezp.chromatic.com/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📌 Related Issues
✅ 체크 리스트
📄 Tasks
⭐ PR Point
인증 플로우를 개선했어요.
코드 볼곳
/src/app/api -> api route 설정
/src/app/api/[...path] -> BFF 설정, 모든 api가 거치는곳
/src/app/api/auth -> 인증 관련 api들
/src/middleware.ts -> 라우트 가드 설정 미들웨어
현재 상황
Authrization에 들어간 토큰으로 인증을 처리한다.localStorage로 관리한다.문제점
가능한 개선 방향
http-only쿠키 방식으로 인증 구조 변경둘중에서 http-only 쿠키 방식으로 인증 구조를 변경하기를 선택했어요.
Next Auth는 Next 서버에서
session 기반으로 인증 정보 + 유저 정보를 관리하는 기능/0Auth 간편하게 구현같은 다양한 편의 사항 제공해줘요.하지만 우리는 유저정보를 별도로 관리할 필요가 없고 (이미 api 활용하는 중) / 0Auth 인증을 이미 서버에서 다 구현해뒀어요.
따라서 정말
인증만 관리하는데 굳이 라이브러리까지? 라는 생각에 http-only 쿠키 방식으로 가야겠다 결정했어요.그런데 이제 현실적인 상황이 저를 마주했어요.
위의 두가지 이유로 현실적으로 서버에서 지금 당장 인증 구조를 바꾸기 어렵다 생각했어요.
그렇다면 이제 상황을 정리하면 아래와 같아요.
Authrization에 토큰을 끼워서 보내야 한다.많은 삽질 끝에 위의 요구사항을 만족할 수 있는 방법인
BFF패턴을 도입하기로 했어요.BFF 패턴
BFF는 프론트엔드 전용 백엔드 레이어에요. 쉽게 이해하면 브라우저와 백엔드 서버 사이에 프록시 서버가 하나 낀다고 생각하면돼요.
기존 api 요청
브라우저 < ---- > 백엔드
BFF 패턴 api 요청
브라우저 < ---- > BFF (Next 서버) < ---- > 백엔드
선택 이유 (장점)
우려 사항 (단점)
-> 웹 배포 리전과 서버 리전을 가까운데 두면 어느정도 커버 가능
이런 단점이 존재하지만 현실적으로 최선의 선택이라 선택하게 되었어요.
구현
Next js에서는 Route handler와 catch-all segement로 BFF를 구현할 수 있어요.
인증 API Route Handler
로그인(
/api/auth/login), 로그아웃(/api/auth/logout), reissue(/api/auth/reissue)를Next Route Handler로 구현했어요. Next 서버에서 백엔드 인증 API를 호출하고, 응답에 따라 쿠키를 설정·삭제한 뒤 클라이언트에는 필요한 정보만 반환해요.이에 따라 클라이언트 localStorage 토큰 로직을 제거하고, access/refresh 토큰은 Next 서버에서만 httpOnly 쿠키로 설정·삭제해요.
XSS로부터 토큰 노출을 줄이고, BFF·미들웨어에서 일관되게 쿠키만 읽어 사용하는 구조입니다.
기존 api 요청 프록시
app/api/[...path]/route.tscatch-all로 백엔드 프록시를 두고, axios의 Base Url을/api로 설정해 기존 요청을 모두 해당 경로로 보내게 했어요.route.ts에서는 http 요청 헤더에 'Authorization'을 설정해서 백엔드로 전송해요.미들웨어 라우트 가드
기존 라우트 가드들은
middleware.ts에서 처리했어요. 지금은 ai한테 돌아가게만 하도록 구현해둔 상태라 추후 pr에서 코드를 리펙토링 해야해요.📷 Screenshot
이해에 도움이 될까 하여 간단하게 도식화 해보았어요.
🔔 ETC