[REFACTOR] Kiosk BFF Device Token 인증 구조 개선 논의

[hwangtae123]

🎯 Type

Architecture (구조 개선)

⚠️ AS-IS (현재 문제점)

현재 Kiosk BFF의 Device Token 인증 로직이 Core의 Repository를 직접 주입받아 DB를 조회하고 있습니다.

대상 파일:

• guideon-kiosk-bff/src/main/java/com/guideon/kiosk/global/security/DeviceTokenAuthFilter.java
• guideon-kiosk-bff/src/main/java/com/guideon/kiosk/global/security/DeviceTokenHandshakeInterceptor.java

현재 흐름:

1. Kiosk BFF가 X-DEVICE-TOKEN 또는 WebSocket token query param을 받음
2. Kiosk BFF에서 plain token을 SHA-256으로 해싱
3. Kiosk BFF가 Core의 DeviceRepository를 직접 사용해서 DB 조회
4. 유효한 device면 DeviceDetails를 생성해서 SecurityContext 또는 WebSocket session attributes에 저장

이 구조에서는 Kiosk BFF가 Core의 Entity/Repository/JPA 구조에 직접 의존하게 됩니다.

✨ TO-BE (개선 방향)

Device Token 검증 책임을 Core로 이동하고, Kiosk BFF는 Core 내부 API를 호출해서 인증 결과만 받는 구조로 변경하는 것이 좋을지 논의가 필요합니다.

제안 흐름:

1. Kiosk BFF가 Device Token을 받음
2. Kiosk BFF가 token을 SHA-256으로 해싱
3. Kiosk BFF가 Core 내부 API로 tokenHash 검증 요청
4. Core가 DeviceRepository로 DB 조회 및 active device 검증
5. Core가 deviceId, siteId, zoneId, latitude, longitude 반환
6. Kiosk BFF가 응답값으로 DeviceDetails 생성

예상 API:

• POST /internal/v1/devices/verify-token
  또는
• GET /internal/v1/devices/verify?tokenHash={sha256}

확인하고 싶은 점:

• BFF에서 DeviceRepository를 직접 사용하는 것이 초기 의도였는지, 임시 구현이었는지
• REST 인증 필터와 WebSocket 핸드셰이크 인증을 모두 Core verify API 방식으로 바꿔도 되는지
• BFF가 Core에 plain token을 보낼지, SHA-256 hash를 보낼지
• DeviceTokenAuthFilter와 DeviceTokenHandshakeInterceptor가 공통 인증 client/helper를 공유하도록 정리해도 되는지

예상 작업:

• Core 내부 device token 검증 API 추가
• 인증된 device context 응답 DTO 추가
• Kiosk BFF Feign Client 추가
• DeviceTokenAuthFilter를 Core API 호출 방식으로 변경
• DeviceTokenHandshakeInterceptor를 Core API 호출 방식으로 변경
• Kiosk BFF에서 DeviceRepository/Device 직접 import 제거
• REST + WebSocket 인증 흐름 테스트

[yyuneu]

4번은 필요해 보입니다.
지금 Filter랑 Interceptor에 SHA-256 해싱 + Repository 조회 로직이 그대로 복붙돼있어서, 별도 이슈로 빼서 정리하는게 좋을 것 같습니다.

1 ~ 3번은 지금 필요 없다 생각합니다.

저희 프로젝트가 사실 BFF랑 Core가 분리돼있긴 한데, 진짜 마이크로서비스라기보다는 멀티모듈 모놀리스에 가까운 구조라 굳이 싶은 구조입니다.
iosk-bff/build.gradle에서 Core를 직접 의존하도록 설계돼있어요. Device 인증 말고도 Bootstrap, Place, Chat 다 Core Repository 직접 쓰는 상태라, Device만 verify API로 빼면 같은 BFF 안에 패턴이 두 개 공존해서 더 어색해질 것 같습니다.

또 인증 필터에서 매 요청마다 HTTP 한 번 더 타게 되는데, MVP 개발 시점에서 이런 부분을 리팩토링 하는 것은 너무 오버엔지니어링이라 생각합니다.

만약 4번을 도입한다면 plain token 말고 SHA-256 해시 전송 하면 될 것 같습니다