feat: JWT 기반 인증 시스템 구현 및 보안 취약점 해결

[vanillaturtlechips]

PR

PR 요약

하드코딩된 ownerId = 1 보안 취약점을 해결하고, NextAuth + JWT 기반의 완전한 인증 시스템을 구현. 이제 사용자별로 독립된 프로젝트 관리가 가능

const ownerId = getUserIdFromRequest(req);
if (!ownerId) {
  return res.status(401).json({ message: '로그인이 필요합니다.' });
}

변경된 점

src/
├── middleware/
│   └── auth.middleware.ts           # JWT 토큰 검증 미들웨어
├── services/auth/
│   └── user-sync.service.ts         # 사용자 동기화 서비스
├── types/
│   └── next-auth.d.ts               # NextAuth 타입 확장
└── pages/api/debug/
    └── auth-check.ts                # 인증 상태 디버깅 API

1. src/pages/api/auth/[...nextauth].ts

• GitHub OAuth 후 자동 사용자 DB 동기화
• JWT 쿠키 설정 최적화

2. src/pages/api/project/create.ts

diff
- const ownerId = 1; // 하드코딩 제거
+ const ownerId = getUserIdFromRequest(req); // 실제 사용자
+ if (!ownerId) return res.status(401).json({...});

3. src/pages/api/project/dashboard_projects.ts

diff
- // 모든 프로젝트 반환
+ // 사용자가 소유하거나 기여한 프로젝트만 반환
+ where: {
+   OR: [
+     { ownerId: userId },
+     { contributors: { some: { userId } } }
+   ]
+ }

4. src/pages/dashboard.tsx

• 인증 상태 확인 및 리디렉션
• 사용자 정보 표시 (헤더) [헤더가 2개 중복되는 경우가 있어서 부분적으로 추가하라고 다 빼놨음
• 에러 처리 강화

5. src/pages/index.tsx

• 로그인/로그아웃 UI 복원
• 사용자 동기화 플로우

이슈 번호

#186

[JSHWJ]

@vanillaturtlechips

1. 저희 서비스 기획에서 회원가입이 필요한가요?
2. 로컬에서 가입이 되어있는 버전과 안 되어있는 버전으로 테스트 하셨나요?
3. 사용자 테이블이 upsert 하신다고 하셨는데 update하거나 insert 하시는 필드에 대해서 어떤 의도에서 그렇게 하셨는지 설명 부탁드려요

[vanillaturtlechips]

@JSHWJ

1.

"회원가입" 개념은 없어요, GitHub 연동으로 자동 계정이 생성되는 방식입니다.

2.

이 db 기준으로 설명하겠습니다.

로그인이 되어 있는 상태의 버전은 세션이 유지되는 일주일 동안 자동으로 dashboard 페이지가 기본 화면으로 배치가 됩니다.

로그인이 되어 있지 않은 상태의 버전은 이 상태만 지정이 되어 있습니다.

3.

요건 이 db 기준으로 설명하겠습니다.

Insert는 아까 제가 말을 올렸듯이 사용자 첫 로그인 할때, 그 값을 해당 테이블에 저장하는 방식으로 보시면 될 거 같구요

update는 GitHub에서 프로필 정보 변경 시 우리 DB도 최신화하는 방식이라고 보면 될 거 같아요

이렇게 해서 나중에 데이터 불일치 문제를 해소하고자 했어요.

ex. 추가적으로 회원 가입 방식도 논의해볼 수 있으면 좋을 거 같아요.

1. 화이트리스트 (관리자가 db에 회원 정보를 사전 등록하는 방식)
2. 회원가입 + 승인 (누구나 이 커뮤니티에 가입 가능한데, 하지만 pending 상태고, 그 요청을 관리자가 승인 해야지 가입이 가능한 상태, 쉽게 생각하면 네이버 카페 초대장 같은 방식)
3. 도메인 기반 자동 승인 (요건 자동으로 이메일이 회사 도메인 기반이 아니면 자동으로 승인이 거부하고, 회사 도메인으로 접속을 하면 승인이 되는 상태, 요건 제가 다녔던 회사에서도 이런 방식을 쓰는 것 같았어요)
4. 초대 기반 시스템 (기존 사용자나 관리자가 새 사용자를 초대하는 시스템, 쉽게 생각하면 이메일 발송하고 클릭하면 로그인 되는 네이버 비밀 카페 초대장 같은 시스템)

제가 다녔던 회사에선 보통 3 + 4를 쓰긴 했어요. 이 부분은 나중에 조원들이랑 같이 생각해봐요

[JSHWJ]

@vanillaturtlechips

1. GitHub 연동으로 자동 계정이 생성되는 방식입니다. => 미리 디비에 회사 직원 계정 등록해둔 다음에 깃허브 소셜 로그인 하는 방식으로 결정하지 않았나요? 이 문장이 이해가 안 가네요
2. 넵 로컬에서 백엔드 api 로그인 성공/실패 여부 테스트 하신 게 맞나용?
3. 아 로그인 할 때마다 프로필 네임이랑 이미지를 점검하고 업데이트하는 방식으로 하신다는 거군용
4. 그리고 화이트리스트 방식으로 로그인 구현하기로 초기 기획 때 이미 결정하지 않았나요?

[vanillaturtlechips]

@JSHWJ

1.

말씀하신 대로 초기 기획에서는 화이트리스트 방식으로 결정했었는데,
구현하면서 몇 가지 문제점을 발견해서 검토 요청드립니다

화이트리스트 방식의 기술적 고려사항:

DB 운영하는 사람이 힘들 수도

• 신규 입사자 추가 요청: "로그인이 안 돼요!"
• 퇴사자 삭제 요청: "보안팀에서 즉시 삭제하라고..."
• 이메일 변경 요청: "GitHub 이메일을 바꿨는데 로그인이..."
• 부서 이동 시 권한 변경: "팀이 바뀌었는데 프로젝트가..."
• 주말/휴일/휴가에 화이트리스트 관리자가 부재하면 <- 서비스가 중단될 수도 있음

신입이 서비스에 접근하면 (실제 사례)

• 새 직원이 서비스 사용하려고 함
• GitHub 로그인 → "Access Denied"
• 운영 팀에 문의 → "화이트리스트 등록 요청하세요"
• 승인 대기 → OT 업무 차질
• 예전 회사 온보딩 기간때, Anti DDos, Jira, 사내 인트라넷 등의 계정 발급에 차질이 생겨서 PM 계정으로 이벤트를 관리한 적이 있음, 이 부분에서 관제 PM과 운영 PM 쪽과의 충돌이 생길 뻔함 (물론 그 당시 긴급 투입된 상태라서 살짝 다른 이슈일 수도 있음)
• 이처럼 개발과 운영 사이의 사일로가 생길 수 있어 Devops 방법론에 부합하지 않게 될 수 있다고 생각

확장성 문제

• 10명까진 OK, 이용자가 100명 이상이면?
• 협력업체, 파트너사, 각각 고객사까지 생각했을때 관리자의 수동 작업은 리소스 낭비일 수 있다고 생각

화이트리스트여도 보안 이슈가 있을 수 있음

• 퇴사자, 휴직자에 대한 보안 정책을 수립해야 함 (주통기 기반)
• 권한 세분화도 최소 권한 원칙으로 수립
• 감사 추적이 어려울 수 있음

2.

로컬 테스트 완료했습니다

성공 케이스:

• GitHub 로그인 → JWT 토큰 생성 → /dashboard 리디렉션
• 콘솔 로그: "[Auth Success] User synchronized: user@example.com"
• DB에 사용자 정보 정상 저장 확인

실패 케이스:

• GitHub OAuth 거부 시 → 메인 페이지로 돌아감
• 네트워크 오류 시 → 에러 메시지 표시 후 재시도 가능
• JWT 토큰 없이 /dashboard 접근 시 → 자동으로 로그인 페이지 리디렉션

백엔드 API 응답도 정상 확인했습니다.

3.

맞습니다! UPSERT로 구현한 이유는:

UPDATE 시나리오:

• GitHub에서 프로필 사진 변경 → 우리 DB도 자동 동기화
• GitHub 이름 변경 → 실시간 반영
• 로그인할 때마다 최신 정보 유지

INSERT 시나리오:

• 첫 로그인 시 새 사용자 생성

이렇게 하면 사용자가 GitHub에서 정보를 바꿔도 우리 서비스에서
항상 최신 정보를 볼 수 있습니다.

4.

초기 기획때 화이트리스트로 결정한 것 맞습니다.

다만 구현하면서 다음과 같은 대안들을 고려해봤는데 어떻게 생각하시나요?

1. 도메인 기반 자동 승인 + 초대 기반 시스템으로 완전 자동화

• 회사 도메인을 가진 사용자(ex. 2220110150@intellsia.com)은 즉시 자동 승인하고, 외부 사용자는 기존 직원이 초대장을 보내면 가입할 수 있는 방식입니다.

• 관리자 개입 없이 모든 과정이 자동화됩니다.

회사 직원: GitHub 로그인 → 도메인 확인 → 즉시 승인
외부 개발자: 초대 링크 받음 → GitHub 로그인 → 자동 승인

2. 기존 화이트 리스트에 + 관리자 페이지를 구현하는 방식

• 사전에 등록된 사용자만 로그인할 수 있되, 관리자가 웹 페이지에서 쉽게 사용자를 추가/삭제할 수 있는 방식입니다.

신규 사용자: 접근 요청 → 관리자 승인 → 로그인 가능
관리자: 웹 페이지에서 클릭 몇 번으로 사용자 관리