WEBVTT

00:00:00.000 --> 00:00:03.300
사실 대부분의 사람들은 아이디가 단순히 사용자 이름과 비밀번호라고 생각합니다.

00:00:03.460 --> 00:00:05.580
입력하고 액세스 권한을 얻으면 끝이죠.

00:00:05.800 --> 00:00:09.240
하지만 고객을 상대하는 기업이라면 아이디는 훨씬 더 복잡해집니다.

00:00:09.420 --> 00:00:12.860
수천 명의 사람들이 앱에 가입하거나 또 다른 비밀번호를 만드는 대신

00:00:12.860 --> 00:00:15.480
구글 계정으로 로그인하게 하려면 어떻게 해야 할까요?

00:00:15.660 --> 00:00:20.020
그리고 직원 디렉터리와 섞이지 않게 모든 고객 데이터를 안전하게 유지하려면 어떻게 해야 할까요?

00:00:20.200 --> 00:00:23.520
그것이 바로 마이크로소프트 엔트라 엑스터널 아이디가 해결하고자 하는 문제입니다.

00:00:23.700 --> 00:00:24.460
핵심은이 겁니다.

00:00:24.800 --> 00:00:27.320
이 서비스가 에이저 ADBC를 완전히 대체합니다.

00:00:27.320 --> 00:00:30.540
이번 에피소드가 끝날 때 쯤이면 엑스터널 아이디가 정확히 무엇인지

00:00:30.540 --> 00:00:32.340
주요 활용방법 3가지는 무엇인지

00:00:32.340 --> 00:00:34.900
그리고 고객용 앱에 왜 중요한지 이해하게 될 것입니다.

00:00:35.100 --> 00:00:37.300
예전 방식은 별도의 아이디 사일로였습니다.

00:00:37.760 --> 00:00:40.960
20년 전으로 돌아가 고객용 앱을 만들었다고 상상해보세요.

00:00:41.260 --> 00:00:44.480
당시에는 직접 로그인 시스템을 구축하고 비밀번호 코드를 작성하고

00:00:44.480 --> 00:00:48.820
저장할 데이터베이스를 설정하고 비밀번호 찾기 흐름까지 모두 처음부터 만들어야 했습니다.

00:00:49.140 --> 00:00:51.240
사용자가 수백 명인 작은 앱에는 괜찮았지만

00:00:51.240 --> 00:00:54.020
앱이 성장함에 따라 상황은 빠르게 복잡해졌습니다.

00:00:54.020 --> 00:00:56.980
기업들은 사용자가 구글이나 페이스북으로 로그인하게 하고

00:00:56.980 --> 00:01:00.900
다단계 인증이 필요했으며 오류 없이 수백만 개의 계정을 처리해야 했습니다.

00:01:01.180 --> 00:01:03.660
그 모든 것을 직접 구축하는 것은 악몽이 되었습니다.

00:01:03.900 --> 00:01:06.580
마이크로소프트 위 첫 번째 답변은 에이저 ADBC였습니다.

00:01:06.880 --> 00:01:10.120
이는 고객 아이디 서비스였으며 당시에는 실질적인 문제를 해결해주었습니다.

00:01:10.340 --> 00:01:12.120
하지만 여기서부터 고통이 시작되었습니다.

00:01:12.360 --> 00:01:15.340
가장 큰 문제는 사용자 지정 정책, 커스텀 팔러시스 이라는 것이었고

00:01:15.340 --> 00:01:17.040
이 정책들은 XML로 작성되었습니다.

00:01:17.220 --> 00:01:19.460
수백 줄에 달하는 XML 파일을 다뤄본 적이 있다면

00:01:19.460 --> 00:01:21.520
그게 얼마나 고통스러운지 잘 아실 겁니다.

00:01:21.520 --> 00:01:23.420
설정도 어렵고 디버깅도 힘들며

00:01:23.420 --> 00:01:26.160
문제가 발생하면 원인을 알아내기가 매우 어려웠습니다.

00:01:26.160 --> 00:01:30.500
게다가 에이저 ADBC는 마이크로소프트 위 메인 아이디 플랫폼과 분리되어 있었습니다.

00:01:30.640 --> 00:01:34.640
따라서 이미 직원을 위해 마이크로소프트 365나 에이저 AD를 사용하고 있더라도

00:01:34.640 --> 00:01:37.740
BEC는 완전히 새로운 제품을 배우는 것처럼 느껴졌습니다.

00:01:37.920 --> 00:01:40.520
예상대로 IT팀은 유지관리에 어려움을 겪었고

00:01:40.520 --> 00:01:42.280
개발자는 작업을 기피했으며

00:01:42.280 --> 00:01:45.200
고객은 불편한 가입 경험 때문에 떠나고 싶어 했습니다.

00:01:45.540 --> 00:01:48.540
마이크로소프트는 더 간단하고 통합된 무언가가 필요하다는 것을 깨달았고

00:01:48.540 --> 00:01:51.380
그것이 바로 마이크로소프트 엔트라 엑스터널 아이디가 되었습니다.

00:01:51.580 --> 00:01:54.040
마이크로소프트 엔트라 엑스터널 아이디란 무엇인가?

00:01:54.040 --> 00:01:57.000
그렇다면 마이크로소프트 엔트라 엑스터널 아이디는 정확히 무엇일까요?

00:01:57.140 --> 00:01:58.680
가장 간단한 정의는 이렇습니다.

00:01:58.880 --> 00:02:03.100
직원이 아닌 외부 사용자, 고객, 파트너 및 게스트를 위한 클라우드 아이디 서비스입니다.

00:02:03.280 --> 00:02:04.160
이렇게 생각해보세요.

00:02:04.420 --> 00:02:06.300
여러분의 회사가 사무용 빌딩을 가지고 있다고 상상해보세요.

00:02:06.500 --> 00:02:08.740
그것이 바로 여러분의 워크포스 테넌트, 워크포스 터넌트입니다.

00:02:08.920 --> 00:02:11.580
직원들이 일하는 곳, 이자 책상이 있는 곳, 출입증으로 드나드는 바로 그 곳입니다.

00:02:11.740 --> 00:02:13.460
엔트라 아이디가 그 건물을 관리하죠.

00:02:13.680 --> 00:02:15.820
이제 고객을 위한 매장을 연다고 상상해보세요.

00:02:15.820 --> 00:02:19.440
별도의 공간에 자체 출입구와 규칙, 고유한 보안을 갖춘 곳 말입니다.

00:02:19.620 --> 00:02:23.880
고객이 직원 휴게실에 들어오지 않고, 직원이 실수로 고객 계정에 접근하지도 않습니다.

00:02:24.100 --> 00:02:25.760
그것이 바로 엑스터널 아이디입니다.

00:02:25.980 --> 00:02:29.120
마이크로소프트 엔트라 제품군에 속하지만 성격은 조금 다릅니다.

00:02:29.320 --> 00:02:35.160
고객 아이덴티티 및 액세스 관리, CIAM를 위해 구축되었으며 외부 사용자의 전체 수명 주기를 처리합니다.

00:02:35.360 --> 00:02:40.020
가입, 로그인, 암호 재설정, 프로필 관리, MFA, 토큰 발급까지 지원합니다.

00:02:40.020 --> 00:02:45.860
워스 2.0, 오픈 아이디 커넥트, SAML 같은 표준 프로토콜과 호환됨으로 거의 모든 앱을 연결할 수 있습니다.

00:02:46.060 --> 00:02:48.560
하지만 기존 에이저 ADBC와는 큰 차이가 있습니다.

00:02:48.820 --> 00:02:50.280
엑스터널 아이디는 더 간단합니다.

00:02:50.480 --> 00:02:52.520
더 이상 복잡한 사용자 지정 XML 정책은 필요 없습니다.

00:02:52.800 --> 00:02:55.380
대신 관리센터에서 직접 사용자 흐름을 구성하면 됩니다.

00:02:55.640 --> 00:02:59.200
또는 기존 백엔드 로직에 연결되는 사용자 지정 인증 확장을 사용할 수 있습니다.

00:02:59.480 --> 00:03:01.320
기능은 그대로 번거로움은 줄었습니다.

00:03:01.620 --> 00:03:03.180
세 가지 핵심 사용 사례를 살펴보겠습니다.

00:03:03.560 --> 00:03:05.660
그렇다면 엑스터널 아이디를 실제로 어떻게 사용할까요?

00:03:05.800 --> 00:03:07.160
세 가지 주요 시나리오가 있습니다.

00:03:07.160 --> 00:03:10.920
직원이 아닌 외부 사용자를 관리해야 하는 거의 모든 상황을 포괄합니다.

00:03:11.060 --> 00:03:14.580
가장 일반적인 고객 아이덴티티, 즉 BEC부터 시작해보죠.

00:03:14.720 --> 00:03:16.740
피자 주문 앱을 만든다고 상상해보세요.

00:03:17.120 --> 00:03:20.460
사람들이 가입하고 주문하며 다음 주에도 다시 찾게 해야 합니다.

00:03:20.680 --> 00:03:23.580
새로운 암호를 만들게 하는 대신 구글 계정으로 로그인하게 하고

00:03:23.580 --> 00:03:26.840
이름, 전화번호, 배달 선호사항 등을 수집해야 합니다.

00:03:27.040 --> 00:03:29.100
엑스터널 아이디 가입 모든 것을 처리합니다.

00:03:29.340 --> 00:03:31.500
미리 구축된 가입 및 로그인 흐름을 제공합니다.

00:03:31.780 --> 00:03:35.720
이름, 전화번호 등 필요한 속성을 선택하여 수집하도록 구성할 수 있습니다.

00:03:35.720 --> 00:03:39.620
구글, 페이스북, 애플을 통한 소셜 로그인을 설정하세요.

00:03:39.820 --> 00:03:45.580
사용자가 인증하면 엑스터널 아이디가 앱에 토큰을 발급하여 해당 사용자가 누구인지 알 수 있게 합니다.

00:03:45.820 --> 00:03:50.060
이것이 에이저 ADBC를 대체하며 대부분의 조직이 시작하는 지점입니다.

00:03:50.240 --> 00:03:53.300
또 다른 시나리오는 기업 간 협업, 즉 BEB입니다.

00:03:53.500 --> 00:03:57.820
파트너나 공급업체에게 내부 앱에 대한 액세스 권한을 제공해야 할 때 사용합니다.

00:03:58.040 --> 00:04:04.780
외부 물류 파트너가 확인해야 할 셔어포인트, 사이트나 프리랜서 디자이너가 사용하는 프로젝트 관리 도구가 있을 수 있죠.

00:04:04.780 --> 00:04:09.080
이 시나리오에서는 그들을 워크포스 테넌트의 게스트 사용자로 초대합니다.

00:04:09.320 --> 00:04:16.060
엑스터널 아이디는 초대 이메일, 초대 수락 절차, 그리고 볼 수 있는 범위를 제어하는 액세스 정책을 관리합니다.

00:04:16.280 --> 00:04:20.820
이 기능은 사실 에이저 ADNA-BEB 협업으로 이미 수년간 사용되어 왔습니다.

00:04:21.040 --> 00:04:25.720
하지만 이제는 엑스터널 아이디 위 일부가 되었으므로 고객 아이디와 동일한 곳에서 관리할 수 있습니다.

00:04:25.980 --> 00:04:28.220
다음은 기기 간 통신, 즉 MEM입니다.

00:04:28.220 --> 00:04:31.320
이는 최종 사용자에게 덜 드러나지만 똑같이 중요합니다.

00:04:31.440 --> 00:04:37.500
때로는 백엔드 서비스가 다른 API, 결제 프로세서, 데이터 분석 서비스 또는 내부 마이크로 서비스와 통신해야 합니다.

00:04:37.700 --> 00:04:41.280
사람이 관여하지 않고 한 애플리케이션이 다른 애플리케이션을 호출하는 방식입니다.

00:04:41.480 --> 00:04:44.960
엑스터널 아이디는 워스 2.0 클라이언트 자격 증명 흐름을 사용합니다.

00:04:45.200 --> 00:04:50.720
서비스는 클라이언트 아이디와 비밀키를 사용하여 스스로 인증하고 토큰을 받아 다운스트림 API를 호출합니다.

00:04:50.720 --> 00:04:57.580
이 기능은 MEM 프리미엄 추가 기능이 필요함으로 비용이 발생하지만 API 간 통신을 보호해야 할 경우 내장되어 있어 편리합니다.

00:04:57.760 --> 00:05:01.900
이 세 가지 시나리오는 여러분이 접하게 될 거의 모든 외부 아이디 상황을 다룹니다.

00:05:02.080 --> 00:05:06.300
하지만 여러분이 내려야 할 중요한 결정이 하나 있는데 바로 그 사용자들이 실제로 어디에 거주하는가입니다.

00:05:06.520 --> 00:05:10.900
엑스터널 아이디는 업무용 테넌트와 외부 테넌트라는 매우 다른 두 곳에서 실행될 수 있기 때문입니다.

00:05:11.080 --> 00:05:12.660
두 가지 옵션을 자세히 살펴보겠습니다.

00:05:13.080 --> 00:05:17.420
엑스터널 아이디는 기존 업무용 테넌트 내부에서 실행되거나 완전히 분리된 외부 테넌트로 실행될 수 있습니다.

00:05:17.420 --> 00:05:20.940
두 방식은 동일하지 않으며 잘못 선택하면 추후 문제가 발생할 수 있습니다.

00:05:21.120 --> 00:05:22.860
업무용 테넌트 옵션부터 시작해보겠습니다.

00:05:23.200 --> 00:05:26.000
귀사의 회사는 이미 직원을 위한 엔트라 아이디 테넌트를 보유하고 있습니다.

00:05:26.260 --> 00:05:28.080
그것이 바로 여러분의 업무용 테넌트입니다.

00:05:28.300 --> 00:05:34.620
해당 테넌트 내에서 게스트 셀프 서비스 가입 기능을 활성화하면 외부 사용자가 가입하여 직원과 동일한 디렉터리에 포함될 수 있습니다.

00:05:34.880 --> 00:05:37.500
그들의 계정은 CEO의 계정 바로 옆에 위치하게 됩니다.

00:05:37.780 --> 00:05:43.640
셰어포인트 사이트에 소수의 파트너를 초대하는 것과 같은 간단한 비이비 시나리오에서는 같은 디렉터리에 혼합하는 것이 전혀 문제가 없습니다.

00:05:43.640 --> 00:05:46.860
설정이 간편하고 별도의 테넌트를 관리할 필요가 없기 때문입니다.

00:05:47.020 --> 00:05:48.320
하지만 중요한 점이 있습니다.

00:05:48.580 --> 00:05:53.740
수천 명이 사용자를 대상으로 하는 앱을 구축하는 경우 고객을 직원과 동일한 디렉터리에 두고 싶지는 않을 것입니다.

00:05:53.960 --> 00:05:55.460
그것은 보완 위험이 될 수 있습니다.

00:05:55.740 --> 00:05:58.180
직원이 실수로 고객 데이터에 접근할 수 있기 때문입니다.

00:05:58.380 --> 00:06:01.480
직원을 위해 위도된 구성 변경이 고객 액세스에 영향을 줄 수 있습니다.

00:06:01.700 --> 00:06:05.500
또한 고객 로그인 페이지에 브랜딩이 회사용으로 설정한 내용과 강제로 연결될 것입니다.

00:06:05.700 --> 00:06:06.940
이는 바람직하지 않습니다.

00:06:07.180 --> 00:06:08.760
대안은 외부 테넌트 옵션입니다.

00:06:08.760 --> 00:06:12.140
고객 아이디만을 위해 완전히 격리된 새로운 디렉터리를 만드는 것입니다.

00:06:12.280 --> 00:06:13.780
이곳에는 직원이 상주하지 않습니다.

00:06:13.980 --> 00:06:15.360
완전히 분리된 독립 공간입니다.

00:06:15.540 --> 00:06:17.520
앞서 언급했던 사무실 빌딩 비율을 기억하시나요?

00:06:17.720 --> 00:06:19.780
업무용 테넌트는 회사의 본사 건물과 같습니다.

00:06:20.120 --> 00:06:22.740
외부 테넌트는 고객을 위해 여는 전용 매장입니다.

00:06:23.000 --> 00:06:26.100
그들만의 입구와 규칙 그리고 자체 보완을 갖추고 있습니다.

00:06:26.400 --> 00:06:27.880
어느 것도 뒤섞이이지 않습니다.

00:06:28.120 --> 00:06:30.220
그렇다면 외부 테넌트의 장점은 무엇일까요?

00:06:30.380 --> 00:06:32.800
첫째, 격리된 사용자 저장소를 제공합니다.

00:06:32.800 --> 00:06:37.500
고객 데이터는 직원 데이터와 완전히 분리되어 위험을 줄이고 규정 준수를 간소화합니다.

00:06:37.660 --> 00:06:39.840
둘째, 별도의 브랜딩이 가능합니다.

00:06:40.040 --> 00:06:45.160
기업 테넌트에 영향을 주지 않으면 서고객 전용 로그인 페이지의 디자인을 맞춤 설정할 수 있습니다.

00:06:45.420 --> 00:06:48.080
셋째, 모바일 앱용 네이티브 인증 API를 통해

00:06:48.080 --> 00:06:52.100
iOS나 안드로이드 앱 내에 완전히 사용자 지정된 로그인 화면을 구축할 수 있습니다.

00:06:52.320 --> 00:06:54.740
브라우저 리디렉션이나 불편한 웹뷰가 필요 없습니다.

00:06:55.080 --> 00:06:58.440
넷째, 월간 활성 사용자, MAU 기반의 요금제를 제공합니다.

00:06:58.440 --> 00:07:03.620
해당 월에 실제로 인증한 사용자에게만 비용을 지불하므로 고객 성장에 맞춰 자연스럽게 확장됩니다.

00:07:03.800 --> 00:07:05.660
그렇다면 언제 무엇을 선택해야 할까요?

00:07:05.840 --> 00:07:06.740
매우 간단합니다.

00:07:06.940 --> 00:07:10.580
수천명이 고객을 대상으로 하는 BEC 앱을 구축 중에 라면 외부 테넌트를 선택하세요.

00:07:10.820 --> 00:07:14.120
이것이 권장되는 방식이며 엑스터널 아이디가 설계된 목적이기도 합니다.

00:07:14.280 --> 00:07:18.680
단순히 파트너를 초대하여 내부 리소스에 액세스하게 하려는 경우 라면 워크포스 테넌트 옵션으로 충분합니다.

00:07:18.860 --> 00:07:21.440
중요한 점은 구축을 시작하기 전에 차이를 이해하는 것입니다.

00:07:21.680 --> 00:07:25.100
나중에 하나에서 다른 것으로 마이그레이션 하는 것은 간단하지 않기 때문입니다.

00:07:25.100 --> 00:07:29.500
보안, MFA 및 조건부 액세스, 이제 보안에 대해 이야기해보겠습니다.

00:07:29.820 --> 00:07:34.040
고객이 앱에 접속하도록 허용하려면 권한 없는 사용자가 침입하지 못하도록 확실히 해야 합니다.

00:07:34.260 --> 00:07:39.300
엑스터널 아이디에는 엔트라 아이디가 직원용으로 제공하는 것과 동일한 엔터프라이즈급 보안 기능이 포함되어 있습니다.

00:07:39.600 --> 00:07:43.580
즉, 다단계 인증, 조건부 액세스, 위험기반 정책을 의미합니다.

00:07:43.780 --> 00:07:46.420
현재 MFA를 위해 두 가지 옵션을 사용할 수 있습니다.

00:07:46.680 --> 00:07:48.220
이메일 일회용 암호는 무료입니다.

00:07:48.460 --> 00:07:51.680
시스템이 사용자 이메일로 코드를 보내면 사용자가 입력하여 완료합니다.

00:07:51.680 --> 00:07:56.000
SMS 일회용 암호도 같은 방식으로 작동하지만 휴대폰으로 전송되며 통신사 비용이 발생합니다.

00:07:56.160 --> 00:07:59.460
한 가지 참고할 점은 아직 마이크로소프트 어센티케이터 지원이 되지 않는다는 것입니다.

00:07:59.620 --> 00:08:04.680
현재의 한계이며 마이크로소프트가 작업 중일 가능성이 높지만 당분간은 이메일이나 SMS만 가능합니다.

00:08:04.840 --> 00:08:06.840
조건부 액세스는 흥미로운 지점입니다.

00:08:07.120 --> 00:08:14.600
로그인 위험 수준이 중간 이상일 때 MFA를 요구하거나 사업을 하지 않는 국가에서의 액세스를 차단하는 등의 규칙을 정의할 수 있습니다.

00:08:14.600 --> 00:08:17.880
시스템은 실시간으로 각 로그인 시도를 평가합니다.

00:08:18.100 --> 00:08:26.780
누군가 의심스러운 위치나 장치에서 로그인을 시도하면 개발자가 직접 로직을 구축하지 않아도 자동으로 보안 요구사항을 강화할 수 있습니다.

00:08:27.040 --> 00:08:29.840
하지만 단연 돋보이는 기능은 바로 스텝업 인증입니다.

00:08:30.080 --> 00:08:31.400
작동 방식은 다음과 같습니다.

00:08:31.740 --> 00:08:35.520
사용자가 제품 카탈로그를 보기 위해 비밀번호만으로 앱에 로그인한다고 가정해보겠습니다.

00:08:35.920 --> 00:08:41.980
저위험 활동에는 적합하지만 결제 내역을 확인하거나 청구서를 다운로드하려고 할 때는 추가적인 인증이 필요합니다.

00:08:41.980 --> 00:08:46.340
단계별 인증을 사용하면 앱의 특정 섹션에 대해서만 MFA를 요구할 수 있습니다.

00:08:46.580 --> 00:08:49.960
사용자는 민감한 정보에 접근하려고 할 때까지 인증 요구를 받지 않습니다.

00:08:50.160 --> 00:08:55.060
이 모든 과정은 엑스터널 아이디가 인증 컨텍스트라는 기능을 사용하여 백그라운드에서 처리합니다.

00:08:55.260 --> 00:08:59.600
앱의 어떤 부분에 추가 보안이 필요한지만 정의하면 나머지는 시스템이 알아서 처리합니다.

00:08:59.840 --> 00:09:04.740
사용자는 일반적인 탐색 시 원활한 경험을 누리면서 민감한 데이터는 안전하게 보호됩니다.

00:09:04.960 --> 00:09:06.420
브랜딩 및 사용자 경험

00:09:06.420 --> 00:09:12.560
브랜딩 제어는 조직이 자체 로그인 시스템을 구축하는 대신 엑스터널 아이디를 선택하는 가장 큰 이유 중 하나입니다.

00:09:12.760 --> 00:09:15.340
가입 및 로그인 페이지의 디자인을 완전히 제어할 수 있으며

00:09:15.340 --> 00:09:23.460
로고 업로드, 배경색 설정, 브라우저 템용 파비콘 추가, 개인정보처리 방침 및 서비스 약관 링크가 포함된 헤더와 푸터 사용자 지정이 가능합니다.

00:09:23.620 --> 00:09:28.780
더 많은 제어가 필요하다면 사용자 지정 CSS 파일을 업로드하여 폰트, 버튼 색상, 네이아웃을 제정해 할 수 있습니다.

00:09:28.940 --> 00:09:31.620
귀사의 브랜드와 색상, 모든 것을 직접 결정할 수 있습니다.

00:09:31.620 --> 00:09:36.680
이제 조금 까다로운 부분을 살펴보겠습니다. 브랜딩은 애플리케이션 단위가 아닌 페넌트 단위로 적용됩니다.

00:09:36.840 --> 00:09:41.560
따라서 고객 포털과 모바일 앱처럼 여러 앱을 운영하더라도 모두 동일한 브랜딩 페이지를 공유하게 됩니다.

00:09:41.780 --> 00:09:43.920
가견마다 고유한 디자인을 적용할 수는 없습니다.

00:09:44.220 --> 00:09:49.260
기존 에이저 ADBC는 애플리케이션 별 브랜딩을 지원했지만, 엑스터널 아이디는 아직 이를 지원하지 않습니다.

00:09:49.440 --> 00:09:52.840
또 다른 제한사항으로 로그인 페이지의 오류 메시지를 사용자 지정할 수 없습니다.

00:09:53.120 --> 00:09:56.380
존재하지 않는 이메일을 입력하면 해당 이메일 주소로 된 계정을 찾을 수 없습니다.

00:09:56.380 --> 00:09:59.760
와 같은 메시지가 표시됩니다. 그리고 이 텍스트는 변경할 수 없습니다.

00:10:00.080 --> 00:10:06.140
일부 조직에는 괜찮을 수 있지만, 규제 산업 분야에 있거나 엄격한 브랜드 어조를 유지해야 하는 조직에는 큰 문제입니다.

00:10:06.340 --> 00:10:08.060
모바일 앱에는 더 나은 옵션이 있습니다.

00:10:08.400 --> 00:10:12.100
엑스터널 아이디는 iOS 및 안드로이드를 위한 네이티브 인증 API를 제공합니다.

00:10:12.320 --> 00:10:17.660
사용자를 브라우저 기반 로그인 페이지로 리디렉션하는 대신 앱 내부에 완전히 커스텀된 로그인 화면을 구축할 수 있습니다.

00:10:17.880 --> 00:10:20.260
브라우저 리디렉션이나 어색한 웹뷰가 필요 없습니다.

00:10:20.640 --> 00:10:23.800
사용자는 앱을 벗어나지 않으며 모든 픽셀을 직접 제어할 수 있습니다.

00:10:23.800 --> 00:10:28.400
훨씬 더 원활한 경험을 제공하며, 이는 에이저 ADBC에는 없었던 기능입니다.

00:10:28.540 --> 00:10:34.540
에이저 ADBC에서의 마이그레이션, 이미 에이저 ADBC를 사용 중이라면 이것이 어떤 의미인지 궁금하실 겁니다.

00:10:34.780 --> 00:10:35.760
핵심은 다음과 같습니다.

00:10:36.100 --> 00:10:39.080
마이크로소프트는 최소 2030년까지 BC를 계속 지원할 예정입니다.

00:10:39.240 --> 00:10:43.100
따라서 기존 테넌트가 당장 작동을 멈추지는 않겠지만, 새로운 기능은 더 이상 추가되지 않습니다.

00:10:43.260 --> 00:10:48.100
패스 키, 네이티브 인증, 사기 방지 등 모든 혁신적인 기능은 엑스터널 아이디에서만 제공됩니다.

00:10:48.320 --> 00:10:50.840
사실상 기능이 고정된 플랫폼을 사용하고 계신 셈입니다.

00:10:50.840 --> 00:10:55.720
마이크로소프트는 공식 마이그레이션 도구와 가이드를 공개했으며, 규모에 따라 두 가지 경로가 있습니다.

00:10:55.920 --> 00:11:02.720
디렉터리 개체, 사용자, 그룹, 사용자 지정 속성이 약 500만 개 미만인 페넌트의 경우 표준 마이그레이션은 비교적 간단합니다.

00:11:02.900 --> 00:11:05.280
페넌트 간 이동과 비슷한 방식으로 작동합니다.

00:11:05.520 --> 00:11:10.940
새로운 엑스터널 아이디 페넌트를 만들고, 사용자와 자격증명을 마이그레이션 한 다음 애플리케이션을 전환합니다.

00:11:10.940 --> 00:11:18.640
마이크로소프트는 대량 사용자 내보내기 및 가져오기 도구를 제공하며, 전환 중 중단을 최소화하기 위해 JIT, 저스트 인타임, 암호 마이그레이션을 사용할 수 있습니다.

00:11:18.820 --> 00:11:23.960
500만 개 이상의 디렉터리 개체를 보유한 대규모 테넌트의 경우, 대규모 호환성 모드, HSC가 있습니다.

00:11:24.240 --> 00:11:29.040
이 모드에서는 네이저 AD BEC와 엑스터널 아이디가 동일한 테넌트 내에서 병렬로 실행됩니다.

00:11:29.040 --> 00:11:33.800
기존 BEC 엔드포인트는 활성 상태로 유지되며, 애플리케이션을 점진적으로 이동할 수 있습니다.

00:11:34.000 --> 00:11:39.220
이는 수백만 명이 사용자를 하룻밤 사이에 마이그레이션 할 수 없는 조직을 위해 설계되었지만, 상충관계가 존재합니다.

00:11:39.420 --> 00:11:44.360
소셜 아이디 공급자나 패스키를 사용할 수 없고, 조건부 액세스가 제한되며 일부 기능은 제공되지 않습니다.

00:11:44.540 --> 00:11:46.980
연구적인 해결책이 아닌 가교 전략으로 생각하십시오.

00:11:47.120 --> 00:11:48.640
이제 중요한 변화를 말씀드리겠습니다.

00:11:48.940 --> 00:11:50.540
사용자 지정 정책이 사라졌습니다.

00:11:50.760 --> 00:11:55.120
에이저 AD BEC 위 XML 기반 아이디 경험 프레임워크를 사용하여 복잡한 인증 흐름을 구축했다면,

00:11:55.120 --> 00:11:57.160
엑스터널 아이디에서는 작동하지 않습니다.

00:11:57.320 --> 00:12:01.180
사용자 흐름과 사용자 지정 인증 확장을 사용하여 해당 로직을 다시 구축해야 합니다.

00:12:01.400 --> 00:12:04.220
XML을 새로운 형식으로 변환해주는 마법 같은 도구는 없습니다.

00:12:04.560 --> 00:12:05.940
직접 작업을 수행해야 합니다.

00:12:06.160 --> 00:12:07.500
결론적으로 핵심은 이렇습니다.

00:12:07.800 --> 00:12:10.220
오늘 새로 시작한다면 엑스터널 아이디를 사용하십시오.

00:12:10.340 --> 00:12:12.000
BEC를 고려할 이유는 전혀 없습니다.

00:12:12.360 --> 00:12:15.680
기존 BEC 테넌트가 있다면 지금 바로 마이그레이션 계획을 세우십시오.

00:12:15.920 --> 00:12:22.280
2030년까지 시간이 있지만, 마지막 순간까지 기다리면 기존 앱을 유지하면서 복잡한 마이그레이션을 급하게 처리해야 할 것입니다.

00:12:22.460 --> 00:12:23.540
작게 시작하십시오.

00:12:23.540 --> 00:12:28.200
애플리케이션 하나를 선택하여 마이그레이션하고, 테스트하며, 그 과정에서 배운 뒤 나머지를 진행하십시오.

00:12:28.280 --> 00:12:29.900
개발자 경험과 자동화입니다.

00:12:30.160 --> 00:12:33.860
마이크로소프트는 개발자가 엑스터널 아이디를 쉽게 사용할 수 있도록 집중했으며,

00:12:34.240 --> 00:12:36.820
이는 이전 BEC 사용자 지정 정책에서 크게 바뀐 점입니다.

00:12:37.000 --> 00:12:41.240
수백 줄에 달하고, 괄호 하나만 잘못 넣어도 작동하지 않던 그 XML 파일들을 기억하시나요?

00:12:41.480 --> 00:12:42.380
이제 사라졌습니다.

00:12:42.600 --> 00:12:46.380
마이크로소프트 엔트라 엑스터널 아이디라는 비주얼 스튜디오 코드 확장 프로그램이 있습니다.

00:12:46.380 --> 00:12:53.960
인증 후에는 편집기를 떠나지 않고도 테넌트를 탐색하고, 사용자 흐름을 확인하고, JSON 파일로 다운로드하며, 브랜딩까지 미리 볼 수 있습니다.

00:12:54.180 --> 00:12:57.160
로그인 페이지를 개시하기 전에 어떤 모습인지 확인할 수 있습니다.

00:12:57.400 --> 00:12:59.740
또한 마이크로소프트 그래프 API가 있습니다.

00:13:00.080 --> 00:13:05.180
사용자 흐름, 앱 등록, 브랜딩 등 거의 모든 엑스터널 아이디 리소스를 프로그래밍 방식으로 관리할 수 있습니다.

00:13:05.180 --> 00:13:10.220
즉, 파워셀이나 레스트 호출을 사용하여 CI, CD 파이프라인에서 테넌트 설정을 자동화할 수 있습니다.

00:13:10.380 --> 00:13:15.420
새 테넌트를 만들고, 사용자 흐름을 구성하고, 앱을 등록하고, 브랜딩을 설정하는 작업을 모두 스크립트로 처리하세요.

00:13:15.600 --> 00:13:18.640
여러 환경을 관리하는 경우, 이 방식은 엄청난 시간을 절약해줍니다.

00:13:18.820 --> 00:13:21.460
사용자 지정 인증 확장에 진정한 강력함이 숨어 있습니다.

00:13:21.740 --> 00:13:26.400
복잡한 XML 대신 네이저 펑션스에 대한 간단한 HTTP 호출로 인증 흐름을 확장할 수 있습니다.

00:13:26.600 --> 00:13:28.520
연동할 수 있는 4가지 이벤트가 있습니다.

00:13:28.520 --> 00:13:34.020
토큰 발급 시작 시 역할이나 충성도 등급 정보와 같은 사용자 지정 클레임을 토큰에 추가할 수 있습니다.

00:13:34.240 --> 00:13:39.620
속성 수집 시작 및 제출 시 자체 백엔드를 호출하여 가입 데이터를 검증하거나 미리 채울 수 있습니다.

00:13:39.860 --> 00:13:43.200
그리고 이메일 OTP 발송 시 인증 이메일을 사용자 지정할 수 있습니다.

00:13:43.440 --> 00:13:46.980
BEC가 가졌던 유연함 그대로 모든 개발자가 다룰 수 있는 모델로 제공됩니다.

00:13:47.180 --> 00:13:48.720
알아두어야 할 제한사항도 있습니다.

00:13:49.040 --> 00:13:53.960
아직 마이크로소프트 그래프 알림이 지원되지 않아 새 사용자가 가입할 때 워크플로우를 자동으로 트리거할 수 없습니다.

00:13:53.960 --> 00:13:58.740
일부 구성은 여전히 센터에서 수동으로 수행해야 하며 기본 제공되는 프로필 편집 페이지가 없습니다.

00:13:59.060 --> 00:14:03.860
사용자가 정보를 업데이트 하도록 하려면 앱에 해당 페이지를 직접 만들고 그래프 API를 호출해야 합니다.

00:14:04.060 --> 00:14:05.460
하지만 방향성은 명확합니다.

00:14:05.820 --> 00:14:08.680
마이크로소프트는 외부 아이디를 완전히 자동화할 수 있게 만들고자 합니다.

00:14:08.900 --> 00:14:11.060
그렇게 되면 대규모 관리도 훨씬 쉬워집니다.

00:14:11.240 --> 00:14:18.140
이제 마이크로소프트 엔트라 엑스터널 아이디가 엔트라 브랜드로 통합된 에이저 AD BEC위 현대적 대체제라는 사실을 알게 되셨을 겁니다.

00:14:18.140 --> 00:14:25.380
고객 아이디, 파트너 협업, 기계 간 통신이라는 세 가지 사용 사례는 직면할 거의 모든 외부 아이디 요구사항을 포괄합니다.

00:14:25.580 --> 00:14:30.280
핵심 결정사항은 워크포스 테넌트를 사용할지 아니면 별도의 외부 테넌트를 만들지 여부입니다.

00:14:30.480 --> 00:14:33.500
고객 대면 앱의 경우 분리하는 것이 거의 항상 더 좋습니다.

00:14:33.740 --> 00:14:35.780
아이디는 애플리케이션의 현관 문과 같습니다.

00:14:36.120 --> 00:14:42.160
이를 올바르고 안전하며 브랜드화 되고 간단하게 구현하는 것은 사용자 신뢰와 비즈니스 성장에 직접적인 영향을 미칩니다.

00:14:42.160 --> 00:14:48.060
숙제로 엔트라 다데마이 CROSOFT.COM으로 이동하여 외부 테넌트를 만들고 시작 가이드를 시도해보세요.

00:14:48.300 --> 00:14:51.240
몇 분 안에 샘플 앱을 설정하는 방법을 안내해 줄 것입니다.

00:14:51.500 --> 00:14:55.220
마이크로소프트 아이디 플랫폼에 대한 더 쉬운 설명을 원하시면 구독해주세요.