Passkey B2B 원년: 소비자에서 엔터프라이즈로
- ~2024년에 Apple, Google, Microsoft가 일제히 추진한 Passkey는 처음에는 소비자용 인증 수단으로 확산되었습니다. 그러나 2025년 하반기부터 B2B 채택이 급속히 진행되어, 2026년은 "Passkey B2B 전개 원년"이라 부를 수 있는 상황이 되었습니다. Okta, Entra ID, Google Workspace, 1Password Business 모두가 Cross-Device Passkey와 동기 Passkey를 양쪽 지원하며, FIDO2 준수 보안 키(YubiKey 5C, Google Titan)와 병존 운용할 수 있는 설계로 성숙했습니다.
B2B에서 Passkey가 본격 도입되는 최대 이유는 피싱 내성입니다. 2024~2025년, 일본 기업을 타깃으로 한 AiTM(Adversary-in-the-Middle) 피싱 킷이 급증했습니다. 기존의 TOTP나 SMS OTP는 중간자 프록시를 통한 인증 세션 탈취 공격에 취약하며, 국내 대형 SaaS에서 수천 계정이 하룻밤에 침해되는 사건이 여러 건 발생했습니다. Passkey(WebAuthn)는 도메인 바인딩에 의해 피싱 사이트에서는 서명이 성립하지 않기 때문에, AiTM에 대해 구조적으로 내성을 가집니다. "운용으로 주의한다"가 아니라 "프로토콜로 담보된다"는 점이 경영 판단의 근거가 되었습니다.
동기 Passkey(iCloud Keychain, Google Password Manager 경유)와 디바이스 바인드 Passkey(YubiKey 등에 한정)의 트레이드오프는 계속되는 논점입니다. 금융·방위 계열은 디바이스 바인드를 선호하고, 폭넓은 직원 전개에는 동기 Passkey가 현실적입니다. NIST SP 800-63B의 2025년 개정에서 동기 Passkey가 AAL2로 인정된 것은 정책 수립의 순풍이 되고 있습니다.
WebAuthn 구현의 함정과 계정 복구
처음에 막히는 것은 RP ID(Relying Party ID)의 설계입니다. RP ID는 도메인 단위이기 때문에 `corp.example.jp`와 `portal.example.jp`에서 별도의 Passkey 등록이 필요합니다. 통합하고 싶은 경우에는 부모 도메인 `example.jp`를 RP ID로 해야 하지만, 부모 도메인을 마케팅 사이트와 공유하는 조직에서는 영향을 신중하게 평가해야 합니다.
계정 복구는 Passkey 운용 최대의 난관입니다. 복구 설계를 소홀히 하면 백업 수단으로 취약한 인증(이메일 OTP, SMS OTP)이 온존되어, 보안 강도는 잔존 백업 수단으로 끌어내려집니다. 권장되는 것은 3계층 설계입니다. 경도 복구(다른 단말에서의 재로그인)는 동기 Passkey로 자동 해결, 중도 복구(전체 단말 분실)는 관리자 승인 + 본인 확인 서류, 중도 복구(ID 변조 의심)는 오프라인 본인 확인 필수입니다. 중도 복구를 CS 경유로 하지 않는 것도 중요하며, CS의 소셜 엔지니어링 돌파가 2024년에 실제로 발생하고 있습니다.
SCIM과 프로비저닝 자동화
SCIM 2.0에 의한 자동 프로비저닝은 이제 선택지가 아니라 전제 조건입니다. IdP에서 각 SaaS로 SCIM 동기함으로써, 사용자 추가·속성 업데이트·비활성화가 실시간으로 전파됩니다. 주요 SaaS(Salesforce, Slack, Notion, GitHub Enterprise, Atlassian)는 SCIM 2.0을 기본 제공하며, 수신 측의 구현 품질도 2024년 대비 대폭 향상되었습니다.
SCIM 운용에서 간과되기 쉬운 것은 속성 매핑 설계입니다. IdP 측의 부서·직위·고용 구분을 SaaS 측의 그룹이나 권한 롤로 매핑하는 표를 HR과 정보 시스템 부서가 공동으로 유지할 수 있는 형태로 만들어야 합니다. Okta Workflows, Entra Lifecycle Workflows에는 노코드 UI가 있으며, IF 문 체인으로 표현하는 방식이 주류입니다. 스크립트 의존의 속성 변환은 반년 후 변경에 추적할 수 없게 되는 전형적인 패턴이 됩니다. CSV 일별 동기에서의 탈피 계획은 2026년 내부 감사에서 제시를 요구받는 경우가 늘고 있습니다.
SAML에서 OIDC로: 왜 지금인가
SAML은 B2B SSO의 오랜 표준이었지만, 2026년 시점에서 신규 프로젝트는 OIDC가 첫 번째 선택지가 되었습니다. 이유는 세 가지입니다. 첫 번째로 모바일·SPA 대응에서, SAML의 XML 리다이렉트는 PKCE를 사용하는 OIDC와 비교해 모바일 네이티브에서 번거롭습니다. 두 번째로 서명·암호화의 복잡성으로, SAML은 XML Signature 사양이 광범위하며 구현 차이로 인한 취약성(XML Signature Wrapping 공격 등)이 역사적으로 빈발했습니다. 세 번째로 인증(ID Token)과 API 인가(Access Token)를 구조적으로 분리할 수 있어, 마이크로서비스 환경에서의 권한 설계가 명확해집니다.
단, SAML 전폐는 현실적이지 않습니다. SAP SuccessFactors, Workday, Oracle Cloud의 일부는 SAML이 유일한 SSO입니다. 이행 전략은 "신규는 OIDC, 기존 SAML은 당분간 유지, IdP를 양대응 기반으로 집약"이 됩니다. 이행에서 막히는 것은 "속성 매핑 차이"로, 오랫동안 SAML 운용에서 만들어진 Assertion 변환 로직을 OIDC claim 설계에 이어받을 때, 그룹명 충돌이나 롤 스코프 불일치가 빈발합니다. 이행 전에 "현재 SAML Assertion 전속성을 나열하여 OIDC 표준 claim + 커스텀 claim으로의 매핑 표를 만든다"는 공정을 반드시 거치십시오.
Adaptive MFA와 step-up 인증
Adaptive MFA는 요청 문맥에 따라 인증 강도를 동적으로 조정하는 구조입니다. 평소에는 Passkey만으로 통과시키지만, 미지의 디바이스에서, 심야에, 처음인 국가에서 접속된 경우에만 추가 인증을 요구하는 조건 분기로 운용합니다. step-up 인증은 그 서브셋으로, "급여 데이터 열람" "프로덕션 배포" "고객 데이터 일괄 내보내기" 같은 고위험 조작 직전에 현재 세션의 인증 강도를 재평가하여, 부족하면 추가 인증을 요구합니다. OIDC의 acr(Authentication Context Class Reference) claim으로 "이 조작에는 acr=phr(phishing-resistant)이 필요"라고 선언하는 방식이 표준입니다.
설계에서 가장 어려운 것은 "오탐의 허용값"입니다. 너무 엄격하면 업무가 중단되고, 느슨하면 침해가 간과됩니다. 필자의 경험칙으로는 "기존 디바이스 + 기존 지역에서는 Passkey만" "미지 디바이스에서는 Passkey + step-up"에서 시작하여, 인시던트 이력과 위양성률을 월별 리뷰로 조정합니다.
일본 기업 특유의 충돌: 개인번호와 공유 계정
일본 기업에서 Passkey·SCIM·OIDC를 추진할 때, 해외 벤더 문서에는 없는 문화적 충돌이 발생합니다. 첫 번째로 "사원번호와 개인번호(마이넘버)의 취급". 개인번호는 번호법에 의해 이용 목적이 엄격하게 제한되어 있으며, IdP의 sub claim이나 SCIM의 externalId에 개인번호를 넣어서는 안 됩니다. 그러나 현장에서는 사원번호와 개인번호를 연결한 기간 시스템이 남아 있어, SCIM 동기 설계에서 개인번호를 실수로 외부 SaaS에 흘리는 인시던트가 발생하고 있습니다. 속성 매핑 표에는 "외부 유출 금지 속성"의 체크리스트가 필수입니다.
두 번째로 "공유 계정 문화"와의 충돌입니다. 일본의 중소~중견 기업에서는 `soumu@`, `keiri@` 같은 직책 부 공유 계정이 남아 있습니다. Passkey는 개인의 인증기에 연결되기 때문에, 공유 계정에 Passkey를 설정하면 "누가 로그인했는가"를 추적할 수 없게 됩니다. 이행 전략은 공유 계정을 기능 계정(Service Account)과 개인 계정으로 분리하여, 업무 이메일 수신은 기능 계정, 로그인은 개인 계정으로 행하는 설계로 재편하는 것입니다. 감사 로그의 가역성을 우선한다면 공유 로그인 자체를 전폐할 수밖에 없습니다. 세 번째로 "회사 지급 단말과 BYOD의 혼재"가 있으며, 관리 대상 단말만 동기 Passkey, BYOD는 하드웨어 키 필수로 하는 2계층 운용이 현실적입니다.
이행 로드맵
- ~18개월의 로드맵을 제시합니다. 제1단계(0~3개월)에서 IdP 기반 정비·SAML/OIDC 양대응·SCIM 수신 대응 SaaS 목록 작성. 제2단계(3~6개월)에서 Passkey 파일럿 전개·Adaptive MFA 초기 정책·SCIM 자동화의 우선 SaaS 10개. 제3단계(6~12개월)에서 전사 Passkey 전개·TOTP/SMS OTP 단계적 폐지·step-up의 앱 조합. 제4단계(12~18개월)에서 SAML 신규 금지·레거시 SAML의 OIDC 이행 또는 철수 판단·공유 계정 전폐. 경영층에 대한 설명은 "AiTM 상정 손해액"과 "감사 대응 공수 절감"의 2축이 효과적입니다. IdP를 중축으로 HR·ZTNA·SaaS 군을 통합하는 아이덴티티 운용 기반은 프로젝트 단위가 아니라 조직의 항상적 케이퍼빌리티로 격상되고 있습니다.