Update Baron Safe 기반 휴대폰 승인 로그인 제안안.md

Baron Safe 기반 휴대폰 승인 로그인 제안안.md

@@ -462,9 +462,97 @@ POST /api/v1/auth/baron-safe/requests/{authReqId}/decision
 | 세션 관리 | OIDC Back-Channel Logout | RP 로그아웃 전파 |
 | 토큰 취소 | OAuth2 Token Revocation | refresh token 무효화 |
 
-## 10. 구현 방식 선택지
+## 10. 앱 기술 스택 제안
 
-### 10.1 완전 CIBA 지원 방식
+`baron-safe`는 Android와 iOS를 모두 지원해야 하므로, 초기 개발에서는 단일 코드베이스로 양 플랫폼을 동시에 지원하는 크로스플랫폼 프레임워크를 우선 검토하는 것이 현실적이다.
+
+### 10.1 권장안: Flutter 기반 크로스플랫폼 앱
+
+권장 기술 스택:
+
+| 영역 | 권장 기술 | 적용 이유 |
+| --- | --- | --- |
+| App Framework | Flutter | Android/iOS 단일 코드베이스, 기존 `userfront`와 기술 친화성 |
+| Language | Dart | Flutter 기본 언어 |
+| Push Notification | Firebase Cloud Messaging + APNs 연동 | Android/iOS 공통 푸시 발송 관리 |
+| Secure Storage | Android Keystore, iOS Keychain/Secure Enclave 연동 | 기기 private key 및 민감 토큰 보호 |
+| Local Authentication | `local_auth` 계열 생체 인증 연동 | 승인 전 지문/Face ID/기기 PIN 확인 |
+| Crypto Signing | JWS/JWK 또는 COSE 서명 라이브러리 | 승인 응답 서명 및 위변조 방지 |
+| API 통신 | HTTPS + certificate pinning 검토 | 앱-서버 통신 보호 |
+| 상태 관리 | Riverpod 또는 Bloc | 승인 요청/기기 등록/세션 상태 관리 |
+| 배포 | Google Play Enterprise, Apple Business Manager/TestFlight | 내부/협력사 대상 앱 배포 관리 |
+
+Flutter를 권장하는 이유:
+
+- Android/iOS 공통 UI와 비즈니스 로직을 하나의 코드베이스로 관리할 수 있다.
+- 로그인 승인 앱은 고성능 네이티브 UI보다 안정적인 API 통신, 푸시, 보안 저장소, 생체 인증 연동이 핵심이므로 Flutter와 잘 맞는다.
+- Baron SSO의 `userfront`가 이미 Flutter 기반이므로 조직 내 학습 비용과 코드 패턴 재사용 측면에서 유리하다.
+- 필요 시 플랫폼별 보안 기능은 Method Channel 또는 플러그인으로 네이티브 연동할 수 있다.
+
+### 10.2 대안: React Native
+
+React Native도 Android/iOS 공통 개발이 가능하다.
+
+장점:
+
+- JavaScript/TypeScript 기반으로 웹 프론트엔드 인력과 협업이 쉽다.
+- 푸시, 생체 인증, secure storage 생태계가 충분하다.
+
+단점:
+
+- 현재 Baron SSO의 사용자 프론트가 Flutter 기반이므로 기술 스택이 하나 더 늘어난다.
+- 보안 저장소와 네이티브 crypto 연동 시 라이브러리 품질 검증이 필요하다.
+
+### 10.3 대안: 네이티브 앱 분리 개발
+
+Android는 Kotlin, iOS는 Swift로 각각 개발하는 방식이다.
+
+장점:
+
+- Android Keystore, iOS Keychain/Secure Enclave, 생체 인증, 푸시 처리 등 플랫폼 보안 기능을 가장 직접적으로 제어할 수 있다.
+- 장기적으로 고보안 앱을 만들기에는 가장 안정적인 선택이다.
+
+단점:
+
+- Android/iOS 개발과 테스트를 별도로 운영해야 한다.
+- 초기 개발 속도와 유지보수 비용이 증가한다.
+- 기능 동등성 관리가 어렵다.
+
+### 10.4 공통 구현 원칙
+
+프레임워크와 관계없이 다음 원칙은 반드시 지켜야 한다.
+
+- Android와 iOS 모두 기기별 key pair를 앱 최초 등록 시 생성한다.
+- private key는 서버로 전송하지 않고 Android Keystore 또는 iOS Keychain/Secure Enclave에 보관한다.
+- push token은 알림 전달용으로만 사용하고 인증 수단으로 취급하지 않는다.
+- 승인 응답은 `auth_req_id`, `nonce`, `decision`, `device_id`, `approved_at` 등을 포함해 서명한다.
+- 앱 승인 전 OS 생체 인증 또는 앱 PIN을 요구한다.
+- 앱이 탈옥/루팅, 디버그 빌드, 무결성 훼손 상태일 경우 고위험 RP 승인을 제한한다.
+- Android는 Play Integrity API, iOS는 App Attest 또는 DeviceCheck 적용을 검토한다.
+- 앱과 서버 API는 TLS를 기본으로 하고, 필요 시 certificate pinning을 적용한다.
+
+### 10.5 배포 및 운영 방안
+
+Baron SSO 사용자가 불특정 다수가 아니라 등록된 내부/외부 사용자라는 점을 고려하면, 앱 배포도 일반 공개 앱보다 관리형 배포가 적합하다.
+
+권장 배포 방식:
+
+| 대상 | Android | iOS |
+| --- | --- | --- |
+| 내부 임직원 | Managed Google Play 또는 사내 MDM | Apple Business Manager 또는 MDM |
+| 협력사/고객사 | 제한 공개 테스트/엔터프라이즈 배포 검토 | Apple Business Manager Custom App 또는 TestFlight |
+| 초기 파일럿 | Firebase App Distribution | TestFlight |
+
+운영 고려사항:
+
+- 기기 등록/해제 기능을 관리자 화면과 사용자 마이페이지에 제공한다.
+- 분실 기기 즉시 차단 기능이 필요하다.
+- 앱 버전 최소 요구사항을 서버에서 강제할 수 있어야 한다.
+- 보안 정책 변경 시 구버전 앱의 승인을 제한할 수 있어야 한다.
+
+## 11. 구현 방식 선택지
+
+### 11.1 완전 CIBA 지원 방식
 
 Baron SSO가 CIBA의 backchannel authentication endpoint와 CIBA grant type을 공식 지원한다.
 
@@ -479,7 +567,7 @@ Baron SSO가 CIBA의 backchannel authentication endpoint와 CIBA grant type을
 - Hydra에서 CIBA를 직접 지원하지 않는 경우 구현 범위가 커진다.
 - discovery metadata, client registration, token grant 확장이 필요하다.
 
-### 10.2 CIBA 스타일 내부 브로커 방식
+### 11.2 CIBA 스타일 내부 브로커 방식
 
 Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로그인 완료는 기존 Hydra `AcceptLoginRequest`로 연결한다.
 
@@ -496,10 +584,10 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 
 권장:
 
-- 초기 도입은 9.2 방식이 현실적이다.
+- 초기 도입은 11.2 방식이 현실적이다.
-- 이후 RP 요구가 커지면 9.1 방식으로 확장한다.
+- 이후 RP 요구가 커지면 11.1 방식으로 확장한다.
 
-### 10.3 Device Authorization Grant 응용 방식
+### 11.3 Device Authorization Grant 응용 방식
 
 키오스크, TV, CLI처럼 입력이 제한된 기기에는 OAuth2 Device Authorization Grant를 응용할 수 있다.
 
@@ -513,11 +601,12 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 - 사용자가 user code를 입력하는 UX가 기본 모델이다.
 - 휴대폰 번호 기반 push 승인과는 CIBA보다 덜 직접적이다.
 
-## 11. 도입 단계 제안
+## 12. 도입 단계 제안
 
 ### Phase 1: 내부 승인 브로커 MVP
 
 - `baron-safe` 기기 등록 모델 추가
+- Android/iOS 공통 앱 MVP 구현
 - 승인 요청 생성 API 추가
 - 앱 요청 상세 조회 API 추가
 - 앱 승인/거절 API 추가
@@ -528,7 +617,9 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 ### Phase 2: 보안 강화
 
 - 기기별 key pair 및 JWS 서명 검증
+- Android Keystore, iOS Keychain/Secure Enclave 연동 강화
 - OS 생체 인증 또는 앱 PIN 필수화
+- Play Integrity API, App Attest/DeviceCheck 적용 검토
 - nonce 재사용 방지
 - rate limit 및 push fatigue 방어
 - RP별 allowlist와 required ACR 정책
@@ -542,9 +633,9 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 - Ping/Poll delivery mode 정식화
 - PAR/JAR 적용 검토
 
-## 12. 운영 정책 제안
+## 13. 운영 정책 제안
 
-### 12.1 인증 강도 구분
+### 13.1 인증 강도 구분
 
 `baron-safe` 승인 로그인은 다음과 같이 별도 인증 강도로 관리한다.
 
@@ -556,14 +647,14 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 | Baron Safe + 생체 인증 | `baron:safe:aal2` | 앱 승인 + 사용자 확인 |
 | WebAuthn/passkey | `baron:webauthn:phishing-resistant` | 피싱 저항 인증 |
 
-### 12.2 RP별 접근 정책
+### 13.2 RP별 접근 정책
 
 - 일반 RP: Baron Safe 앱 승인 허용
 - 민감 RP: Baron Safe + 생체 인증 또는 WebAuthn 요구
 - 관리자 RP: WebAuthn 또는 추가 MFA 요구
 - 외부망 RP: IP/위치 이상 탐지 시 추가 인증 요구
 
-### 12.3 감사 로그 항목
+### 13.3 감사 로그 항목
 
 | 항목 | 설명 |
 | --- | --- |
@@ -578,7 +669,7 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 | signature_valid | 서명 검증 결과 |
 | completed_at | 로그인 완료 시각 |
 
-## 13. 주요 위험과 대응
+## 14. 주요 위험과 대응
 
 | 위험 | 설명 | 대응 |
 | --- | --- | --- |
@@ -586,11 +677,12 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 | 휴대폰 분실 | 등록 앱이 설치된 기기 분실 | 원격 기기 해제, 관리자 잠금, 생체 인증 필수 |
 | 푸시 토큰 탈취 | 알림 토큰 유출 | push token은 인증 수단으로 사용하지 않음 |
 | 앱 위조 | 공격자가 가짜 앱으로 승인 시도 | 기기 private key 서명 검증 |
+| 앱 무결성 훼손 | 루팅/탈옥/디버그 환경에서 승인 조작 | Play Integrity, App Attest, 고위험 RP 제한 |
 | 요청 변조 | RP 정보 또는 요청 ID 변조 | 서버 저장 요청 기준 검증, nonce, signature |
 | 사용자 열람 | 전화번호 입력으로 가입 여부 추론 | 응답 메시지 일반화, rate limit |
 | RP 오남용 | 허용되지 않은 RP가 승인 요청 생성 | client authentication, allowlist |
 
-## 14. 팀장 보고용 최종 제안
+## 15. 팀장 보고용 최종 제안
 
 `baron-safe` 앱 승인 방식은 "전화번호만으로 로그인"이 아니라 "전화번호로 사용자를 식별하고, 등록된 모바일 인증 장치에서 사용자가 승인하는 로그인"으로 정의해야 한다.
 
@@ -606,10 +698,11 @@ Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로
 권장 구현 방향은 다음과 같다.
 
 1. 1차로 Baron Backend가 CIBA 스타일 내부 승인 브로커 역할을 수행한다.
-2. `baron-safe` 앱은 기기별 key pair를 생성하고 승인 응답을 서명한다.
+2. 앱은 Android/iOS 공통 지원을 위해 Flutter 기반으로 우선 검토한다.
-3. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다.
+3. `baron-safe` 앱은 기기별 key pair를 생성하고 승인 응답을 서명한다.
-4. Baron SSO는 승인 검증 후 기존 Hydra `AcceptLoginRequest`로 OIDC 흐름을 완료한다.
+4. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다.
-5. 모든 승인 로그인에는 `amr`, `acr`, `device_id`, `auth_req_id`를 기록한다.
+5. Baron SSO는 승인 검증 후 기존 Hydra `AcceptLoginRequest`로 OIDC 흐름을 완료한다.
-6. 향후 표준 CIBA endpoint 지원 여부를 검토한다.
+6. 모든 승인 로그인에는 `amr`, `acr`, `device_id`, `auth_req_id`를 기록한다.
+7. 향후 표준 CIBA endpoint 지원 여부를 검토한다.
 
 최종적으로 이 방식은 기존 제안보다 보안성과 설명 가능성이 높다. 단, push 알림 자체를 인증 수단으로 오해해서는 안 되며, 반드시 등록 기기의 서명 검증과 사용자 확인 절차가 포함되어야 한다.