사실 대부분의 사람들은 아이디가 단순히 사용자 이름과 비밀번호라고 생각합니다.입력하고 액세스 권한을 얻으면 끝이죠.하지만 고객을 상대하는 기업이라면 아이디는 훨씬 더 복잡해집니다.수천 명의 사람들이 앱에 가입하거나 또 다른 비밀번호를 만드는 대신구글 계정으로 로그인하게 하려면 어떻게 해야 할까요?그리고 직원 디렉터리와 섞이지 않게 모든 고객 데이터를 안전하게 유지하려면 어떻게 해야 할까요?그것이 바로 마이크로소프트 엔트라 엑스터널 아이디가 해결하고자 하는 문제입니다.핵심은이 겁니다.이 서비스가 에이저 ADBC를 완전히 대체합니다.이번 에피소드가 끝날 때 쯤이면 엑스터널 아이디가 정확히 무엇인지주요 활용방법 3가지는 무엇인지그리고 고객용 앱에 왜 중요한지 이해하게 될 것입니다.예전 방식은 별도의 아이디 사일로였습니다. 20년 전으로 돌아가 고객용 앱을 만들었다고 상상해보세요.당시에는 직접 로그인 시스템을 구축하고 비밀번호 코드를 작성하고저장할 데이터베이스를 설정하고 비밀번호 찾기 흐름까지 모두 처음부터 만들어야 했습니다.사용자가 수백 명인 작은 앱에는 괜찮았지만앱이 성장함에 따라 상황은 빠르게 복잡해졌습니다.기업들은 사용자가 구글이나 페이스북으로 로그인하게 하고다단계 인증이 필요했으며 오류 없이 수백만 개의 계정을 처리해야 했습니다.그 모든 것을 직접 구축하는 것은 악몽이 되었습니다.마이크로소프트 위 첫 번째 답변은 에이저 ADBC였습니다.이는 고객 아이디 서비스였으며 당시에는 실질적인 문제를 해결해주었습니다.하지만 여기서부터 고통이 시작되었습니다.가장 큰 문제는 사용자 지정 정책, 커스텀 팔러시스 이라는 것이었고이 정책들은 XML로 작성되었습니다.수백 줄에 달하는 XML 파일을 다뤄본 적이 있다면그게 얼마나 고통스러운지 잘 아실 겁니다.설정도 어렵고 디버깅도 힘들며문제가 발생하면 원인을 알아내기가 매우 어려웠습니다.

게다가 에이저 ADBC는 마이크로소프트 위 메인 아이디 플랫폼과 분리되어 있었습니다.따라서 이미 직원을 위해 마이크로소프트 365나 에이저 AD를 사용하고 있더라도BEC는 완전히 새로운 제품을 배우는 것처럼 느껴졌습니다.예상대로 IT팀은 유지관리에 어려움을 겪었고개발자는 작업을 기피했으며고객은 불편한 가입 경험 때문에 떠나고 싶어 했습니다.마이크로소프트는 더 간단하고 통합된 무언가가 필요하다는 것을 깨달았고그것이 바로 마이크로소프트 엔트라 엑스터널 아이디가 되었습니다.마이크로소프트 엔트라 엑스터널 아이디란 무엇인가?그렇다면 마이크로소프트 엔트라 엑스터널 아이디는 정확히 무엇일까요?가장 간단한 정의는 이렇습니다.직원이 아닌 외부 사용자, 고객, 파트너 및 게스트를 위한 클라우드 아이디 서비스입니다.이렇게 생각해보세요.여러분의 회사가 사무용 빌딩을 가지고 있다고 상상해보세요.그것이 바로 여러분의 워크포스 테넌트, 워크포스 터넌트입니다.직원들이 일하는 곳, 이자 책상이 있는 곳, 출입증으로 드나드는 바로 그 곳입니다.엔트라 아이디가 그 건물을 관리하죠.이제 고객을 위한 매장을 연다고 상상해보세요.별도의 공간에 자체 출입구와 규칙, 고유한 보안을 갖춘 곳 말입니다.고객이 직원 휴게실에 들어오지 않고, 직원이 실수로 고객 계정에 접근하지도 않습니다.그것이 바로 엑스터널 아이디입니다.마이크로소프트 엔트라 제품군에 속하지만 성격은 조금 다릅니다.고객 아이덴티티 및 액세스 관리, CIAM를 위해 구축되었으며 외부 사용자의 전체 수명 주기를 처리합니다.가입, 로그인, 암호 재설정, 프로필 관리, MFA, 토큰 발급까지 지원합니다.워스 2.0, 오픈 아이디 커넥트, SAML 같은 표준 프로토콜과 호환됨으로 거의 모든 앱을 연결할 수 있습니다.하지만 기존 에이저 ADBC와는 큰 차이가 있습니다.엑스터널 아이디는 더 간단합니다.

더 이상 복잡한 사용자 지정 XML 정책은 필요 없습니다.대신 관리센터에서 직접 사용자 흐름을 구성하면 됩니다.또는 기존 백엔드 로직에 연결되는 사용자 지정 인증 확장을 사용할 수 있습니다.기능은 그대로 번거로움은 줄었습니다.세 가지 핵심 사용 사례를 살펴보겠습니다.그렇다면 엑스터널 아이디를 실제로 어떻게 사용할까요?세 가지 주요 시나리오가 있습니다.직원이 아닌 외부 사용자를 관리해야 하는 거의 모든 상황을 포괄합니다.가장 일반적인 고객 아이덴티티, 즉 BEC부터 시작해보죠.피자 주문 앱을 만든다고 상상해보세요.사람들이 가입하고 주문하며 다음 주에도 다시 찾게 해야 합니다.새로운 암호를 만들게 하는 대신 구글 계정으로 로그인하게 하고이름, 전화번호, 배달 선호사항 등을 수집해야 합니다.엑스터널 아이디 가입 모든 것을 처리합니다.미리 구축된 가입 및 로그인 흐름을 제공합니다.이름, 전화번호 등 필요한 속성을 선택하여 수집하도록 구성할 수 있습니다.구글, 페이스북, 애플을 통한 소셜 로그인을 설정하세요.사용자가 인증하면 엑스터널 아이디가 앱에 토큰을 발급하여 해당 사용자가 누구인지 알 수 있게 합니다.이것이 에이저 ADBC를 대체하며 대부분의 조직이 시작하는 지점입니다.또 다른 시나리오는 기업 간 협업, 즉 BEB입니다.파트너나 공급업체에게 내부 앱에 대한 액세스 권한을 제공해야 할 때 사용합니다.외부 물류 파트너가 확인해야 할 셔어포인트, 사이트나 프리랜서 디자이너가 사용하는 프로젝트 관리 도구가 있을 수 있죠.이 시나리오에서는 그들을 워크포스 테넌트의 게스트 사용자로 초대합니다.엑스터널 아이디는 초대 이메일, 초대 수락 절차, 그리고 볼 수 있는 범위를 제어하는 액세스 정책을 관리합니다.이 기능은 사실 에이저 ADNA-BEB 협업으로 이미 수년간 사용되어 왔습니다.하지만 이제는 엑스터널 아이디 위 일부가 되었으므로 고객 아이디와 동일한 곳에서 관리할 수 있습니다.

다음은 기기 간 통신, 즉 MEM입니다.이는 최종 사용자에게 덜 드러나지만 똑같이 중요합니다.때로는 백엔드 서비스가 다른 API, 결제 프로세서, 데이터 분석 서비스 또는 내부 마이크로 서비스와 통신해야 합니다.사람이 관여하지 않고 한 애플리케이션이 다른 애플리케이션을 호출하는 방식입니다.엑스터널 아이디는 워스 2.0 클라이언트 자격 증명 흐름을 사용합니다.서비스는 클라이언트 아이디와 비밀키를 사용하여 스스로 인증하고 토큰을 받아 다운스트림 API를 호출합니다.이 기능은 MEM 프리미엄 추가 기능이 필요함으로 비용이 발생하지만 API 간 통신을 보호해야 할 경우 내장되어 있어 편리합니다.이 세 가지 시나리오는 여러분이 접하게 될 거의 모든 외부 아이디 상황을 다룹니다.하지만 여러분이 내려야 할 중요한 결정이 하나 있는데 바로 그 사용자들이 실제로 어디에 거주하는가입니다.엑스터널 아이디는 업무용 테넌트와 외부 테넌트라는 매우 다른 두 곳에서 실행될 수 있기 때문입니다.두 가지 옵션을 자세히 살펴보겠습니다.엑스터널 아이디는 기존 업무용 테넌트 내부에서 실행되거나 완전히 분리된 외부 테넌트로 실행될 수 있습니다.두 방식은 동일하지 않으며 잘못 선택하면 추후 문제가 발생할 수 있습니다.업무용 테넌트 옵션부터 시작해보겠습니다.귀사의 회사는 이미 직원을 위한 엔트라 아이디 테넌트를 보유하고 있습니다.그것이 바로 여러분의 업무용 테넌트입니다.해당 테넌트 내에서 게스트 셀프 서비스 가입 기능을 활성화하면 외부 사용자가 가입하여 직원과 동일한 디렉터리에 포함될 수 있습니다.그들의 계정은 CEO의 계정 바로 옆에 위치하게 됩니다.셰어포인트 사이트에 소수의 파트너를 초대하는 것과 같은 간단한 비이비 시나리오에서는 같은 디렉터리에 혼합하는 것이 전혀 문제가 없습니다.설정이 간편하고 별도의 테넌트를 관리할 필요가 없기 때문입니다.

하지만 중요한 점이 있습니다.수천 명이 사용자를 대상으로 하는 앱을 구축하는 경우 고객을 직원과 동일한 디렉터리에 두고 싶지는 않을 것입니다.그것은 보완 위험이 될 수 있습니다.직원이 실수로 고객 데이터에 접근할 수 있기 때문입니다.직원을 위해 위도된 구성 변경이 고객 액세스에 영향을 줄 수 있습니다.또한 고객 로그인 페이지에 브랜딩이 회사용으로 설정한 내용과 강제로 연결될 것입니다.이는 바람직하지 않습니다.대안은 외부 테넌트 옵션입니다.고객 아이디만을 위해 완전히 격리된 새로운 디렉터리를 만드는 것입니다.이곳에는 직원이 상주하지 않습니다.완전히 분리된 독립 공간입니다.앞서 언급했던 사무실 빌딩 비율을 기억하시나요?업무용 테넌트는 회사의 본사 건물과 같습니다.외부 테넌트는 고객을 위해 여는 전용 매장입니다.그들만의 입구와 규칙 그리고 자체 보완을 갖추고 있습니다.어느 것도 뒤섞이이지 않습니다.그렇다면 외부 테넌트의 장점은 무엇일까요?첫째, 격리된 사용자 저장소를 제공합니다.고객 데이터는 직원 데이터와 완전히 분리되어 위험을 줄이고 규정 준수를 간소화합니다.둘째, 별도의 브랜딩이 가능합니다.기업 테넌트에 영향을 주지 않으면 서고객 전용 로그인 페이지의 디자인을 맞춤 설정할 수 있습니다.셋째, 모바일 앱용 네이티브 인증 API를 통해iOS나 안드로이드 앱 내에 완전히 사용자 지정된 로그인 화면을 구축할 수 있습니다.브라우저 리디렉션이나 불편한 웹뷰가 필요 없습니다.넷째, 월간 활성 사용자, MAU 기반의 요금제를 제공합니다.해당 월에 실제로 인증한 사용자에게만 비용을 지불하므로 고객 성장에 맞춰 자연스럽게 확장됩니다.그렇다면 언제 무엇을 선택해야 할까요?매우 간단합니다.수천명이 고객을 대상으로 하는 BEC 앱을 구축 중에 라면 외부 테넌트를 선택하세요.이것이 권장되는 방식이며 엑스터널 아이디가 설계된 목적이기도 합니다.

단순히 파트너를 초대하여 내부 리소스에 액세스하게 하려는 경우 라면 워크포스 테넌트 옵션으로 충분합니다.중요한 점은 구축을 시작하기 전에 차이를 이해하는 것입니다.나중에 하나에서 다른 것으로 마이그레이션 하는 것은 간단하지 않기 때문입니다.보안, MFA 및 조건부 액세스, 이제 보안에 대해 이야기해보겠습니다.고객이 앱에 접속하도록 허용하려면 권한 없는 사용자가 침입하지 못하도록 확실히 해야 합니다.엑스터널 아이디에는 엔트라 아이디가 직원용으로 제공하는 것과 동일한 엔터프라이즈급 보안 기능이 포함되어 있습니다.즉, 다단계 인증, 조건부 액세스, 위험기반 정책을 의미합니다.현재 MFA를 위해 두 가지 옵션을 사용할 수 있습니다.이메일 일회용 암호는 무료입니다.시스템이 사용자 이메일로 코드를 보내면 사용자가 입력하여 완료합니다. SMS 일회용 암호도 같은 방식으로 작동하지만 휴대폰으로 전송되며 통신사 비용이 발생합니다.한 가지 참고할 점은 아직 마이크로소프트 어센티케이터 지원이 되지 않는다는 것입니다.현재의 한계이며 마이크로소프트가 작업 중일 가능성이 높지만 당분간은 이메일이나 SMS만 가능합니다.조건부 액세스는 흥미로운 지점입니다.로그인 위험 수준이 중간 이상일 때 MFA를 요구하거나 사업을 하지 않는 국가에서의 액세스를 차단하는 등의 규칙을 정의할 수 있습니다.시스템은 실시간으로 각 로그인 시도를 평가합니다.누군가 의심스러운 위치나 장치에서 로그인을 시도하면 개발자가 직접 로직을 구축하지 않아도 자동으로 보안 요구사항을 강화할 수 있습니다.하지만 단연 돋보이는 기능은 바로 스텝업 인증입니다.작동 방식은 다음과 같습니다.사용자가 제품 카탈로그를 보기 위해 비밀번호만으로 앱에 로그인한다고 가정해보겠습니다.저위험 활동에는 적합하지만 결제 내역을 확인하거나 청구서를 다운로드하려고 할 때는 추가적인 인증이 필요합니다.

단계별 인증을 사용하면 앱의 특정 섹션에 대해서만 MFA를 요구할 수 있습니다.사용자는 민감한 정보에 접근하려고 할 때까지 인증 요구를 받지 않습니다.이 모든 과정은 엑스터널 아이디가 인증 컨텍스트라는 기능을 사용하여 백그라운드에서 처리합니다.앱의 어떤 부분에 추가 보안이 필요한지만 정의하면 나머지는 시스템이 알아서 처리합니다.사용자는 일반적인 탐색 시 원활한 경험을 누리면서 민감한 데이터는 안전하게 보호됩니다.브랜딩 및 사용자 경험브랜딩 제어는 조직이 자체 로그인 시스템을 구축하는 대신 엑스터널 아이디를 선택하는 가장 큰 이유 중 하나입니다.가입 및 로그인 페이지의 디자인을 완전히 제어할 수 있으며로고 업로드, 배경색 설정, 브라우저 템용 파비콘 추가, 개인정보처리 방침 및 서비스 약관 링크가 포함된 헤더와 푸터 사용자 지정이 가능합니다.더 많은 제어가 필요하다면 사용자 지정 CSS 파일을 업로드하여 폰트, 버튼 색상, 네이아웃을 제정해 할 수 있습니다.귀사의 브랜드와 색상, 모든 것을 직접 결정할 수 있습니다.이제 조금 까다로운 부분을 살펴보겠습니다. 브랜딩은 애플리케이션 단위가 아닌 페넌트 단위로 적용됩니다.따라서 고객 포털과 모바일 앱처럼 여러 앱을 운영하더라도 모두 동일한 브랜딩 페이지를 공유하게 됩니다.가견마다 고유한 디자인을 적용할 수는 없습니다.기존 에이저 ADBC는 애플리케이션 별 브랜딩을 지원했지만, 엑스터널 아이디는 아직 이를 지원하지 않습니다.또 다른 제한사항으로 로그인 페이지의 오류 메시지를 사용자 지정할 수 없습니다.존재하지 않는 이메일을 입력하면 해당 이메일 주소로 된 계정을 찾을 수 없습니다.와 같은 메시지가 표시됩니다. 그리고 이 텍스트는 변경할 수 없습니다.일부 조직에는 괜찮을 수 있지만, 규제 산업 분야에 있거나 엄격한 브랜드 어조를 유지해야 하는 조직에는 큰 문제입니다.

모바일 앱에는 더 나은 옵션이 있습니다.엑스터널 아이디는 iOS 및 안드로이드를 위한 네이티브 인증 API를 제공합니다.사용자를 브라우저 기반 로그인 페이지로 리디렉션하는 대신 앱 내부에 완전히 커스텀된 로그인 화면을 구축할 수 있습니다.브라우저 리디렉션이나 어색한 웹뷰가 필요 없습니다.사용자는 앱을 벗어나지 않으며 모든 픽셀을 직접 제어할 수 있습니다.훨씬 더 원활한 경험을 제공하며, 이는 에이저 ADBC에는 없었던 기능입니다.에이저 ADBC에서의 마이그레이션, 이미 에이저 ADBC를 사용 중이라면 이것이 어떤 의미인지 궁금하실 겁니다.핵심은 다음과 같습니다.마이크로소프트는 최소 2030년까지 BC를 계속 지원할 예정입니다.따라서 기존 테넌트가 당장 작동을 멈추지는 않겠지만, 새로운 기능은 더 이상 추가되지 않습니다.패스 키, 네이티브 인증, 사기 방지 등 모든 혁신적인 기능은 엑스터널 아이디에서만 제공됩니다.사실상 기능이 고정된 플랫폼을 사용하고 계신 셈입니다.마이크로소프트는 공식 마이그레이션 도구와 가이드를 공개했으며, 규모에 따라 두 가지 경로가 있습니다.디렉터리 개체, 사용자, 그룹, 사용자 지정 속성이 약 500만 개 미만인 페넌트의 경우 표준 마이그레이션은 비교적 간단합니다.페넌트 간 이동과 비슷한 방식으로 작동합니다.새로운 엑스터널 아이디 페넌트를 만들고, 사용자와 자격증명을 마이그레이션 한 다음 애플리케이션을 전환합니다.마이크로소프트는 대량 사용자 내보내기 및 가져오기 도구를 제공하며, 전환 중 중단을 최소화하기 위해 JIT, 저스트 인타임, 암호 마이그레이션을 사용할 수 있습니다. 500만 개 이상의 디렉터리 개체를 보유한 대규모 테넌트의 경우, 대규모 호환성 모드, HSC가 있습니다.이 모드에서는 네이저 AD BEC와 엑스터널 아이디가 동일한 테넌트 내에서 병렬로 실행됩니다.

기존 BEC 엔드포인트는 활성 상태로 유지되며, 애플리케이션을 점진적으로 이동할 수 있습니다.이는 수백만 명이 사용자를 하룻밤 사이에 마이그레이션 할 수 없는 조직을 위해 설계되었지만, 상충관계가 존재합니다.소셜 아이디 공급자나 패스키를 사용할 수 없고, 조건부 액세스가 제한되며 일부 기능은 제공되지 않습니다.연구적인 해결책이 아닌 가교 전략으로 생각하십시오.이제 중요한 변화를 말씀드리겠습니다.사용자 지정 정책이 사라졌습니다.에이저 AD BEC 위 XML 기반 아이디 경험 프레임워크를 사용하여 복잡한 인증 흐름을 구축했다면,엑스터널 아이디에서는 작동하지 않습니다.사용자 흐름과 사용자 지정 인증 확장을 사용하여 해당 로직을 다시 구축해야 합니다. XML을 새로운 형식으로 변환해주는 마법 같은 도구는 없습니다.직접 작업을 수행해야 합니다.결론적으로 핵심은 이렇습니다.오늘 새로 시작한다면 엑스터널 아이디를 사용하십시오. BEC를 고려할 이유는 전혀 없습니다.기존 BEC 테넌트가 있다면 지금 바로 마이그레이션 계획을 세우십시오. 2030년까지 시간이 있지만, 마지막 순간까지 기다리면 기존 앱을 유지하면서 복잡한 마이그레이션을 급하게 처리해야 할 것입니다.작게 시작하십시오.애플리케이션 하나를 선택하여 마이그레이션하고, 테스트하며, 그 과정에서 배운 뒤 나머지를 진행하십시오.개발자 경험과 자동화입니다.마이크로소프트는 개발자가 엑스터널 아이디를 쉽게 사용할 수 있도록 집중했으며,이는 이전 BEC 사용자 지정 정책에서 크게 바뀐 점입니다.수백 줄에 달하고, 괄호 하나만 잘못 넣어도 작동하지 않던 그 XML 파일들을 기억하시나요?이제 사라졌습니다.마이크로소프트 엔트라 엑스터널 아이디라는 비주얼 스튜디오 코드 확장 프로그램이 있습니다.인증 후에는 편집기를 떠나지 않고도 테넌트를 탐색하고, 사용자 흐름을 확인하고, JSON 파일로 다운로드하며, 브랜딩까지 미리 볼 수 있습니다.

로그인 페이지를 개시하기 전에 어떤 모습인지 확인할 수 있습니다.또한 마이크로소프트 그래프 API가 있습니다.사용자 흐름, 앱 등록, 브랜딩 등 거의 모든 엑스터널 아이디 리소스를 프로그래밍 방식으로 관리할 수 있습니다.즉, 파워셀이나 레스트 호출을 사용하여 CI, CD 파이프라인에서 테넌트 설정을 자동화할 수 있습니다.새 테넌트를 만들고, 사용자 흐름을 구성하고, 앱을 등록하고, 브랜딩을 설정하는 작업을 모두 스크립트로 처리하세요.여러 환경을 관리하는 경우, 이 방식은 엄청난 시간을 절약해줍니다.사용자 지정 인증 확장에 진정한 강력함이 숨어 있습니다.복잡한 XML 대신 네이저 펑션스에 대한 간단한 HTTP 호출로 인증 흐름을 확장할 수 있습니다.연동할 수 있는 4가지 이벤트가 있습니다.토큰 발급 시작 시 역할이나 충성도 등급 정보와 같은 사용자 지정 클레임을 토큰에 추가할 수 있습니다.속성 수집 시작 및 제출 시 자체 백엔드를 호출하여 가입 데이터를 검증하거나 미리 채울 수 있습니다.그리고 이메일 OTP 발송 시 인증 이메일을 사용자 지정할 수 있습니다. BEC가 가졌던 유연함 그대로 모든 개발자가 다룰 수 있는 모델로 제공됩니다.알아두어야 할 제한사항도 있습니다.아직 마이크로소프트 그래프 알림이 지원되지 않아 새 사용자가 가입할 때 워크플로우를 자동으로 트리거할 수 없습니다.일부 구성은 여전히 센터에서 수동으로 수행해야 하며 기본 제공되는 프로필 편집 페이지가 없습니다.사용자가 정보를 업데이트 하도록 하려면 앱에 해당 페이지를 직접 만들고 그래프 API를 호출해야 합니다.하지만 방향성은 명확합니다.마이크로소프트는 외부 아이디를 완전히 자동화할 수 있게 만들고자 합니다.그렇게 되면 대규모 관리도 훨씬 쉬워집니다.이제 마이크로소프트 엔트라 엑스터널 아이디가 엔트라 브랜드로 통합된 에이저 AD BEC위 현대적 대체제라는 사실을 알게 되셨을 겁니다.

고객 아이디, 파트너 협업, 기계 간 통신이라는 세 가지 사용 사례는 직면할 거의 모든 외부 아이디 요구사항을 포괄합니다.핵심 결정사항은 워크포스 테넌트를 사용할지 아니면 별도의 외부 테넌트를 만들지 여부입니다.고객 대면 앱의 경우 분리하는 것이 거의 항상 더 좋습니다.아이디는 애플리케이션의 현관 문과 같습니다.이를 올바르고 안전하며 브랜드화 되고 간단하게 구현하는 것은 사용자 신뢰와 비즈니스 성장에 직접적인 영향을 미칩니다.숙제로 엔트라 다데마이 CROSOFT.COM으로 이동하여 외부 테넌트를 만들고 시작 가이드를 시도해보세요.몇 분 안에 샘플 앱을 설정하는 방법을 안내해 줄 것입니다.마이크로소프트 아이디 플랫폼에 대한 더 쉬운 설명을 원하시면 구독해주세요.