Właściwie większość ludzi uważa, że tożsamość to tylko nazwa użytkownika i hasło. Wpisujesz je, uzyskujesz dostęp i gotowe. Jednak dla firmy obsługującej klientów kwestia tożsamości staje się znacznie bardziej skomplikowana. Co się dzieje, gdy Twoja aplikacja musi umożliwić rejestrację tysiącom osób lub logowanie przez konto Google zamiast tworzenia kolejnego hasła? I jak zapewnić bezpieczeństwo danych klientów, nie mieszając ich z bazą pracowników? To właśnie problem, który ma rozwiązać Microsoft Entra External ID. Oto w czym rzecz. Całkowicie zastępuje on Azure AdB2C. Pod koniec tego odcinka zrozumiesz, czym właściwie jest External ID, poznasz trzy główne sposoby jego użycia i dlaczego ma znaczenie dla każdej aplikacji klienckiej. Stare podejście, oddzielne silosy tożsamości. Wyobraź sobie, że jest 20 lat temu i stworzyłeś aplikację dla klientów. W tamtych czasach budowało się własny system logowania, pisało kod haseł, konfigurowało bazę danych do ich przechowywania i tworzyło ścieżkę odzyskiwania hasła wszystko od podstaw.

Działało to dobrze w małej aplikacji z kilkuset użytkownikami, ale wraz z rozwojem aplikacji sprawy szybko się komplikowały. Firmy musiały umożliwić logowanie przez Google lub Facebooka, potrzebowały uwierzytelniania wieloskładnikowego i musiały obsługiwać miliony kont bez awarii. Budowanie tego wszystkiego na własną rękę stało się koszmarem. Pierwszą odpowiedzią Microsoftu był Azure AdB2C. Była to usługa tożsamości klienta, która w tamtym czasie rozwiązywała realny problem. Ale tutaj zaczęły się schody. Największym problemem były tak zwane zasady niestandardowe, które pisano w formacie XML. Jeśli kiedykolwiek pracowałeś z plikami XML liczącymi setki linii, wiesz dokładnie, jak to jest uciążliwe. Trudne w konfiguracji, trudne w debakowaniu, a gdy coś się zepsuło, powodzenia w szukaniu przyczyny. Co więcej, Azure AdB2C było oddzielone od głównej platformy tożsamości Microsoftu. Więc jeśli miałeś już Microsoft 365 lub Azure Ad dla pracowników, B2C było jak nauka zupełnie nowego produktu.

Zgodnie z przewidywaniami, zespoły IT zmagały się z utrzymaniem. Programiści bali się z tym pracować, a klienci kończyli z niezdarnym procesem rejestracji, który zniechęcał ich do korzystania z usług. Microsoft zrozumiał, że potrzebuje czegoś prostszego i bardziej ujednoliconego i właśnie tym stał się Microsoft Entra External ID. Czym właściwie jest Microsoft Entra External ID? Czym więc dokładnie jest Microsoft Entra External ID? Oto najprostsza definicja. To chmurowa usługa tożsamości dla użytkowników zewnętrznych, klientów, partnerów i gości, a nie dla pracowników. Pomyśl o tym w ten sposób. Wyobraź sobie, że Twoja firma ma biurowiec. To jest Twój tenant dla pracowników. To miejsce, w którym pracują Twoi pracownicy, gdzie znajdują się ich biurka i gdzie wchodzą za pomocą identyfikatorów. Entra ID zarządza tym budynkiem. Wyobraź sobie teraz, że otwierasz sklep dla klientów oddzielną przestrzeń z własnym wejściem, własnymi zasadami i własnym zabezpieczeniem.

Klienci nie błąkają się po pokoju socjalnym pracowników, a pracownicy nie uzyskują przypadkiem dostępu do kont klientów. To właśnie External ID. Jest częścią rodziny Microsoft Entra, ale w innym wydaniu. Zostało stworzone do C i AM, czyli zarządzania tożsamością i dostępem klientów i obsługuje pełny cykl życia użytkownika zewnętrznego. Rejestracja, logowanie, resetowanie hasła, zarządzanie profilem, MFA, wydawanie tokenów. Działa ze standardowymi protokołami, takimi jak OAuth 2.0, OpenID Connect i SAML, więc niemal każda tworzona aplikacja może się z nim połączyć. Oto jednak wielka różnica względem starego Azure ad B2C. External ID jest prostsze. Koniec z niestandardowymi zasadami XML. Zamiast tego konfigurujesz przepływy użytkowników bezpośrednio w centrum administracyjnym. Możesz też użyć niestandardowych rozszerzeń uwierzytelniania, które łączą się z twoją istniejącą logiką zaplecza. Ta sama moc, mniej kłopotów, trzy główne przypadki użycia.

Jak więc faktycznie korzystać z External ID? Istnieją trzy główne scenariusze. Obejmują one niemal każdą sytuację, w której musisz zarządzać kimś, kto nie jest pracownikiem. Zacznijmy od najczęstszego tożsamości klienta, czyli B2C. Wyobraź sobie, że tworzysz aplikację do zamawiania pizzy. Potrzebujesz, aby ludzie się rejestrowali, składali zamówienia i wracali w przyszłym tygodniu. Chcesz, aby logowali się za pomocą swojego konta Google, zamiast tworzyć kolejne hasło i musisz zebrać ich imię, numer telefonu oraz preferencje dostawy. External ID obsługuje to wszystko. Otrzymujesz gotowe przepływy rejestracji i logowania. Konfigurujesz, jakie atrybuty chcesz zbierać imię, telefon, cokolwiek potrzebujesz. Ustawiasz logowanie społecznościowe za pomocą Google, Facebooka lub Apple. A gdy użytkownik się uwierzytelni, External ID wydaje token Twojej aplikacji, aby wiedziała, kim jest ta osoba. To zamiennik dla Azure Ad B2C i punkt wyjścia dla większości organizacji.

Innym scenariuszem jest współpraca między firmami, czyli B2B. Dzieje się tak, gdy musisz zapewnić partnerom lub dostawcom dostęp do swoich wewnętrznych aplikacji. Może masz witrynę SharePoint, którą musi widzieć Twój zewnętrzny partner logistyczny lub narzędzie do zarządzania projektami, z którego korzystają niezależni projektanci. W tym scenariuszu zapraszasz ich jako użytkowników gości w swoim dzierżawcy pracowniczym. External ID obsługuje wiadomość e-mail z zaproszeniem proces realizacji, w którym akceptują zaproszenie oraz zasady dostępu kontrolujące to, co mogą zobaczyć. Funkcja ta istnieje od lat jako współpraca B2B wewnątrz Azure Adiunkt. Ale teraz jest to część parasola External ID, więc zarządzasz tym z tego samego miejsca, co tożsamościami swoich klientów. Potem mamy komunikację typu maszyna-maszyna, czyli M2M. Jest ona mniej widoczna dla użytkowników końcowych, ale równie ważna.

Czasami Twoja usługa zaplecza musi komunikować się z innym API, procesorem płatności, usługą analityki danych lub wewnętrznym mikroserwisem. Nie bierze w tym udziału człowiek, to po prostu jedna aplikacja wywołuje drugą. External ID wykorzystuje przepływ poświadczeń klienta OAuth 2.0. Twoja usługa uwierzytelnia się za pomocą identyfikatora klienta i klucza tajnego, a następnie otrzymuje token do wywołania podrzędnego API. Wymaga to dodatku M2M Premium, więc wiąże się z kosztem, ale jeśli musisz zabezpieczyć komunikację API, API rozwiązanie jest już wbudowane. Te trzy scenariusze obejmują niemal każdą sytuację dotyczącą tożsamości zewnętrznej, z jaką się zetkniesz. Musisz jednak podjąć ważną decyzję, gdzie Ci użytkownicy będą faktycznie przechowywani, ponieważ External ID może działać w dwóch bardzo różnych miejscach, dzierżawie pracowniczej lub zewnętrznej. Przeanalizujmy obie te opcje. External ID może działać wewnątrz Twojej istniejącej dzierżawy pracowniczej lub jako całkowicie oddzielna dzierżawa zewnętrzna.

Nie są to te same rzeczy, a wybór niewłaściwej może spowodować problemy w przyszłości. Zacznijmy od opcji dzierżawy pracowniczej. Twoja firma posiada już dzierżawę Entra ID dla pracowników. To jest Twoja dzierżawa pracownicza. Jeśli włączysz funkcję samodzielnej rejestracji gości w tej dzierżawie, użytkownicy zewnętrzni mogą się zarejestrować i trafić do tego samego katalogu, co Twoi pracownicy. Ich konta znajdą się tuż obok konta Twojego prezesa. W prostszych scenariuszach B2B, takich jak zapraszanie kilku partnerów do witryny SharePoint, mieszanie ich w tym samym katalogu jest jak najbardziej w porządku. Jest to proste w konfiguracji i nie musisz zarządzać oddzielną dzierżawą. Ale jest pewien haczyk. Jeśli tworzysz aplikację dla tysięcy klientów, nie chcesz, aby żyli oni w tym samym katalogu, co Twoi pracownicy. Stanowi to ryzyko dla bezpieczeństwa. Pracownik mógłby przypadkowo natknąć się na dane klientów.

Zmiana konfiguracji przeznaczona dla pracowników mogłaby wpłynąć na dostęp klientów, a branding stron logowania dla klientów byłby powiązany z tym, co ustawiłeś dla swojej firmy. To nie jest idealne rozwiązanie. Alternatywą jest opcja dzierżawy zewnętrznej. Tworzysz zupełnie nowy, odizolowany katalog specjalnie dla tożsamości klientów. Żadni pracownicy tu nie mieszkają. To całkowicie oddzielna przestrzeń. Pamiętasz wcześniejszą analogię do budynku biurowego? Dzierżawa pracownicza to Twoja siedziba korporacyjna. Dzierżawa zewnętrzna to dedykowany sklep, który otwierasz dla swoich klientów. Mają własne wejście, własne zasady i własne zabezpieczenia. Nic się nie miesza. Jakie są więc korzyści z posiadania dzierżawy zewnętrznej? Po pierwsze, otrzymujesz odizolowany magazyn użytkowników. Dane klientów pozostają całkowicie oddzielone od danych pracowników, co ogranicza ryzyko i upraszcza zgodność z przepisami.

Po drugie, otrzymujesz oddzielny branding. Możesz dostosować wygląd stron logowania specjalnie dla swoich klientów, nie wpływając przy tym na swojego tenanta korporacyjnego. Po trzecie, otrzymujesz natywne API uwierzytelniania dla aplikacji mobilnych, które pozwala budować w pełni niestandardowe ekrany logowania w aplikacjach iOS lub Android, bez przekierowań do przeglądarki i nieporęcznych widoków internetowych. Po czwarte, otrzymujesz model cenowy oparty na mału, czyli miesięcznej liczbie aktywnych użytkowników. Płacisz tylko za użytkowników, którzy faktycznie uwierzytelniają się w danym miesiącu, co naturalnie skaluje się wraz ze wzrostem liczby klientów. Kiedy więc wybrać, którą opcję? To całkiem proste. Jeśli tworzysz aplikację B2C dla tysięcy klientów, wybierz zewnętrznego tenanta. Jest to zalecane podejście i właśnie do tego zostało zaprojektowane external ID. Jeśli tylko zapraszasz partnerów do uzyskania dostępu do zasobów wewnętrznych, opcja tenanta dla pracowników jest w porządku.

Kluczem jest zrozumienie różnicy przed rozpoczęciem prac, ponieważ późniejsza migracja z jednego na drugiego nie jest prosta. Teraz porozmawiajmy o bezpieczeństwie. Jeśli zamierzasz wpuścić klientów do swojej aplikacji, musisz upewnić się, że nie dostaną się do niej osoby niepowołane. External ID obejmuje te same funkcje bezpieczeństwa klasy korporacyjnej, które EntraID oferuje pracownikom. Oznacza to uwierzytelnianie wieloskładnikowe, dostęp warunkowy i zasady oparte na ryzyku. W kwestii MFA masz obecnie dwie opcje. Jednorazowy kod dostępu przesyłany e-mailem jest bezpłatny. System wysyła kod na adres e-mail użytkownika, ten go wpisuje i gotowe. Jednorazowy kod SMS działa w ten sam sposób, ale trafia na telefon i wiąże się z kosztami operatora. Warto zauważyć, że nie ma jeszcze wsparcia dla Microsoft Authenticator. To obecne ograniczenie, nad którym Microsoft prawdopodobnie pracuje, ale na razie pozostaje e-mail lub SMS.

Dostęp warunkowy to miejsce, w którym sprawy stają się interesujące. Możesz definiować reguły, np. wymagające MFA przy logowaniu o średnim lub wyższym ryzyku albo blokujące dostęp z krajów, w których nie prowadzisz działalności. System ocenia każdą próbę logowania w czasie rzeczywistym. Jeśli ktoś próbuje się zalogować z podejrzanej lokalizacji lub urządzenia, system może automatycznie podnieść wymagania bezpieczeństwa bez konieczności tworzenia tej logiki samodzielnie. Istnieje jednak jedna funkcja, która naprawdę się wyróżnia – uwierzytelnianie stopniowe. Oto jak to działa. Wyobraź sobie, że użytkownik loguje się do aplikacji tylko za pomocą hasła, aby przeglądać katalog produktów. Jest to wystarczające dla działań o niskim ryzyku, ale gdy użytkownik chce przejrzeć historię płatności lub pobrać fakturę, wymagana jest dodatkowa weryfikacja. Dzięki uwierzytelnianiu krokowemu możesz wymagać MFA tylko w określonych sekcjach aplikacji.

Użytkownik nie otrzymuje monitu, dopóki nie spróbuje uzyskać dostępu do czegoś wrażliwego. Wszystkim zarządza External ID w tle przy użyciu tzw. kontekstu uwierzytelniania. Definiujesz, które części aplikacji wymagają dodatkowych zabezpieczeń, a resztą zajmuje się system. Użytkownik cieszy się płynnością podczas przeglądania, a dane wrażliwe pozostają chronione. Branding i wrażenia użytkownika. Kontrola brandingu to jeden z głównych powodów, dla których organizacje wybierają External ID zamiast własnego systemu logowania. Masz pełną kontrolę nad wyglądem stron rejestracji i logowania. Wgrasz logo, ustawisz kolory tła, dodasz fejwikon w karcie przeglądarki oraz dostosujesz nagłówek i stopkę z linkami do polityki prywatności i regulaminu. Jeśli potrzebujesz jeszcze większej kontroli, możesz przesłać własny plik CSS, aby nadpisać czcionki, kolory przycisków i układ. To Twoja marka, Twoje kolory, o wszystkim decydujesz Ty.

Tutaj sytuacja robi się nieco bardziej skomplikowana. Branding jest globalny dla dzierżawy, a nie dla każdej aplikacji z osobna. Jeśli więc masz wiele aplikacji, na przykład portal klienta i aplikację mobilną, wszystkie współdzielą te same strony z brandingiem. Nie możesz nadać każdej aplikacji unikalnego wyglądu. Starszy Azure Ad B2C pozwalał na branding per aplikacja, ale External ID jeszcze tego nie obsługuje. Kolejne ograniczenie, komunikaty o błędach na stronach logowania, nie podlegają edycji. Jeśli ktoś wpisze nieistniejący adres e-mail, zobaczy komunikat typu Nie znaleźliśmy konta o tym adresie e-mail. Tego tekstu nie można zmienić. Dla niektórych organizacji jest to akceptowalne, ale dla innych, zwłaszcza w branżach regulowanych lub z rygorystycznym językiem marki, stanowi to realny problem. Aplikacje mobilne mają lepszą opcję. External ID posiada natywne API uwierzytelniania dla systemów iOS i Android.

Zamiast przekierowywać użytkowników na stronę logowania w przeglądarce, możesz zbudować w pełni własne ekrany logowania wewnątrz aplikacji. Bez przekierowań do przeglądarki, bez nieporęcznych widoków internetowych. Użytkownik cały czas pozostaje w Twojej aplikacji, a Ty kontrolujesz każdy piksel. To znacznie płynniejsze doświadczenie i jedna z tych funkcji, których Azure Ad B2C nigdy nie oferował. Migracja z Azure Ad B2C. Jeśli korzystasz już z Azure Ad B2C, prawdopodobnie zastanawiasz się, co to dla Ciebie oznacza. Oto jak to wygląda. Microsoft będzie wspierać B2C co najmniej do 2030 roku. Twoje obecne dzierżawy nie przestaną działać z dnia na dzień, ale nie pojawią się w nich nowe funkcje. Wszelkie innowacje, klucze dostępu, uwierzytelnianie natywne i ochrona przed oszustwami są zarezerwowane dla External ID. Znajdujesz się na platformie, która w zasadzie została zamrożona. Firma Microsoft udostępniła oficjalne narzędzia i wskazówki dotyczące migracji, a zależnie od skali dostępne są dwie ścieżki.

Dla dzierżaw z liczbą mniejszą niż około 5 milionów obiektów katalogowych, użytkowników grup i atrybutów niestandardowych standardowa migracja jest stosunkowo prosta. Działa to podobnie jak przeniesienie między dzierżawami. Tworzysz nową dzierżawę External ID, migrujesz użytkowników wraz z ich danymi uwierzytelniającymi, a następnie przełączasz swoje aplikacje. Microsoft udostępnia narzędzia do masowego eksportu i importu użytkowników, a do ograniczenia zakłóceń podczas przejścia można użyć migracji haseł Just In Time. Dla większych dzierżaw posiadających ponad 5 milionów obiektów katalogowych dostępny jest tryb wysokiej skali, czyli HSC. W tym trybie Azure Ad B2C oraz External ID działają równolegle w ramach tej samej dzierżawy. Twoje istniejące punkty końcowe B2C pozostają aktywne, podczas gdy Ty stopniowo przenosisz kolejne aplikacje. Zostało to zaprojektowane dla organizacji, które nie mogą przenieść milionów użytkowników z dnia na dzień, ale wiąże się to z pewnymi kompromisami.

Brak obsługi dostawców tożsamości społecznościowych, brak kluczy dostępu paskiz,

A teraz ważna zmiana. Niestandardowe zasady znikają. Jeśli stworzyłeś złożone przepływy uwierzytelniania przy użyciu opartego na XML środowiska Identity Experience Framework z Azure Ad B2C, nie będą one działać w External ID. Będziesz musiał przebudować tę logikę przy użyciu przepływów użytkownika i niestandardowych rozszerzeń uwierzytelniania. Nie ma magicznego narzędzia, które przekonwertuje Twój kod XML na nowy format. Po prostu musisz wykonać te prace samodzielnie. Podsumowując, oto jak to wygląda. Jeśli zaczynasz od zera, wybierz External ID. Nie ma powodu, aby w ogóle patrzeć na B2C. Jeśli masz już istniejącą dzierżawę B2C, zacznij planować migrację już teraz. Masz czas do 2030 roku, ale czekanie do ostatniej chwili oznacza pośpieszną, złożoną migrację przy jednoczesnym utrzymaniu działania obecnych aplikacji. Zacznij od małych kroków. Wybierz jedną aplikację, przeprowadź migrację, przetestuj ją, wyciągnij wnioski z tego procesu, a następnie zajmij się resztą.

Doświadczenie programisty i automatyzacja. Microsoft naprawdę skupił się na tym, aby External ID było przyjazne dla programistów, co stanowi ogromną zmianę w porównaniu do starych, niestandardowych zasad B2C. Pamiętasz te pliki XML, które miały setki linii i psuły się, jeśli postawiłeś jeden nawias w złym miejscu? Tego już nie ma. Dostępne jest rozszerzenie do Visual Studio Code o nazwie Microsoft Entra External ID. Po zalogowaniu możesz przeglądać swoją dzierżawę, wyświetlać przepływy użytkownika, pobierać je jako pliki JSON, a nawet podglądać branding wszystko bez opuszczania edytora. Widzisz, jak wygląda twoja strona logowania, zanim jeszcze ją opublikujesz. Do tego dochodzi interfejs Microsoft Graph API. Prawie każdy zasób External ID, przepływy użytkownika, rejestracja aplikacji czy branding może być zarządzany programowo. Oznacza to, że możesz zautomatyzować konfigurację dzierżawy w potokach CI, CD przy użyciu programu PowerShell lub wywołań REST.

Stwórz nowego tenanta, skonfiguruj przepływy użytkowników, zarejestruj aplikację i ustaw branding wszystko za pomocą skryptu. Jeśli zarządzasz wieloma środowiskami, oszczędza to mnóstwo czasu. Niestandardowe rozszerzenia uwierzytelniania to miejsce, gdzie kryje się prawdziwa moc. Zamiast złożonego XML-a, rozszerzasz przepływy uwierzytelniania prostymi wywołaniami HTTP do Azure Functions. Istnieją cztery zdarzenia, pod które możesz się podpiąć. Początek wydawania tokena pozwala dodawać do nich niestandardowe oświadczenia, jak role czy informacje o poziomie lojalności. Początek i przesłanie zbierania atrybutów pozwalają walidować lub wstępnie wypełniać dane rejestracji, wywołując własny backend. A wysłanie jednorazowego kodu OTP pozwala dostosować e-maile weryfikacyjne. To ta sama elastyczność, którą miało B2C, ale w modelu, z którym poradzi sobie każdy programista. Warto znać pewne ograniczenia.

Brak jeszcze powiadomień Microsoft Graph, więc nie wywołasz automatycznie przepływu pracy po rejestracji nowego użytkownika. Niektóre konfiguracje nadal wymagają ręcznego ustawienia w centrum i brak wbudowanej strony edycji profilu. Jeśli chcesz, by użytkownicy aktualizowali swoje dane, musisz zbudować tę stronę w aplikacji i samodzielnie wywołać API Graph. Ale kierunek jest jasny. Microsoft chce, aby External ID było w pełni automatyzowalne. Dzięki temu łatwiej zarządzać rozwiązaniem na dużą skalę. Wiesz już, że Microsoft Entra External ID to nowoczesny zamiennik Azure Ad B2C zunifikowany pod marką Entra. Trzy przypadki użycia – tożsamość klienta, współpraca z partnerami i komunikacja maszyna-maszyna pokrywają niemal każdą potrzebę zewnętrznej tożsamości. Kluczową decyzją jest wybór między użyciem tenanta pracowniczego a utworzeniem osobnego tenanta zewnętrznego. Dla aplikacji skierowanych do klientów osobny tenant jest prawie zawsze lepszym rozwiązaniem.

Tożsamość to drzwi wejściowe do Twojej aplikacji. Poprawne, bezpieczne, spójne wizualnie i proste rozwiązanie bezpośrednio wpływa na zaufanie użytkowników i rozwój biznesu. Twoje zadanie domowe – wejdź na entra.microsoft.com, utwórz zewnętrznego tenanta i wypróbuj przewodnik dla początkujących. Przeprowadzi Cię on przez konfigurację przykładowej aplikacji w kilka minut. Zasubskrybuj, aby otrzymywać więcej prostych wyjaśnień platformy tożsamości Microsoft.