373 lines
16 KiB
Markdown
373 lines
16 KiB
Markdown
# Baron Safe 개발 전 검토 및 방식 비교
|
|
|
|
작성일: 2026-06-30
|
|
|
|
## 1. 목적
|
|
|
|
본 문서는 `Baron Safe` 앱 개발 착수 전 검토해야 할 주요 선택지를 정리한다. 회의 중 언급된 "은행앱처럼 앱/웹앱 전환", "Flutter 앱", "웹앱", "네이티브", "푸시 기능", "선승인 후차단" 등의 키워드를 기준으로, Baron SSO 승인 로그인에 적합한 개발 방식과 승인 프로세스를 비교한다.
|
|
|
|
핵심 판단 기준은 다음과 같다.
|
|
|
|
- 앱은 단순 명료하고 직관적이어야 한다.
|
|
- 앱에 많은 기능을 담으려는 순간 `Baron Safe`의 의미가 흐려진다.
|
|
- `Baron Safe`의 본질은 "요청 RP와 요청 기기를 확인하고 승인/거절하는 안전 확인 채널"이다.
|
|
- 따라서 앱의 1차 기능은 승인 요청 확인, 승인, 거절, 기기 등록/해제 정도로 제한한다.
|
|
- 복잡한 관리자 기능, RP 목록 탐색, 일반 포털 기능, 대시보드 기능은 Baron Safe 앱에 넣지 않는다.
|
|
|
|
## 2. 전제
|
|
|
|
Baron SSO 사용자는 불특정 다수가 아니라 내부 사용자, 협력사/고객사 사용자, 그리고 Baron SSO 연동 RP를 인지하고 사용하는 등록 사용자로 한정된다. 따라서 앱 설치와 기기 등록은 다소 번거롭더라도 보안상 수용 가능한 절차로 볼 수 있다.
|
|
|
|
단, 사용자에게 앱 설치를 요구하는 대신 앱은 아주 명확한 가치를 제공해야 한다.
|
|
|
|
```text
|
|
내가 방금 요청한 로그인이 맞는가?
|
|
어느 RP가 요청했는가?
|
|
어떤 기기/브라우저에서 요청했는가?
|
|
승인할 것인가, 거절할 것인가?
|
|
```
|
|
|
|
이 네 가지 질문에 빠르고 안전하게 답하는 것이 `Baron Safe`의 1차 목표다.
|
|
|
|
## 3. 앱 기능 범위 원칙
|
|
|
|
### 3.1 반드시 포함할 기능
|
|
|
|
| 기능 | 설명 |
|
|
| --- | --- |
|
|
| 기기 등록 | 사용자 계정과 앱 기기를 사전 바인딩 |
|
|
| 승인 요청 수신 | Push 또는 앱 내 목록으로 요청 확인 |
|
|
| 요청 정보 표시 | RP명, 요청 기기, IP/위치, 요청 시각, 만료 시간 |
|
|
| 승인 | 생체 인증/PIN 후 승인 |
|
|
| 거절 | 요청자가 본인이 아니면 즉시 거절 |
|
|
| 요청 코드 확인 | number matching 또는 request code 입력/확인 |
|
|
| 기기 해제 | 분실/교체 시 기기 연결 해제 |
|
|
|
|
### 3.2 넣지 않는 것이 좋은 기능
|
|
|
|
| 기능 | 제외 이유 |
|
|
| --- | --- |
|
|
| 일반 SSO 포털 전체 기능 | 앱 목적이 흐려짐 |
|
|
| RP 즐겨찾기/런처 | 승인 앱이 포털 앱으로 변질됨 |
|
|
| 상세 감사 로그 전체 조회 | 관리자/웹 포털 영역에 적합 |
|
|
| 조직도/프로필/설정 전체 | 앱 복잡도 증가 |
|
|
| 자체 메신저/공지 기능 | 푸시 피로도 증가 |
|
|
| 다수 메뉴 기반 대시보드 | 사용자가 승인 순간에 집중하기 어려움 |
|
|
|
|
## 4. 구현 방식 비교
|
|
|
|
### 4.1 요약 판단
|
|
|
|
| 방식 | Android/iOS 공통성 | 푸시 신뢰성 | 보안 저장소 | 개발 속도 | 운영 적합성 | 판단 |
|
|
| --- | --- | --- | --- | --- | --- | --- |
|
|
| 네이티브 앱 | 낮음 | 매우 높음 | 매우 좋음 | 느림 | 매우 좋음 | 장기 고보안 최적 |
|
|
| Flutter 앱 | 높음 | 높음 | 좋음 | 빠름 | 좋음 | 1차 권장 |
|
|
| React Native 앱 | 높음 | 높음 | 좋음 | 빠름 | 보통 | 대안 |
|
|
| PWA/웹앱 | 높음 | 보통/제약 있음 | 제한적 | 매우 빠름 | 제한적 | 단독 인증앱으로 비권장 |
|
|
| WebView/하이브리드 | 중간 | 높음 | 네이티브 보완 가능 | 보통 | 보통 | 단순 래핑은 비권장 |
|
|
|
|
1차 권장안은 `Flutter 앱 + 네이티브 보안 기능 연동`이다. Android/iOS 공통 개발이 가능하고, 기존 `userfront`가 Flutter 기반이라 기술 일관성도 있다. 푸시는 FCM/APNs를 네이티브 앱 수준으로 사용할 수 있다.
|
|
|
|
PWA/웹앱은 설치와 배포가 쉽지만, 승인 로그인용 인증 장치로 사용하기에는 기기 바인딩, 보안 저장소, 앱 무결성, 푸시 일관성 측면에서 약점이 있다.
|
|
|
|
## 5. 네이티브 앱
|
|
|
|
Android는 Kotlin, iOS는 Swift로 각각 개발하는 방식이다.
|
|
|
|
장점:
|
|
|
|
- APNs, FCM, Android Keystore, iOS Keychain/Secure Enclave를 가장 직접적으로 제어할 수 있다.
|
|
- 생체 인증, 앱 무결성 검증, 백그라운드 알림 처리가 가장 안정적이다.
|
|
- 장기적으로 금융앱 수준의 보안 요구에 대응하기 좋다.
|
|
|
|
단점:
|
|
|
|
- Android/iOS 개발을 각각 진행해야 한다.
|
|
- 동일 기능을 양 플랫폼에서 반복 구현해야 한다.
|
|
- 초기 개발 기간과 유지보수 비용이 크다.
|
|
|
|
적합한 경우:
|
|
|
|
- 금융앱 수준의 강한 보안 통제와 장기 운영을 최우선으로 할 때
|
|
- 플랫폼별 세밀한 보안 정책을 직접 제어해야 할 때
|
|
- 충분한 Android/iOS 네이티브 개발 인력이 있을 때
|
|
|
|
## 6. Flutter 앱
|
|
|
|
Flutter는 하나의 코드베이스로 Android/iOS 앱을 개발하고, 필요한 보안 기능은 플랫폼 플러그인 또는 Method Channel로 연동하는 방식이다.
|
|
|
|
장점:
|
|
|
|
- Android/iOS 공통 UI와 승인 로직을 빠르게 개발할 수 있다.
|
|
- 기존 Baron SSO `userfront`가 Flutter 기반이므로 내부 기술 친화성이 높다.
|
|
- FCM/APNs, local_auth, secure storage 등 승인 앱에 필요한 주요 기능을 연동할 수 있다.
|
|
- 앱 화면을 단순하게 유지하기 쉽다.
|
|
|
|
단점:
|
|
|
|
- 일부 보안 기능은 네이티브 플러그인 품질에 의존한다.
|
|
- App Attest, Play Integrity, Secure Enclave 세부 제어는 네이티브 연동이 필요할 수 있다.
|
|
|
|
적합한 경우:
|
|
|
|
- 1차 MVP를 빠르게 만들고 양 플랫폼을 동시에 지원해야 할 때
|
|
- 앱 기능을 승인/거절 중심으로 단순하게 제한할 때
|
|
- 플랫폼별 고급 보안 기능은 단계적으로 붙일 계획일 때
|
|
|
|
권장:
|
|
|
|
- 1차 Baron Safe는 Flutter로 시작한다.
|
|
- 단, private key 생성/보관, 앱 무결성 검증, 생체 인증은 네이티브 플러그인 또는 Method Channel로 신중하게 구현한다.
|
|
|
|
## 7. 웹앱/PWA
|
|
|
|
PWA는 웹 기술로 만든 앱을 홈 화면에 설치해 앱처럼 사용하는 방식이다.
|
|
|
|
장점:
|
|
|
|
- 앱스토어 배포 없이 빠르게 제공할 수 있다.
|
|
- Android/iOS/데스크톱에서 같은 웹 코드로 접근할 수 있다.
|
|
- 단순 승인 화면 프로토타입을 빠르게 검증할 수 있다.
|
|
|
|
단점:
|
|
|
|
- iOS Web Push는 홈 화면에 추가된 웹앱에서 동작하는 방식이며, 사용자가 직접 홈 화면 추가와 알림 허용을 해야 한다.
|
|
- 브라우저/OS별 Push API, Service Worker, 권한 정책 차이가 있다.
|
|
- 기기 private key 보호, 앱 무결성, 루팅/탈옥 탐지 등 고보안 요구에 한계가 있다.
|
|
- 사용자가 URL만 보고 접근하므로 피싱/가짜 PWA에 취약할 수 있다.
|
|
|
|
적합한 경우:
|
|
|
|
- 사전 PoC 또는 내부 데모
|
|
- 앱 설치 전 임시 승인 채널
|
|
- 낮은 위험도의 보조 확인 화면
|
|
|
|
비권장:
|
|
|
|
- Baron Safe의 최종 인증 장치 역할을 PWA만으로 구현하는 것은 비권장이다.
|
|
- 특히 "등록 기기에서 서명된 승인"을 핵심 보안 근거로 삼으려면 네이티브 앱 또는 Flutter 앱이 더 적합하다.
|
|
|
|
## 8. WebView/하이브리드 방식
|
|
|
|
네이티브 앱 껍데기에 웹 화면을 담는 방식이다. 은행앱처럼 일부 화면은 앱, 일부 화면은 웹으로 전환하는 구조도 여기에 포함된다.
|
|
|
|
장점:
|
|
|
|
- 앱 배포 후 UI 일부를 웹에서 빠르게 바꿀 수 있다.
|
|
- 네이티브 푸시와 웹 UI를 결합할 수 있다.
|
|
- 기존 웹 자산을 재사용할 수 있다.
|
|
|
|
단점:
|
|
|
|
- 인증 승인 앱의 핵심 화면이 웹으로 과도하게 넘어가면 보안 경계가 흐려진다.
|
|
- WebView 내 세션, 쿠키, 딥링크, 리다이렉트 처리가 복잡해질 수 있다.
|
|
- 피싱 화면과 진짜 승인 화면을 사용자가 구분하기 어려워질 수 있다.
|
|
|
|
권장 방향:
|
|
|
|
- Baron Safe의 핵심 승인 화면은 앱 네이티브/Flutter 화면으로 유지한다.
|
|
- 약관, 도움말, 공지, 기기 관리 안내처럼 보안 민감도가 낮은 화면만 WebView로 처리한다.
|
|
- 승인/거절/서명/생체 인증은 WebView가 아니라 앱 네이티브 레이어에서 수행한다.
|
|
|
|
## 9. 앱/웹앱 전환 방식
|
|
|
|
회의에서 언급된 "은행앱처럼 앱/웹앱 전환"은 다음 구조로 해석할 수 있다.
|
|
|
|
### 9.1 웹에서 앱으로 전환
|
|
|
|
사용자가 웹 로그인 화면에서 전화번호를 입력하면, Baron SSO가 승인 요청을 만들고 앱으로 전환한다.
|
|
|
|
가능한 방식:
|
|
|
|
- Universal Links(iOS), App Links(Android)
|
|
- 커스텀 URL Scheme
|
|
- Push 알림 탭
|
|
- QR 코드 스캔
|
|
|
|
권장:
|
|
|
|
- 기본은 Push 알림으로 앱을 열게 한다.
|
|
- 앱이 이미 설치되어 있으면 Universal/App Link로 바로 열 수 있다.
|
|
- 앱이 없으면 설치 안내 페이지로 이동한다.
|
|
|
|
### 9.2 앱에서 웹으로 복귀
|
|
|
|
사용자가 앱에서 승인하면 요청 기기 웹 화면은 poll 또는 server push로 승인 상태를 확인하고 로그인 완료를 진행한다.
|
|
|
|
권장:
|
|
|
|
- 앱이 요청 기기로 직접 토큰을 전달하지 않는다.
|
|
- 앱은 Baron SSO 서버에 승인만 보낸다.
|
|
- 요청 기기는 Baron SSO 서버에서 승인 상태를 확인한다.
|
|
- 최종 RP 로그인은 기존 Hydra/OIDC 흐름으로 완료한다.
|
|
|
|
## 10. 푸시 기능 비교
|
|
|
|
### 10.1 플랫폼별 푸시 구조
|
|
|
|
| 대상 | 기본 푸시 채널 | 설명 |
|
|
| --- | --- | --- |
|
|
| Android 네이티브/Flutter | FCM | Google Firebase Cloud Messaging 사용 |
|
|
| iOS 네이티브/Flutter | APNs, 또는 FCM 경유 APNs | Apple Push Notification service 사용 |
|
|
| Android PWA | Web Push + Service Worker | Chrome/브라우저 기반 |
|
|
| iOS PWA | Web Push + Home Screen web app | iOS/iPadOS 16.4 이후 홈 화면 웹앱에서 지원 |
|
|
|
|
참고:
|
|
|
|
- Firebase Cloud Messaging은 Android, iOS, Web에 메시지를 보낼 수 있는 공식 서비스다.
|
|
- Apple은 iOS/iPadOS 16.4부터 홈 화면에 추가된 웹앱의 Web Push를 지원한다고 설명한다.
|
|
- Web Push API는 Service Worker 기반으로 서버가 웹앱에 비동기 메시지를 보낼 수 있게 한다.
|
|
|
|
### 10.2 푸시 효율성 비교
|
|
|
|
| 방식 | 도달 안정성 | 즉시성 | 사용자 설정 영향 | 구현 난이도 | Baron Safe 적합성 |
|
|
| --- | --- | --- | --- | --- | --- |
|
|
| 네이티브 앱 + FCM/APNs | 높음 | 높음 | 알림 권한/절전 정책 영향 | 중간 | 매우 높음 |
|
|
| Flutter 앱 + FCM/APNs | 높음 | 높음 | 알림 권한/절전 정책 영향 | 중간 | 높음 |
|
|
| PWA Web Push | 중간 | 중간 | 브라우저/홈화면/권한 영향 큼 | 중간 | 제한적 |
|
|
| 웹 폴링 | 낮음 | 낮음 | 사용자가 화면을 열어둬야 함 | 낮음 | 보조 수단 |
|
|
| SMS | 중간 | 중간 | 통신사/비용/지연 영향 | 낮음 | fallback |
|
|
|
|
판단:
|
|
|
|
- 승인 로그인에서 가장 중요한 것은 "요청이 왔을 때 사용자가 빠르게 인지하고 승인할 수 있는가"이다.
|
|
- 이 기준에서는 네이티브 앱 또는 Flutter 앱의 FCM/APNs 기반 푸시가 가장 적합하다.
|
|
- PWA Web Push는 가능하지만, iOS에서는 홈 화면 추가와 권한 허용이 전제이며, 운영 통제가 네이티브 앱보다 약하다.
|
|
- SMS는 앱 미설치자 fallback으로는 가능하지만, Baron Safe의 주 인증 채널로 삼기에는 비용과 보안 한계가 있다.
|
|
|
|
## 11. 승인 프로세스 선택지
|
|
|
|
### 11.1 기본 권장: 요청 생성 -> 앱 승인 -> 로그인 진행
|
|
|
|
프로세스:
|
|
|
|
1. 요청 기기에서 전화번호 입력
|
|
2. Baron SSO가 승인 요청 생성
|
|
3. Baron Safe 앱으로 Push 발송
|
|
4. 사용자가 요청 정보를 확인
|
|
5. 사용자가 승인
|
|
6. 앱이 서명된 승인 응답 전송
|
|
7. 요청 기기 로그인 진행
|
|
|
|
장점:
|
|
|
|
- 가장 명확하고 안전하다.
|
|
- 사용자가 요청을 확인한 뒤에만 로그인이 진행된다.
|
|
- 감사 로그와 상태 전이가 단순하다.
|
|
|
|
단점:
|
|
|
|
- 앱 푸시 지연 또는 사용자가 앱을 보지 않으면 로그인 대기 시간이 발생한다.
|
|
|
|
권장:
|
|
|
|
- Baron Safe 기본 프로세스로 채택한다.
|
|
|
|
### 11.2 선승인 후차단 방식
|
|
|
|
회의 중 언급된 "선승인 후차단"은 두 가지로 해석될 수 있다.
|
|
|
|
해석 A:
|
|
|
|
- 낮은 위험도의 RP는 일단 승인 흐름을 빠르게 진행하고, 이상 징후가 있으면 사후 차단한다.
|
|
|
|
해석 B:
|
|
|
|
- 사용자가 사전에 특정 RP/기기를 신뢰 등록해두고, 이후 요청은 자동 승인에 가깝게 처리하되 위험 발생 시 차단한다.
|
|
|
|
검토:
|
|
|
|
- 이 방식은 UX는 빠르지만 Baron Safe의 핵심인 "요청별 명시 승인"이 약해진다.
|
|
- 전화번호 단독 로그인의 문제를 다시 일부 가져올 수 있다.
|
|
- 고위험 RP에는 부적합하다.
|
|
|
|
허용 가능 조건:
|
|
|
|
- 동일 기기, 동일 RP, 동일 네트워크 등 낮은 위험 조건이 모두 충족될 때
|
|
- 짧은 기간의 trust window 안에서만
|
|
- 사용자가 명시적으로 "이 기기에서 24시간 동안 다시 묻지 않기"를 선택한 경우
|
|
- 관리자 정책상 허용된 RP에 한정
|
|
|
|
권장:
|
|
|
|
- 1차 개발에서는 제외한다.
|
|
- 2차 이후 "신뢰 기기/신뢰 RP" 기능으로 제한 검토한다.
|
|
|
|
### 11.3 선차단 후승인 방식
|
|
|
|
위험 신호가 있는 요청은 앱에 바로 승인 버튼을 주지 않고, 추가 확인 또는 관리자 확인을 요구하는 방식이다.
|
|
|
|
예시:
|
|
|
|
- 평소와 다른 국가/IP
|
|
- 짧은 시간 내 반복 요청
|
|
- 미등록 RP
|
|
- 고위험 관리자 기능 접근
|
|
|
|
장점:
|
|
|
|
- 공격성 요청을 사용자가 실수 승인하는 위험을 줄인다.
|
|
|
|
단점:
|
|
|
|
- 정책과 UX가 복잡해진다.
|
|
|
|
권장:
|
|
|
|
- 1차에서는 위험 요청을 "승인 불가/거절 권고"로 표시하는 정도로 시작한다.
|
|
- 관리자 승인까지 포함하는 복잡한 흐름은 후속 단계로 둔다.
|
|
|
|
## 12. 푸시 피로 공격 방지
|
|
|
|
Baron Safe는 푸시 기반 승인 앱이므로 푸시 피로 공격을 반드시 고려해야 한다.
|
|
|
|
필수 대책:
|
|
|
|
- 사용자별, 전화번호별, IP별, RP별 rate limit
|
|
- 같은 요청을 반복 발송하지 않는 collapse key 또는 deduplication
|
|
- 승인 화면에 number matching 표시
|
|
- 요청 기기 화면에도 동일한 숫자 코드 표시
|
|
- 앱에서 해당 숫자를 확인하거나 입력해야 승인 가능
|
|
- 반복 요청 발생 시 자동 차단 및 감사 로그 기록
|
|
- 고위험 요청은 앱에서 기본 버튼을 "거절" 중심으로 배치
|
|
|
|
예시 UX:
|
|
|
|
```text
|
|
한맥 ERP 로그인을 승인하시겠습니까?
|
|
|
|
요청 기기: Chrome on Windows
|
|
요청 위치: 203.0.113.xxx
|
|
요청 코드: 42
|
|
|
|
요청 기기에 표시된 숫자와 일치할 때만 승인하세요.
|
|
|
|
[거절] [승인]
|
|
```
|
|
|
|
## 13. 최종 권고
|
|
|
|
1차 개발은 다음 방향이 가장 현실적이다.
|
|
|
|
1. 앱은 Flutter 기반으로 개발한다.
|
|
2. 기능은 승인 요청 확인, 승인, 거절, 기기 등록/해제로 제한한다.
|
|
3. 핵심 승인 화면은 WebView가 아닌 앱 화면으로 구현한다.
|
|
4. Push는 FCM/APNs 기반으로 구현한다.
|
|
5. PWA/Web Push는 PoC 또는 fallback으로만 검토한다.
|
|
6. 승인 응답은 기기 private key로 서명한다.
|
|
7. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다.
|
|
8. 푸시 피로 공격 방지를 위해 rate limit와 number matching을 1차부터 포함한다.
|
|
9. 선승인 후차단 방식은 1차에서 제외하고, 신뢰 기기/신뢰 RP 기능으로 후속 검토한다.
|
|
|
|
Baron Safe는 "작은 앱"이어야 한다. 기능을 많이 넣는 앱이 아니라, 로그인 요청을 안전하게 확인하고 승인하는 단 하나의 일을 확실히 하는 앱으로 설계해야 한다.
|
|
|
|
## 14. 참고 공식 문서
|
|
|
|
- Firebase Cloud Messaging: https://firebase.google.com/docs/cloud-messaging
|
|
- Firebase Cloud Messaging for Flutter: https://firebase.google.com/docs/cloud-messaging/flutter/get-started
|
|
- Apple Notifications: https://developer.apple.com/notifications/
|
|
- Web Push for Web Apps on iOS and iPadOS: https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
|
|
- MDN Push API: https://developer.mozilla.org/en-US/docs/Web/API/Push_API
|
|
- Android Notifications: https://developer.android.com/develop/ui/views/notifications
|
|
- Flutter platform channels: https://docs.flutter.dev/platform-integration/platform-channels
|