Update Baron Safe 기반 휴대폰 승인 로그인 제안안22.md
This commit is contained in:
@@ -1,708 +1,107 @@
|
|||||||
# Baron Safe 기반 휴대폰 승인 로그인 제안안
|
// ...existing code...
|
||||||
|
|
||||||
작성일: 2026-06-23
|
|
||||||
|
|
||||||
## 1. 목적
|
|
||||||
|
|
||||||
본 문서는 Baron SSO에서 논의 중인 "휴대전화번호 기반 간편 로그인"을 표준 기술에 가깝게 보완하기 위한 방안으로, 가칭 `baron-safe` 모바일 앱을 이용한 승인 기반 로그인 구조를 제안한다.
|
|
||||||
|
|
||||||
기존의 "휴대전화번호만 입력하면 즉시 로그인" 방식은 전화번호를 사용자 식별자(identifier)로만 사용하고, 사용자가 실제 번호 소유자이거나 현재 로그인 요청을 승인했다는 인증 근거가 부족하다. 반면 `baron-safe` 앱을 사전에 등록된 인증 장치(Authentication Device)로 사용하면, 사용자는 요청 RP와 요청 기기 정보를 확인한 뒤 직접 승인할 수 있고, Baron SSO는 승인 결과를 근거로 OIDC 로그인을 진행할 수 있다.
|
|
||||||
|
|
||||||
본 제안의 목표는 다음과 같다.
|
|
||||||
|
|
||||||
- 휴대전화번호 기반 UX의 간편함은 유지한다.
|
|
||||||
- 전화번호 단독 인증의 보안 취약점을 제거한다.
|
|
||||||
- OIDC/OAuth2 표준 모델과 최대한 정합성 있는 구조로 설계한다.
|
|
||||||
- RP별 보안 수준과 감사 추적성을 유지한다.
|
|
||||||
- 향후 WebAuthn, FIDO2, CIBA 등 표준 확장으로 발전 가능한 아키텍처를 확보한다.
|
|
||||||
|
|
||||||
## 2. 제안 배경
|
|
||||||
|
|
||||||
Baron SSO 통합로그인을 사용하는 대상은 일반 소비자 서비스처럼 불특정 다수의 익명 사용자가 아니다. 주된 사용자는 Baron 내부 구성원, 협력사 또는 고객사 구성원, 그리고 Baron SSO와 연동된 우리 회사 RP를 인지하고 사용하려는 등록 사용자로 한정된다.
|
|
||||||
|
|
||||||
따라서 로그인 편의성을 위해 보안을 낮추는 방향보다, 등록 사용자에게 한 번의 앱 설치와 기기 등록 절차를 요구하더라도 이후 모든 RP 로그인에서 더 명확한 본인 확인과 승인 추적성을 확보하는 방향이 조직 보안과 운영 책임 측면에서 더 타당하다.
|
|
||||||
|
|
||||||
`baron-safe` 앱 설치는 사용자에게 초기 번거로움을 줄 수 있다. 그러나 Baron SSO가 보호하는 대상은 내부 업무 시스템, 고객/협력사 연동 RP, 조직 데이터 접근 권한이므로, 해당 번거로움은 보안상 합리적인 비용으로 볼 수 있다. 특히 앱 기반 승인은 사용자가 "어떤 RP가, 어떤 기기에서, 언제 로그인을 요청했는지" 확인한 뒤 승인하도록 만들기 때문에, 단순 휴대전화번호 입력 방식보다 오인 로그인, 전화번호 도용, 내부 계정 오남용 위험을 줄일 수 있다.
|
|
||||||
|
|
||||||
즉, `baron-safe`는 범용 소비자 서비스의 추가 장벽이라기보다 Baron SSO 생태계에 참여하는 등록 사용자에게 제공되는 전용 안전 확인 채널로 정의하는 것이 적절하다.
|
|
||||||
|
|
||||||
## 3. 핵심 결론
|
|
||||||
|
|
||||||
`baron-safe` 앱 승인 방식은 기존 "폰번호만으로 즉시 로그인"보다 훨씬 안전하고, 표준 기술적으로도 설명 가능한 구조다.
|
|
||||||
|
|
||||||
Baron SSO의 사용자 범위가 등록된 내부/외부 사용자로 제한된다는 점을 고려하면, 앱 설치 및 기기 등록 절차는 과도한 진입 장벽이라기보다 SSO 연동 RP 전체에 공통 적용할 수 있는 보안 기반 장치로 볼 수 있다. 특히 전화번호 단독 로그인에서 부족했던 "현재 사용자가 실제로 이 요청을 승인했다"는 근거를 앱 승인과 기기 서명으로 확보할 수 있다.
|
|
||||||
|
|
||||||
이 방식은 OpenID Connect CIBA(Client-Initiated Backchannel Authentication) 모델과 가장 유사하다. CIBA는 RP가 사용자의 식별자를 기반으로 인증 요청을 시작하고, 사용자는 RP 요청 기기가 아닌 별도의 인증 장치에서 인증 및 동의를 수행하는 흐름이다.
|
|
||||||
|
|
||||||
Baron SSO에 적용하면 다음처럼 대응된다.
|
|
||||||
|
|
||||||
| CIBA 용어 | Baron SSO 대응 |
|
|
||||||
| --- | --- |
|
|
||||||
| OpenID Provider(OP) | Baron SSO + Hydra/Kratos/Backend |
|
|
||||||
| Relying Party(RP) | Baron SSO를 사용하는 업무 시스템 |
|
|
||||||
| Consumption Device(CD) | 사용자가 로그인을 시도한 브라우저/PC/키오스크 |
|
|
||||||
| Authentication Device(AD) | `baron-safe`가 설치된 사용자 휴대폰 |
|
|
||||||
| Backchannel Authentication Request | RP 또는 Baron SSO가 생성하는 로그인 승인 요청 |
|
|
||||||
| auth_req_id | Baron SSO 내부 로그인 승인 요청 ID |
|
|
||||||
| Poll/Ping/Push mode | 요청 기기가 승인 결과를 기다리는 방식 |
|
|
||||||
|
|
||||||
참고 표준:
|
|
||||||
|
|
||||||
- OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0
|
|
||||||
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
|
|
||||||
- OAuth 2.0 Device Authorization Grant, RFC 8628
|
|
||||||
https://www.rfc-editor.org/rfc/rfc8628
|
|
||||||
- OAuth 2.0 Pushed Authorization Requests, RFC 9126
|
|
||||||
https://www.rfc-editor.org/rfc/rfc9126
|
|
||||||
|
|
||||||
## 4. 기존 폰번호 단독 로그인과의 차이
|
|
||||||
|
|
||||||
| 항목 | 폰번호 단독 즉시 로그인 | Baron Safe 승인 로그인 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| 사용자 입력 | 전화번호 | 전화번호 |
|
|
||||||
| 사용자 인증 근거 | 없음 또는 약함 | 등록된 앱/기기의 승인 |
|
|
||||||
| 요청 정보 확인 | 없음 | RP, IP, 기기, 시간 표시 |
|
|
||||||
| 사용자 행위 | 번호 입력만 | 앱에서 명시적 승인 |
|
|
||||||
| 세션 발급 근거 | 전화번호 식별 결과 | 승인 요청에 대한 서명된 응답 |
|
|
||||||
| 표준성 | 비표준 인증 우회에 가까움 | CIBA 스타일 Out-of-Band 인증 |
|
|
||||||
| 감사 가능성 | 낮음 | 요청/승인/거절/기기 정보 추적 가능 |
|
|
||||||
| 권장 여부 | 비권장 | 조건부 권장 |
|
|
||||||
|
|
||||||
핵심 차이는 전화번호가 인증 수단이 아니라 식별자로만 사용된다는 점을 명확히 분리하는 것이다. 실제 인증은 `baron-safe`에 등록된 인증 장치와 사용자 승인 행위가 담당한다.
|
|
||||||
|
|
||||||
## 5. 전체 아키텍처
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
sequenceDiagram
|
|
||||||
autonumber
|
|
||||||
actor User as 사용자
|
|
||||||
participant CD as 요청 기기(브라우저/RP/키오스크)
|
|
||||||
participant RP as 요청 RP
|
|
||||||
participant SSO as Baron SSO Backend
|
|
||||||
participant HY as Ory Hydra
|
|
||||||
participant KR as Ory Kratos
|
|
||||||
participant PUSH as FCM/APNs
|
|
||||||
participant APP as Baron Safe 앱
|
|
||||||
|
|
||||||
User->>CD: 휴대전화번호 입력
|
|
||||||
CD->>RP: 로그인 시작
|
|
||||||
RP->>HY: OIDC Authorization Request
|
|
||||||
HY->>SSO: login_challenge 전달
|
|
||||||
SSO->>SSO: 전화번호 정규화 및 등록 기기 조회
|
|
||||||
SSO->>SSO: 승인 요청 생성(auth_req_id, nonce, expires_at)
|
|
||||||
SSO->>PUSH: 승인 알림 전송
|
|
||||||
PUSH->>APP: Push Notification
|
|
||||||
APP->>User: RP/기기/IP/시간 표시
|
|
||||||
User->>APP: 앱 잠금해제/생체인증 후 승인
|
|
||||||
APP->>SSO: 서명된 승인 응답 제출
|
|
||||||
SSO->>SSO: 기기 공개키/nonce/만료/상태 검증
|
|
||||||
SSO->>KR: 세션 확인 또는 세션 수립
|
|
||||||
SSO->>HY: AcceptLoginRequest(subject)
|
|
||||||
HY->>RP: redirectTo / authorization code
|
|
||||||
RP->>HY: token 교환
|
|
||||||
HY->>RP: ID Token / Access Token / Refresh Token
|
|
||||||
```
|
|
||||||
|
|
||||||
## 6. 프로세스별 상세 설계
|
|
||||||
|
|
||||||
### 6.1 사전 등록 프로세스
|
|
||||||
|
|
||||||
`baron-safe` 앱은 단순 알림 앱이 아니라 사용자 계정에 바인딩된 인증 장치로 등록되어야 한다.
|
|
||||||
|
|
||||||
프로세스:
|
|
||||||
|
|
||||||
1. 사용자가 Baron SSO에 기존 표준 방식으로 로그인한다.
|
|
||||||
2. 사용자 설정 또는 관리자 초대 화면에서 `baron-safe` 기기 등록을 시작한다.
|
|
||||||
3. 앱이 기기 내 안전 저장소에서 key pair를 생성한다.
|
|
||||||
4. 앱이 public key, device id, push token, platform 정보를 Baron SSO에 등록한다.
|
|
||||||
5. Baron SSO는 해당 기기를 사용자 계정에 연결한다.
|
|
||||||
6. 등록 완료 후 해당 기기에서 승인 요청을 받을 수 있다.
|
|
||||||
|
|
||||||
생성되는 데이터:
|
|
||||||
|
|
||||||
| 데이터 | 생성 주체 | 저장 위치 | 설명 |
|
|
||||||
| --- | --- | --- | --- |
|
|
||||||
| device_id | Baron Safe 또는 Backend | Backend DB | 기기 식별자 |
|
|
||||||
| public_key | Baron Safe | Backend DB | 승인 응답 서명 검증용 |
|
|
||||||
| private_key | Baron Safe | 기기 보안 저장소 | 서버로 전송 금지 |
|
|
||||||
| push_token | OS/FCM/APNs | Backend DB | 알림 발송용 |
|
|
||||||
| user_id | Kratos/Baron SSO | Backend DB | 사용자-기기 연결 |
|
|
||||||
| device_name | Baron Safe | Backend DB | 사용자 표시용 |
|
|
||||||
| registered_at | Backend | Backend DB | 등록 시각 |
|
|
||||||
| last_used_at | Backend | Backend DB | 마지막 승인 시각 |
|
|
||||||
|
|
||||||
표준 기술:
|
|
||||||
|
|
||||||
- JWK/JWS: 기기 public key 등록 및 승인 응답 서명 검증
|
|
||||||
- TLS: 앱-서버 통신 보호
|
|
||||||
- OS Secure Enclave/Keystore/Keychain: private key 보호
|
|
||||||
- 선택 적용: WebAuthn/FIDO2/passkey 기반 기기 등록
|
|
||||||
|
|
||||||
주의 사항:
|
|
||||||
|
|
||||||
- push token은 인증 수단이 아니다. 알림 전달 주소일 뿐이다.
|
|
||||||
- 실제 인증 근거는 기기 private key로 서명한 승인 응답과 사용자 확인 행위다.
|
|
||||||
- 기기 분실/교체/폐기 절차가 반드시 필요하다.
|
|
||||||
|
|
||||||
### 6.2 로그인 요청 생성 프로세스
|
|
||||||
|
|
||||||
프로세스:
|
|
||||||
|
|
||||||
1. 사용자가 RP 또는 Baron SSO 로그인 화면에서 휴대전화번호를 입력한다.
|
|
||||||
2. Baron SSO가 전화번호를 정규화한다.
|
|
||||||
3. 해당 번호의 사용자와 등록된 `baron-safe` 기기를 조회한다.
|
|
||||||
4. OIDC `login_challenge`와 RP client 정보를 조회한다.
|
|
||||||
5. Baron SSO가 승인 요청을 생성한다.
|
|
||||||
6. 승인 요청은 Redis 또는 DB에 TTL과 함께 저장된다.
|
|
||||||
|
|
||||||
생성되는 데이터:
|
|
||||||
|
|
||||||
| 데이터 | 예시 | 설명 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| auth_req_id | `ars_...` | 승인 요청 고유 ID |
|
|
||||||
| login_challenge | Hydra 값 | OIDC 로그인 요청 연결 |
|
|
||||||
| client_id | `hanmac-erp` | 요청 RP 식별자 |
|
|
||||||
| client_name | `한맥 ERP` | 앱 화면 표시용 |
|
|
||||||
| requested_subject | Kratos identity id | 승인 대상 사용자 |
|
|
||||||
| phone_hash | SHA-256 등 | 전화번호 원문 노출 최소화 |
|
|
||||||
| nonce | 난수 | 재전송 공격 방지 |
|
|
||||||
| request_ip | `203.0.113.xxx` | 요청 기기 정보 |
|
|
||||||
| user_agent | Chrome on Windows | 요청 기기 정보 |
|
|
||||||
| expires_at | 요청 만료 시각 | 예: 2분 |
|
|
||||||
| status | `pending` | pending/approved/rejected/expired |
|
|
||||||
|
|
||||||
표준 기술:
|
|
||||||
|
|
||||||
- OIDC Authorization Request
|
|
||||||
- Hydra login challenge
|
|
||||||
- CIBA의 `auth_req_id` 모델과 유사한 승인 요청 ID
|
|
||||||
- OAuth/OIDC client metadata
|
|
||||||
|
|
||||||
주의 사항:
|
|
||||||
|
|
||||||
- 전화번호 미등록/기기 미등록 여부가 외부에 드러나면 사용자 열람 공격이 가능하다.
|
|
||||||
- 응답 메시지는 "승인 요청을 확인해 주세요"처럼 일반화하는 것이 안전하다.
|
|
||||||
- 요청 TTL은 짧게 설정한다. 예: 60~180초.
|
|
||||||
|
|
||||||
### 6.3 앱 알림 및 요청 표시 프로세스
|
|
||||||
|
|
||||||
프로세스:
|
|
||||||
|
|
||||||
1. Baron SSO가 등록된 기기의 push token으로 알림을 보낸다.
|
|
||||||
2. 알림에는 민감정보를 최소화하고, 상세 정보는 앱이 서버에서 조회한다.
|
|
||||||
3. 앱은 `auth_req_id`로 승인 요청 상세를 조회한다.
|
|
||||||
4. 앱은 사용자에게 RP 정보와 요청 기기 정보를 표시한다.
|
|
||||||
|
|
||||||
앱 표시 정보:
|
|
||||||
|
|
||||||
| 항목 | 예시 |
|
|
||||||
| --- | --- |
|
|
||||||
| 요청 서비스 | 한맥 ERP |
|
|
||||||
| 요청 시간 | 2026-06-23 15:30 |
|
|
||||||
| 요청 기기 | Chrome on Windows |
|
|
||||||
| 요청 위치/IP | 203.0.113.xxx |
|
|
||||||
| 요청 방식 | Baron Safe 승인 로그인 |
|
|
||||||
| 만료 시간 | 2분 후 만료 |
|
|
||||||
|
|
||||||
표준 기술:
|
|
||||||
|
|
||||||
- FCM/APNs: 모바일 푸시 알림 전달
|
|
||||||
- TLS API: 요청 상세 조회
|
|
||||||
- OAuth2 Bearer 또는 기기 서명 기반 앱 인증
|
|
||||||
|
|
||||||
주의 사항:
|
|
||||||
|
|
||||||
- 푸시 메시지 자체에 전화번호, 사용자 이름, RP 민감정보를 과도하게 넣지 않는다.
|
|
||||||
- 앱 상세 조회 API는 등록된 기기만 접근할 수 있어야 한다.
|
|
||||||
- 승인 화면에는 "본인이 방금 요청한 로그인이 맞습니까?"를 명확히 표시한다.
|
|
||||||
|
|
||||||
### 6.4 사용자 승인 프로세스
|
|
||||||
|
|
||||||
프로세스:
|
|
||||||
|
|
||||||
1. 사용자가 `baron-safe` 앱을 연다.
|
|
||||||
2. 앱이 OS 생체 인증, 앱 PIN, 또는 패스키로 사용자 확인을 수행한다.
|
|
||||||
3. 사용자가 요청 정보를 확인한다.
|
|
||||||
4. 사용자가 `승인` 또는 `거절`을 선택한다.
|
|
||||||
5. 앱은 승인 응답 payload를 생성한다.
|
|
||||||
6. 앱은 payload에 기기 private key로 서명한다.
|
|
||||||
7. 앱이 Baron SSO에 승인 응답을 제출한다.
|
|
||||||
|
|
||||||
승인 응답 예시:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"authReqId": "ars_01J...",
|
|
||||||
"deviceId": "dev_01J...",
|
|
||||||
"decision": "approve",
|
|
||||||
"nonce": "n_01J...",
|
|
||||||
"userPresence": true,
|
|
||||||
"userVerification": "biometric",
|
|
||||||
"approvedAt": "2026-06-23T15:31:02+09:00",
|
|
||||||
"signature": "base64url(jws-signature)"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
생성되는 데이터:
|
|
||||||
|
|
||||||
| 데이터 | 생성 주체 | 설명 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| decision | Baron Safe | approve/reject |
|
|
||||||
| user_presence | Baron Safe | 사용자가 앱을 조작했는지 |
|
|
||||||
| user_verification | Baron Safe | biometric/pin/passkey |
|
|
||||||
| signature | Baron Safe | 승인 응답 위변조 방지 |
|
|
||||||
| approved_at | Baron Safe/Backend | 승인 시각 |
|
|
||||||
|
|
||||||
표준 기술:
|
|
||||||
|
|
||||||
- JWS 또는 COSE 서명
|
|
||||||
- OS 생체 인증 API
|
|
||||||
- 선택 적용: FIDO2/WebAuthn user verification
|
|
||||||
|
|
||||||
주의 사항:
|
|
||||||
|
|
||||||
- "승인"은 반드시 사용자 확인 이후에만 가능해야 한다.
|
|
||||||
- 앱 백그라운드에서 자동 승인하면 안 된다.
|
|
||||||
- 동일 요청에 대한 중복 승인/재전송은 거부해야 한다.
|
|
||||||
|
|
||||||
### 6.5 서버 검증 및 로그인 완료 프로세스
|
### 6.5 서버 검증 및 로그인 완료 프로세스
|
||||||
|
|
||||||
프로세스:
|
프로세스(서버 측 상세 작업 — 앱에서 승인(decision=approve) 제출 후 Baron SSO가 수행할 처리 로직):
|
||||||
|
|
||||||
1. Baron SSO가 `auth_req_id`의 상태를 조회한다.
|
1. 수신 검증(입력 유효성)
|
||||||
2. 요청이 pending인지 확인한다.
|
- 수신된 payload에서 authReqId, deviceId, decision, nonce, approvedAt, (선택)devicePhoneNumberLast4, signature 등을 파싱.
|
||||||
3. 만료 여부를 확인한다.
|
- 필수 필드 누락 시 400 반환 및 감사로그 기록.
|
||||||
4. 제출된 `device_id`가 해당 사용자에게 등록된 기기인지 확인한다.
|
|
||||||
5. 저장된 public key로 signature를 검증한다.
|
|
||||||
6. nonce가 일치하고 재사용되지 않았는지 확인한다.
|
|
||||||
7. 승인 결과가 approve이면 인증 완료 상태로 전환한다.
|
|
||||||
8. Kratos subject를 확정한다.
|
|
||||||
9. Hydra `AcceptLoginRequest`를 호출한다.
|
|
||||||
10. RP로 redirect 또는 token 교환 흐름을 진행한다.
|
|
||||||
|
|
||||||
서버 상태 전이:
|
2. 권한·상태 확인(원자적 검사/전이)
|
||||||
|
- DB/Redis에서 auth_req 레코드를 조회(행 잠금/트랜잭션 사용).
|
||||||
|
- 현재 상태가 pending인지 확인. pending이 아니면 idempotent 응답(이미 approved/rejected/expired 등) 반환.
|
||||||
|
- expires_at 검증(만료된 요청이면 상태를 expired로 전이하고 거부 처리).
|
||||||
|
|
||||||
| 이전 상태 | 이벤트 | 다음 상태 |
|
3. 기기 등록·일치 확인
|
||||||
| --- | --- | --- |
|
- 제출된 deviceId가 auth_req에 연관된 user_id에 등록된 기기인지 확인.
|
||||||
| pending | 앱 승인 성공 | approved |
|
- DB에 저장된 push_token/플랫폼/등록 전화번호 해시 등과 기본 일치 검사 수행.
|
||||||
| pending | 앱 거절 | rejected |
|
- 불일치 시 거부 및 보안 경고(로그, 관리자 알림).
|
||||||
| pending | TTL 만료 | expired |
|
|
||||||
| approved | Hydra accept 성공 | completed |
|
|
||||||
| any | 재사용/위조 시도 | blocked 또는 failed |
|
|
||||||
|
|
||||||
표준 기술:
|
4. 서명 검증(앱이 서명하는 구현인 경우)
|
||||||
|
- 저장된 public_key(JWK)로 JWS/COSE 서명 검증.
|
||||||
|
- signature 불일치 시:
|
||||||
|
- 해당 deviceId의 시도 횟수 증가 및 임계치 초과 시 기기 차단.
|
||||||
|
- 감사로그와 알림 생성.
|
||||||
|
- 거부 응답 반환.
|
||||||
|
|
||||||
- OIDC login challenge accept
|
대체(앱이 서명하지 않는 모델인 경우):
|
||||||
- OAuth2 Authorization Code + PKCE
|
- 서명 검증 대신 다음 신호들을 결합한 위험평가 수행:
|
||||||
- JWS signature verification
|
- push 전송 성공 기록(FCM/APNs 응답)과 앱의 approvedAt 타임스탬프의 시간차(허용 보정값, 권장 60–180초).
|
||||||
- OIDC `amr`, `acr` claim 확장
|
- 앱에서 제출한 전화번호 일부(예: 마지막4자리)와 서버 저장 번호 확인.
|
||||||
|
- 요청 IP/UA/위치와 기존 프로필의 일치도.
|
||||||
|
- device attestation(Play Integrity/App Attest) 결과 유무.
|
||||||
|
- 비정상 반복/속도 패턴 탐지.
|
||||||
|
|
||||||
권장 claim:
|
5. nonce/재사용 방지
|
||||||
|
- 제출 nonce가 auth_req에 기록된 nonce와 일치하는지 검사.
|
||||||
|
- nonce 재사용 시 거부 및 보안 처리(로그·차단).
|
||||||
|
|
||||||
| claim | 예시 | 설명 |
|
6. 리스크 스코어링 및 정책 결정
|
||||||
| --- | --- | --- |
|
- 위 항목들(서명 검증 결과, push 타임스탬프, 전화번호 매칭, attestation, IP/위치 일치, rate-limit)으로 리스크 점수 산출.
|
||||||
| amr | `["app_push", "device_key", "biometric"]` | 인증 수단 |
|
- 리스크가 허용 임계값 이하이면 승인 진행, 초과 시 추가 인증(예: SMS OTP) 요구 또는 거부 처리.
|
||||||
| acr | `baron:safe:aal2` | Baron 내부 인증 강도 |
|
|
||||||
| auth_time | Unix timestamp | 사용자 승인 시각 |
|
|
||||||
| sid | session id | 세션 관리 |
|
|
||||||
|
|
||||||
주의 사항:
|
7. 인증 상태 전이 및 세션 수립
|
||||||
|
- auth_req 상태를 approved로 전이(원자적 업데이트).
|
||||||
|
- Kratos 사용 시:
|
||||||
|
- 기존 세션 확인: 이미 유효한 세션이 있으면 세션 정보 갱신.
|
||||||
|
- 세션이 없으면 Kratos Admin API를 통해 세션 생성(또는 필요한 identity 확인 후 세션 수립).
|
||||||
|
- Hydra와 연동:
|
||||||
|
- Hydra의 AcceptLoginRequest 호출:
|
||||||
|
- subject: Kratos identity id
|
||||||
|
- context: amr, acr, auth_time, sid 등 (권장)
|
||||||
|
- remember / remember_for 등은 정책에 따라 설정
|
||||||
|
- Hydra가 반환한 redirect URL 또는 authorization result를 poll 응답에 반영.
|
||||||
|
|
||||||
- `amr`/`acr`을 통해 일반 비밀번호 로그인, SMS OTP, Baron Safe 승인을 구분해야 한다.
|
8. 토큰 발행 흐름(표준 유지)
|
||||||
- 민감 RP는 특정 `acr` 이상만 허용하도록 정책화할 수 있다.
|
- 이후 RP는 기존 OIDC Authorization Code + PKCE 교환 절차를 통해 토큰을 발급받음(Hydra 책임).
|
||||||
- 승인 완료 후에도 기존 OIDC/OAuth2 토큰 발급은 Hydra 표준 흐름을 유지하는 것이 좋다.
|
- Baron SSO는 발급 관련 추가 제어(특정 RP에 대해 acr 조건 검증 등)를 수행.
|
||||||
|
|
||||||
## 7. API 초안
|
9. 감사·알림·정리
|
||||||
|
- 승인 이벤트를 감사 로그에 남김(필수 항목: auth_req_id, user_id, client_id, device_id, request_ip, request_user_agent, decision, user_verification, signature_valid 여부, completed_at).
|
||||||
|
- 사용자(및 필요 시 관리자)에게 승인 완료 알림(선택) 발송.
|
||||||
|
- auth_req 레코드 정리(만료/완료 후 TTL 후 삭제 또는 아카이빙).
|
||||||
|
- 모니터링/metrics(승인율, 실패율, 서명 불일치 건수 등) 수집.
|
||||||
|
|
||||||
### 7.1 승인 요청 생성
|
10. 실패/이상 처리
|
||||||
|
- 검증 실패(서명 불일치, device 미등록, nonce 불일치 등)는 상태를 failed/blocked로 전이.
|
||||||
|
- 실패 사유에 따라:
|
||||||
|
- 즉시 사용자에게 거부 알림.
|
||||||
|
- 고위험 징후 시 기기 즉시 차단 및 관리자 알림.
|
||||||
|
- 폴백 흐름(예: SMS OTP 발송, 이메일 확인) 트리거 가능.
|
||||||
|
- 반복적 실패 시 rate-limit 및 계정 잠금 정책 적용.
|
||||||
|
|
||||||
내부 또는 RP backchannel API:
|
운영·구현 권장사항(간단 요약):
|
||||||
|
- 모든 상태 전이는 원자적이어야 하며 동시성 경합을 막기 위해 DB 락 또는 CAS 사용.
|
||||||
|
- idempotency 처리: 동일 승인 제출이 여러번 들어와도 안전하게 처리.
|
||||||
|
- TTL과 시간 동기 허용 오차(예: 서버-앱 간 시차 30초) 정책 정의.
|
||||||
|
- 서명 미사용 시 리스크 보정(더 짧은 TTL, 강한 attestation, 추가 인증 폴백).
|
||||||
|
- 감사 로그는 비가역 저장소(immutable)로 보관하고, 관련 이벤트는 SIEM으로 전송.
|
||||||
|
- 민감 RP의 경우 서버에서 추가 확인이 필요한 정책(예: 서명 필수, attestation 필수)을 강제.
|
||||||
|
|
||||||
```text
|
간단한 의사 코드(pseudocode):
|
||||||
POST /api/v1/auth/baron-safe/login/init
|
|
||||||
|
```pseudo
|
||||||
|
// POST /api/v1/auth/baron-safe/requests/{authReqId}/decision handler
|
||||||
|
payload = parse(request.body)
|
||||||
|
auth = db.getAuthReq(payload.authReqId)
|
||||||
|
if auth == null or auth.status != "pending": return idempotentResponse(auth.status)
|
||||||
|
if auth.expires_at < now(): db.update(authReqId, status="expired"); return expiredResponse()
|
||||||
|
|
||||||
|
device = db.getDevice(payload.deviceId)
|
||||||
|
if device.user_id != auth.user_id: return error("device mismatch")
|
||||||
|
|
||||||
|
if payload.signature:
|
||||||
|
if not verifySignature(payload, device.public_key): handleSignatureFailure()
|
||||||
|
else:
|
||||||
|
score = riskScore(payload, auth, device, pushLogs, attestation)
|
||||||
|
if score > threshold: triggerFallbackOrReject()
|
||||||
|
|
||||||
|
// all checks passed
|
||||||
|
db.update(authReqId, status="approved", approved_at=now(), approver_device=device.id)
|
||||||
|
kratos.ensureSession(auth.user_id)
|
||||||
|
hydra.acceptLogin(auth.login_challenge, subject=auth.user_id, acr=selected_acr, amr=selected_amr)
|
||||||
|
audit.log(approved event)
|
||||||
|
return { status: "approved" }
|
||||||
```
|
```
|
||||||
|
|
||||||
요청:
|
// ...existing code...
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"phoneNumber": "010-1234-5678",
|
|
||||||
"login_challenge": "hydra-login-challenge",
|
|
||||||
"client_id": "hanmac-erp"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
응답:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"authReqId": "ars_01J...",
|
|
||||||
"status": "pending",
|
|
||||||
"expiresIn": 120,
|
|
||||||
"interval": 2
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7.2 요청 기기 Poll
|
|
||||||
|
|
||||||
```text
|
|
||||||
POST /api/v1/auth/baron-safe/login/poll
|
|
||||||
```
|
|
||||||
|
|
||||||
요청:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"authReqId": "ars_01J..."
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
응답 예시:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"status": "authorization_pending",
|
|
||||||
"interval": 2
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
승인 완료 시:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"status": "ok",
|
|
||||||
"redirectTo": "https://sso.example.com/oauth2/auth?..."
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7.3 앱 요청 상세 조회
|
|
||||||
|
|
||||||
```text
|
|
||||||
GET /api/v1/auth/baron-safe/requests/{authReqId}
|
|
||||||
```
|
|
||||||
|
|
||||||
응답:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"authReqId": "ars_01J...",
|
|
||||||
"clientName": "한맥 ERP",
|
|
||||||
"clientId": "hanmac-erp",
|
|
||||||
"requestDevice": "Chrome on Windows",
|
|
||||||
"requestIpAddress": "203.0.113.xxx",
|
|
||||||
"requestedAt": "2026-06-23T15:30:00+09:00",
|
|
||||||
"expiresAt": "2026-06-23T15:32:00+09:00",
|
|
||||||
"nonce": "n_01J..."
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7.4 앱 승인/거절 제출
|
|
||||||
|
|
||||||
```text
|
|
||||||
POST /api/v1/auth/baron-safe/requests/{authReqId}/decision
|
|
||||||
```
|
|
||||||
|
|
||||||
요청:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"deviceId": "dev_01J...",
|
|
||||||
"decision": "approve",
|
|
||||||
"nonce": "n_01J...",
|
|
||||||
"userPresence": true,
|
|
||||||
"userVerification": "biometric",
|
|
||||||
"approvedAt": "2026-06-23T15:31:02+09:00",
|
|
||||||
"signature": "base64url-signature"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
응답:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"status": "approved"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## 8. 보안 요구사항
|
|
||||||
|
|
||||||
### 8.1 필수 요구사항
|
|
||||||
|
|
||||||
- `baron-safe` 기기는 사전에 사용자 계정에 등록되어야 한다.
|
|
||||||
- 기기별 private key는 서버에 저장하지 않는다.
|
|
||||||
- 승인 응답은 기기 private key로 서명해야 한다.
|
|
||||||
- 승인 요청은 짧은 TTL을 가져야 한다.
|
|
||||||
- nonce는 요청별 1회용이어야 한다.
|
|
||||||
- 동일 요청의 중복 승인, 만료 후 승인, 다른 기기의 승인은 거부한다.
|
|
||||||
- 앱 승인 전 사용자 확인을 수행한다.
|
|
||||||
- 모든 통신은 TLS를 사용한다.
|
|
||||||
- 승인/거절/만료/실패를 감사 로그로 남긴다.
|
|
||||||
|
|
||||||
### 8.2 권장 요구사항
|
|
||||||
|
|
||||||
- 기기 등록 시 기존 표준 로그인 또는 관리자 초대를 요구한다.
|
|
||||||
- 기기 변경/해제 시 사용자와 관리자에게 알림을 보낸다.
|
|
||||||
- 고위험 RP는 WebAuthn 또는 추가 PIN을 요구한다.
|
|
||||||
- 푸시 피로 공격 방지를 위해 단기간 반복 요청을 제한한다.
|
|
||||||
- 승인 화면에 number matching 또는 request code를 추가한다.
|
|
||||||
- 위치/IP가 평소와 다르면 경고를 표시한다.
|
|
||||||
- `baron-safe` 인증으로 생성된 세션은 일반 세션과 구분 표시한다.
|
|
||||||
|
|
||||||
## 9. 표준 기술 적용 가능성
|
|
||||||
|
|
||||||
| 영역 | 적용 가능한 표준/기술 | 적용 방식 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| Out-of-Band 인증 | OpenID Connect CIBA | 앱 승인 기반 비동기 인증 모델 |
|
|
||||||
| RP 최종 로그인 | OIDC Authorization Code + PKCE | 기존 Hydra 흐름 유지 |
|
|
||||||
| RP backchannel 인증 | `private_key_jwt`, mTLS | RP가 승인 요청 생성 시 자신을 인증 |
|
|
||||||
| 승인 응답 서명 | JWS/JWK 또는 COSE | 등록 기기의 private key로 승인 payload 서명 |
|
|
||||||
| 기기 내 사용자 확인 | WebAuthn/FIDO2/passkey, OS biometric | 앱 승인 전 사용자 검증 |
|
|
||||||
| 제한 장치 대안 | OAuth2 Device Authorization Grant | TV/CLI/키오스크형 입력 제한 장치에 응용 가능 |
|
|
||||||
| 요청 보안 강화 | Pushed Authorization Requests(PAR) | RP 인증 요청 변조/노출 축소 |
|
|
||||||
| 세션 관리 | OIDC Back-Channel Logout | RP 로그아웃 전파 |
|
|
||||||
| 토큰 취소 | OAuth2 Token Revocation | refresh token 무효화 |
|
|
||||||
|
|
||||||
## 10. 앱 기술 스택 제안
|
|
||||||
|
|
||||||
`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을 공식 지원한다.
|
|
||||||
|
|
||||||
장점:
|
|
||||||
|
|
||||||
- 표준 정합성이 가장 높다.
|
|
||||||
- RP와의 장기적 상호운용성이 좋다.
|
|
||||||
- Poll/Ping/Push mode를 명확히 정의할 수 있다.
|
|
||||||
|
|
||||||
단점:
|
|
||||||
|
|
||||||
- Hydra에서 CIBA를 직접 지원하지 않는 경우 구현 범위가 커진다.
|
|
||||||
- discovery metadata, client registration, token grant 확장이 필요하다.
|
|
||||||
|
|
||||||
### 11.2 CIBA 스타일 내부 브로커 방식
|
|
||||||
|
|
||||||
Baron Backend가 CIBA와 유사한 승인 브로커 역할을 하고, 최종 로그인 완료는 기존 Hydra `AcceptLoginRequest`로 연결한다.
|
|
||||||
|
|
||||||
장점:
|
|
||||||
|
|
||||||
- 현재 Baron SSO 구조에 적용하기 쉽다.
|
|
||||||
- 기존 OIDC Authorization Code + PKCE 흐름을 유지할 수 있다.
|
|
||||||
- 단계적 도입이 가능하다.
|
|
||||||
|
|
||||||
단점:
|
|
||||||
|
|
||||||
- 외부 표준 CIBA endpoint로 바로 공개되지는 않는다.
|
|
||||||
- 내부 API 명세와 보안 검증을 엄격히 관리해야 한다.
|
|
||||||
|
|
||||||
권장:
|
|
||||||
|
|
||||||
- 초기 도입은 11.2 방식이 현실적이다.
|
|
||||||
- 이후 RP 요구가 커지면 11.1 방식으로 확장한다.
|
|
||||||
|
|
||||||
### 11.3 Device Authorization Grant 응용 방식
|
|
||||||
|
|
||||||
키오스크, TV, CLI처럼 입력이 제한된 기기에는 OAuth2 Device Authorization Grant를 응용할 수 있다.
|
|
||||||
|
|
||||||
장점:
|
|
||||||
|
|
||||||
- 표준 RFC가 명확하다.
|
|
||||||
- 사용자가 다른 기기에서 승인하는 모델이다.
|
|
||||||
|
|
||||||
단점:
|
|
||||||
|
|
||||||
- 사용자가 user code를 입력하는 UX가 기본 모델이다.
|
|
||||||
- 휴대폰 번호 기반 push 승인과는 CIBA보다 덜 직접적이다.
|
|
||||||
|
|
||||||
## 12. 도입 단계 제안
|
|
||||||
|
|
||||||
### Phase 1: 내부 승인 브로커 MVP
|
|
||||||
|
|
||||||
- `baron-safe` 기기 등록 모델 추가
|
|
||||||
- Android/iOS 공통 앱 MVP 구현
|
|
||||||
- 승인 요청 생성 API 추가
|
|
||||||
- 앱 요청 상세 조회 API 추가
|
|
||||||
- 앱 승인/거절 API 추가
|
|
||||||
- 요청 기기 poll API 추가
|
|
||||||
- Hydra `AcceptLoginRequest` 연계
|
|
||||||
- 감사 로그 추가
|
|
||||||
|
|
||||||
### 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 정책
|
|
||||||
- 관리자 화면에서 기기 등록/해제 관리
|
|
||||||
|
|
||||||
### Phase 3: 표준 확장
|
|
||||||
|
|
||||||
- CIBA discovery metadata 검토
|
|
||||||
- backchannel authentication endpoint 공개 여부 검토
|
|
||||||
- `urn:openid:params:grant-type:ciba` 지원 검토
|
|
||||||
- Ping/Poll delivery mode 정식화
|
|
||||||
- PAR/JAR 적용 검토
|
|
||||||
|
|
||||||
## 13. 운영 정책 제안
|
|
||||||
|
|
||||||
### 13.1 인증 강도 구분
|
|
||||||
|
|
||||||
`baron-safe` 승인 로그인은 다음과 같이 별도 인증 강도로 관리한다.
|
|
||||||
|
|
||||||
| 인증 방식 | 예시 ACR | 설명 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| 전화번호 단독 | `baron:phone:identifier-only` | 운영 로그인 비권장 |
|
|
||||||
| SMS OTP | `baron:phone:sms-otp` | 전화번호 소유 확인 |
|
|
||||||
| Baron Safe 앱 승인 | `baron:safe:app-approval` | 등록 앱 승인 |
|
|
||||||
| Baron Safe + 생체 인증 | `baron:safe:aal2` | 앱 승인 + 사용자 확인 |
|
|
||||||
| WebAuthn/passkey | `baron:webauthn:phishing-resistant` | 피싱 저항 인증 |
|
|
||||||
|
|
||||||
### 13.2 RP별 접근 정책
|
|
||||||
|
|
||||||
- 일반 RP: Baron Safe 앱 승인 허용
|
|
||||||
- 민감 RP: Baron Safe + 생체 인증 또는 WebAuthn 요구
|
|
||||||
- 관리자 RP: WebAuthn 또는 추가 MFA 요구
|
|
||||||
- 외부망 RP: IP/위치 이상 탐지 시 추가 인증 요구
|
|
||||||
|
|
||||||
### 13.3 감사 로그 항목
|
|
||||||
|
|
||||||
| 항목 | 설명 |
|
|
||||||
| --- | --- |
|
|
||||||
| auth_req_id | 승인 요청 ID |
|
|
||||||
| user_id | 대상 사용자 |
|
|
||||||
| client_id | 요청 RP |
|
|
||||||
| device_id | 승인 앱 기기 |
|
|
||||||
| request_ip | 요청 기기 IP |
|
|
||||||
| request_user_agent | 요청 기기 User-Agent |
|
|
||||||
| decision | approve/reject/expired |
|
|
||||||
| user_verification | biometric/pin/passkey/none |
|
|
||||||
| signature_valid | 서명 검증 결과 |
|
|
||||||
| completed_at | 로그인 완료 시각 |
|
|
||||||
|
|
||||||
## 14. 주요 위험과 대응
|
|
||||||
|
|
||||||
| 위험 | 설명 | 대응 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| 푸시 피로 공격 | 공격자가 반복 승인 요청을 보내 사용자가 실수 승인 | rate limit, number matching, 반복 요청 차단 |
|
|
||||||
| 휴대폰 분실 | 등록 앱이 설치된 기기 분실 | 원격 기기 해제, 관리자 잠금, 생체 인증 필수 |
|
|
||||||
| 푸시 토큰 탈취 | 알림 토큰 유출 | push token은 인증 수단으로 사용하지 않음 |
|
|
||||||
| 앱 위조 | 공격자가 가짜 앱으로 승인 시도 | 기기 private key 서명 검증 |
|
|
||||||
| 앱 무결성 훼손 | 루팅/탈옥/디버그 환경에서 승인 조작 | Play Integrity, App Attest, 고위험 RP 제한 |
|
|
||||||
| 요청 변조 | RP 정보 또는 요청 ID 변조 | 서버 저장 요청 기준 검증, nonce, signature |
|
|
||||||
| 사용자 열람 | 전화번호 입력으로 가입 여부 추론 | 응답 메시지 일반화, rate limit |
|
|
||||||
| RP 오남용 | 허용되지 않은 RP가 승인 요청 생성 | client authentication, allowlist |
|
|
||||||
|
|
||||||
## 15. 팀장 보고용 최종 제안
|
|
||||||
|
|
||||||
`baron-safe` 앱 승인 방식은 "전화번호만으로 로그인"이 아니라 "전화번호로 사용자를 식별하고, 등록된 모바일 인증 장치에서 사용자가 승인하는 로그인"으로 정의해야 한다.
|
|
||||||
|
|
||||||
이렇게 정의하면 다음 장점이 있다.
|
|
||||||
|
|
||||||
- Baron SSO 사용자가 등록된 내부/외부 사용자로 제한되므로 앱 설치와 기기 등록을 보안 절차로 수용시키기 쉽다.
|
|
||||||
- 전화번호 단독 로그인의 비표준/저보증 문제를 해결한다.
|
|
||||||
- 사용자는 요청 RP와 요청 기기를 확인하고 승인할 수 있다.
|
|
||||||
- OIDC CIBA와 유사한 표준 모델로 설명 가능하다.
|
|
||||||
- 기존 Hydra 기반 OIDC Authorization Code + PKCE 흐름을 유지할 수 있다.
|
|
||||||
- 감사 로그, RP별 정책, 세션 관리와 자연스럽게 연결된다.
|
|
||||||
|
|
||||||
권장 구현 방향은 다음과 같다.
|
|
||||||
|
|
||||||
1. 1차로 Baron Backend가 CIBA 스타일 내부 승인 브로커 역할을 수행한다.
|
|
||||||
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 알림 자체를 인증 수단으로 오해해서는 안 되며, 반드시 등록 기기의 서명 검증과 사용자 확인 절차가 포함되어야 한다.
|
|
||||||
Reference in New Issue
Block a user