Update Baron Safe PWA/WebView 하이브리드 앱 추진 수정안.md

Baron Safe PWA/WebView 하이브리드 앱 추진 수정안.md

@@ -6,9 +6,12 @@
 
 본 문서는 기존 `Baron Safe 기반 휴대폰 승인 로그인 제안안`을 실제 앱 개발 과제로 진행하기 위한 초기 실행 초안이다.
 
-팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront`는 그대로 유지하고, 그 안에서 활용 가능한 화면 자산과 구현 패턴을 Baron Safe 앱 개발 시 가져다 쓰는 방향으로 구상한다.
+팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront`는 그대로 유지하고, 그 안에서 활용 가능한 화면 자산과   
+구현 패턴을 Baron Safe 앱 개발 시 가져다 쓰는 방향으로 구상한다.
 Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱으로 검토한다.  
-이 앱은 단순 로그인 화면이 아니라, 등록된 휴대폰을 인증 장치로 사용하여 사용자가 로그인 요청을 확인하고 승인 또는 거절하는 보안 승인 앱으로 정의한다.
+
+이 앱은 단순 로그인 화면이 아니라, 등록된 휴대폰을 인증 장치로 사용하여 사용자가 로그인 요청을 확인하고   
+승인 또는 거절하는 보안 승인 앱으로 정의한다.
 
 ## 2. 추진 배경
 
@@ -16,7 +19,8 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 현재 로그인 요청을 직접 승인했는지 확인하기 어렵다.
 
 이를 보완하기 위해 사용자의 휴대폰에 `Baron Safe` 앱을 설치하고, 해당 앱을 사용자 계정에 사전 등록된 인증 장치로 사용한다. 
-사용자는 PC, 브라우저, 키오스크 또는 RP 서비스에서 로그인 요청을 시작하고, 휴대폰 앱에서 요청 서비스, 요청 기기, 요청 시간, IP 정보를 확인한 후 승인한다.
+사용자는 PC, 브라우저, 키오스크 또는 RP 서비스에서 로그인 요청을 시작하고,   
+휴대폰 앱에서 요청 서비스, 요청 기기, 요청 시간, IP 정보를 확인한 후 승인한다.
 
 이 구조는 OpenID Connect CIBA와 유사한 Out-of-Band 인증 흐름이며, Baron SSO의 Hydra/Kratos 기반 인증 흐름과도 연결할 수 있다.
 
@@ -25,7 +29,8 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 `Baron Safe`는 Flutter 기반 설치형 모바일 앱, PWA, WebView/하이브리드 앱 중 하나로 구현할 수 있다.
 
 다만 현재 Baron SSO `userfront`는 이미 모바일 화면을 고려한 포털 UI, 연결 앱 현황, 접속 이력, QR 진입 흐름 등을 포함하고 있다.
-따라서 기존 `userfront`를 직접 변경하거나 앱으로 전환하기보다는, Baron Safe 앱에서 필요한 화면 흐름과 구현 패턴을 가져와 활용하고, 푸시/생체 인증/보안 저장소 같은 기능은 Baron Safe 앱의 네이티브 또는 Flutter 플러그인 계층으로 보강하는 하이브리드 구조가 적절하다.
+따라서 기존 `userfront`를 직접 변경하거나 앱으로 전환하기보다는, Baron Safe 앱에서 필요한 화면 흐름과 구현 패턴을 가져와 활용하고,   
+푸시/생체 인증/보안 저장소 같은 기능은 Baron Safe 앱의 네이티브 또는 Flutter 플러그인 계층으로 보강하는 하이브리드 구조가 적절하다.
 
 기본 방향은 다음과 같다.
 
@@ -54,7 +59,8 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 - 기기 private key를 이용한 승인 응답 서명
 - 기기 분실, 교체, 해제 대응
 
-앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다. 다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
+앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다.   
+다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
 
 ## 5. 지원 플랫폼 및 배포
 
@@ -87,7 +93,8 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 | 이미지/SVG | flutter_svg |
 | 로깅 | logging, logger |
 
-`Baron Safe` 앱은 이 구성을 참고하여 필요한 부분을 가져가되, `userfront` 원본은 그대로 유지한다. 모바일 인증 앱에 필요한 보안/푸시 기능은 Baron Safe 앱 쪽에 별도로 추가한다.
+`Baron Safe` 앱은 이 구성을 참고하여 필요한 부분을 가져가되, `userfront` 원본은 그대로 유지한다.   
+모바일 인증 앱에 필요한 보안/푸시 기능은 Baron Safe 앱 쪽에 별도로 추가한다.
 
 ### 6.2 추가 검토 기술
 
@@ -104,11 +111,13 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 | Deep Link | app_links 또는 firebase_dynamic_links 대체 검토 | 푸시/QR/등록 링크 진입 |
 | App Integrity | Play Integrity API, DeviceCheck/App Attest 검토 | 위변조 앱과 위험 기기 탐지 |
 
-초기에는 기존 `userfront`와의 일관성을 위해 `flutter_riverpod`, `go_router`, `http`를 유지하는 것이 좋다. 단, 인증 앱 특성상 private key 생성/서명은 일반 secure storage만으로 끝내지 말고 Android/iOS 보안 키 저장소와 직접 연동하는 방안을 검토해야 한다.
+초기에는 기존 `userfront`와의 일관성을 위해 `flutter_riverpod`, `go_router`, `http`를 유지하는 것이 좋다.   
+단, 인증 앱 특성상 private key 생성/서명은 일반 secure storage만으로 끝내지 말고 Android/iOS 보안 키 저장소와 직접 연동하는 방안을 검토해야 한다.
 
 ### 6.3 PWA/WebView/하이브리드 방식 검토
 
-팀장 구상은 기존 `userfront`의 활용 가능한 부분을 Baron Safe 앱에서 재사용하여 PWA 또는 WebView/하이브리드 방식으로 앱처럼 제공하는 방향으로 볼 수 있다. 이 방식은 현재 구현된 모바일 포털 화면과 흐름을 참고할 수 있으므로 초기 개발 속도와 화면 일관성 측면에서 장점이 있다.
+팀장 구상은 기존 `userfront`의 활용 가능한 부분을 Baron Safe 앱에서 재사용하여 PWA 또는 WebView/하이브리드 방식으로 앱처럼 제공하는 방향으로 볼 수 있다.   
+이 방식은 현재 구현된 모바일 포털 화면과 흐름을 참고할 수 있으므로 초기 개발 속도와 화면 일관성 측면에서 장점이 있다.
 
 | 방식 | 설명 | 장점 | 주의점 |
 | --- | --- | --- | --- |
@@ -125,7 +134,8 @@ Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱
 - private key 생성과 서명은 Android Keystore, iOS Keychain/Secure Enclave 계층에서 처리한다.
 - WebView 화면은 승인 요청 표시와 사용자 인터랙션을 담당하되, 실제 서명과 민감 토큰 저장은 네이티브 계층에 위임한다.
 
-즉 `userfront`의 화면/패턴을 Baron Safe 앱에서 활용하더라도 Baron Safe의 인증 근거는 웹 세션 자체가 아니라, 앱에 등록된 기기 키와 네이티브 보안 기능에서 나와야 한다.
+즉 `userfront`의 화면/패턴을 Baron Safe 앱에서 활용하더라도 Baron Safe의 인증 근거는 웹 세션 자체가 아니라,   
+앱에 등록된 기기 키와 네이티브 보안 기능에서 나와야 한다.
 
 ## 7. 주요 기능 범위
 
@@ -205,11 +215,14 @@ PoC 단계에서는 기기 서명을 단순화할 수 있으나, API 구조는
 
 ### 8.3 사용자 흐름 제안안 비교
 
-Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과 향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
+Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과   
+향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
 
-특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다. 이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
+특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다.   
+이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
 
-반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다. 두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
+반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다.   
+두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
 
 | 안 | 방식 | 설명 | 장점 | 단점 | 적합한 용도 |
 | --- | --- | --- | --- | --- | --- |
@@ -223,9 +236,11 @@ Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다,
 
 초기 PoC에서는 1안과 2안을 모두 화면상으로 보여주는 방식이 좋다.
 
-1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다. 사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
+1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다.   
+사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
 
-2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고, 사용자가 직접 승인 또는 차단을 결정한다.
+2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고,   
+사용자가 직접 승인 또는 차단을 결정한다.
 
 PoC 이후에는 다음과 같은 단계적 적용을 권장한다.
 
@@ -235,7 +250,8 @@ PoC 이후에는 다음과 같은 단계적 적용을 권장한다.
 | MVP | 2안 중심, 3안 일부 적용 | 고위험 로그인은 매번 승인, 일반 RP는 일정 기간 신뢰 허용 |
 | 운영 | 4안 + 5안 확장 | 위험 기반 정책과 코드 매칭으로 보안 강화 |
 
-이 구조를 사용하면 팀장 구상인 PWA/WebView 기반 화면 재사용과, 기존 제안안의 Baron Safe 승인 보안 모델을 서로 충돌시키지 않고 함께 발전시킬 수 있다.
+이 구조를 사용하면 팀장 구상인 PWA/WebView 기반 화면 재사용과,   
+기존 제안안의 Baron Safe 승인 보안 모델을 서로 충돌시키지 않고 함께 발전시킬 수 있다.
 
 ## 9. 주요 화면 초안