diff --git a/Baron Safe 기반 휴대폰 승인 로그인 제안안.md b/Baron Safe 기반 휴대폰 승인 로그인 제안안.md index de1bf61..0ef074f 100644 --- a/Baron Safe 기반 휴대폰 승인 로그인 제안안.md +++ b/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 방식이 현실적이다. -- 이후 RP 요구가 커지면 9.1 방식으로 확장한다. +- 초기 도입은 11.2 방식이 현실적이다. +- 이후 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를 생성하고 승인 응답을 서명한다. -3. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다. -4. Baron SSO는 승인 검증 후 기존 Hydra `AcceptLoginRequest`로 OIDC 흐름을 완료한다. -5. 모든 승인 로그인에는 `amr`, `acr`, `device_id`, `auth_req_id`를 기록한다. -6. 향후 표준 CIBA endpoint 지원 여부를 검토한다. +2. 앱은 Android/iOS 공통 지원을 위해 Flutter 기반으로 우선 검토한다. +3. `baron-safe` 앱은 기기별 key pair를 생성하고 승인 응답을 서명한다. +4. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다. +5. Baron SSO는 승인 검증 후 기존 Hydra `AcceptLoginRequest`로 OIDC 흐름을 완료한다. +6. 모든 승인 로그인에는 `amr`, `acr`, `device_id`, `auth_req_id`를 기록한다. +7. 향후 표준 CIBA endpoint 지원 여부를 검토한다. 최종적으로 이 방식은 기존 제안보다 보안성과 설명 가능성이 높다. 단, push 알림 자체를 인증 수단으로 오해해서는 안 되며, 반드시 등록 기기의 서명 검증과 사용자 확인 절차가 포함되어야 한다.