Powszechna digitalizacja usług sprawia, że coraz więcej zasobów przenoszonych jest do chmury. Chociaż takie podejście przynosi liczne korzyści, w tym elastyczność i skalowalność, to jednocześnie eksponuje te usługi na zewnątrz, zwiększając ryzyko nieautoryzowanego dostępu. Zarządzanie dostępem do zasobów w chmurze staje się coraz większym wyzwaniem, zwłaszcza w dużych organizacjach, które operują na rosnącej liczbie użytkowników, kontrahentów oraz różnorodności ról i uprawnień.  

Ten proces przyciągnął uwagę globalnej społeczności, która za pomocą wytycznych i dyrektyw podkreśla znaczenie dostosowywania praktyk bezpiecznych do specyfiki danej firmy oraz sektorów, w których działa.  Dyrektywa 2022/2555, znana jako dyrektywa NIS 2, jest reakcją Unii Europejskiej na zachodzące zmiany i konieczność wprowadzenia jednakowego zestawu obowiązków i standardów z zakresu bezpieczeństwa informacji w obrębie krajów wspólnoty. Najważniejsze obowiązki wynikające z dyrektywy to: 

1. 1. Obowiązek wprowadzenia środków zarządzania ryzykiem i reagowania na incydenty. 
   2. Obowiązek zgłaszania poważnych incydentów cyberbezpieczeństwa do właściwych organów. 
   3. Wymóg współpracy między państwami członkowskimi oraz z odpowiednimi organami na poziomie UE. 
   4. Dedykowane wymagania dla kluczowych sektorów, takich jak energia, transport, zdrowie i finanse. 

Co zmieni dyrektywa NIS 2 

Nowe przepisy objęły więcej sektorów i liczniejsze grono organizacji, w tym średnie i duże przedsiębiorstwa z branż krytycznych. Wprowadzono bardziej restrykcyjne wymogi dotyczące bezpieczeństwa informacji oraz obowiązki sprawozdawcze, w celu zwiększenia odporności na zagrożenia cybernetyczne. Zgodnie z Artykułem 21 punkt 3, firmy mają obowiązek zweryfikować ogólną jakość produktów i praktyk cyberbezpieczeństwa dostawców i usługodawców, w tym ich procedury bezpiecznego opracowywania. 

Z kolei w raporcie „Foresight Cybersecurity Threats for 2030”, ENISA (Europejska Agencja ds. Bezpieczeństwa Sieci) przedstawiła szczegółową analizę pojawiających się zagrożeń cyberbezpieczeństwa w perspektywie do roku 2030. Analitycy wśród głównych zagrożeń wskazali: 

• Zakłócenie łańcucha dostaw oprogramowania 

• Niedobór wykwalifikowanych specjalistów ds. cyberbezpieczeństwa 

• Błędy ludzkie i eksploatowane systemy legacy 

Najnowsze raporty na temat bezpieczeństwa łańcucha dostaw oprogramowania potwierdzają, że jest to jedno z największych zagrożeń dla cyberbezpieczeństwa. Raport „The State of Software Supply Chain Security 2024” od ReversingLabs wskazuje, że liczba ataków na łańcuch dostaw oprogramowania wzrosła o 289% w ciągu ostatnich czterech lat, przy czym najwięcej ataków skoncentrowało się na popularnych repozytoriach open-source, takich jak npm i PyPI​. (1) 

W publikacji ENISA wskazano również niebezpieczeństwo związane z rosnącą zależnością kluczowych sektorów gospodarki, od zewnętrznych usług IT. Może ona prowadzić do zwiększonej liczby interakcji w krajobrazie cyfrowym. Efektem tego procesu jest stopniowe uzależnianie się kluczowych dostawców usług od oprogramowania, którego proces powstawania nie jest certyfikowany ani zarządzany.  

Jak zapewnić zgodność rozwiązań IT z dyrektywą NIS 2?

NIS 2 jest dość ogólną dyrektywą. Nie mówi wprost, co należy zrobić i jakie działania podjąć. Niemniej jednak wytycza pewien kierunek działań z obszaru cyberbezpieczeństwa, wśród których warto podkreślić: 

• zapewnienie jednolitego i sprawdzonego autoryzowanego dostępu do usług cyfrowych, zwłaszcza tych przetwarzających dane osobowe,
• zapewnienie w przedsiębiorstwach procesów stałego monitoringu oraz aktualizacji zabezpieczeń dla kluczowych punktów dostępu usług 
• ustandaryzowanie procesów dostępu do usług cyfrowych wraz ze wdrożeniem systemu zarządzania tożsamością użytkowników 
• raportowanie i monitorowanie stanu dostępu do autoryzowanych usługi i zbiorów danych.

Z tego względu możemy w najbliższym czasie spodziewać się wzrostu zainteresowania wdrażaniem rozwiązań klasy IAM (identity and access management). Podstawowym problemem, jest nie tylko wdrożenie samego systemu tej klasy, ale przede wszystkim możliwość dopasowania do potrzeb integracji konkretnych rozwiązań:  

SSO z Keycloak– znacząco upraszcza proces uwierzytelniania i autoryzacji w organizacjach, poprawiając wygodę użytkowników oraz bezpieczeństwo systemów. Dzięki jednorazowemu logowaniu, użytkownicy mogą efektywniej korzystać z różnych aplikacji, co zwiększa produktywność. 

Event Logging i alarmy– Keycloak rejestruje różnorodne zdarzenia, takie jak logowania, zmiany haseł, błędy uwierzytelniania oraz modyfikacje konfiguracji systemu. – Custom authrozation flow / na czym polega problem i dlaczego jest ważny. Alarmy pomagają w szybkiej reakcji na zagrożenia, minimalizując ryzyko naruszeń bezpieczeństwa i zwiększając ochronę zasobów w chmurze. 

Custom Authorization Flow w Keycloak– pozwala na tworzenie niestandardowych procesów uwierzytelniania i autoryzacji, dostosowanych do specyficznych wymagań organizacji. Potrzeba zastosowania tego rozwiązania wynika z konieczności zapewnienia elastyczności i bezpieczeństwa w zarządzaniu dostępem do zasobów. 

Identity Provieders – Integracja Keycloak z Microsoft Active Directory (AD) i Google Workspace umożliwia centralne zarządzanie tożsamościami i dostępem. Dzięki temu użytkownicy mogą korzystać z jednolitego logowania (SSO), uzyskując dostęp do wielu aplikacji za pomocą jednego zestawu danych uwierzytelniających. 

Skalowanie Keycaloak– umożliwia obsługę rosnącej liczby użytkowników i aplikacji poprzez uruchamianie wielu instancji w konfiguracji klastrowej, co zapewnia równomierne rozłożenie obciążenia i wysoką dostępność. 

Jak przygotować się do rozmowy na temat wdrożenia Keycloak w dużej organizacji?

Rozmowy techniczne na temat wdrożenia nowych narzędzi bywają długie i wieloetapowe, dlatego warto się do nich właściwe przygotować, aby etap konsultacji przebiegł szybko i obie strony uzyskały wystarczającą liczbę informacji. O to jak najlepiej przygotować się do wdrożenia Keycloak zapytaliśmy naszego CEO, Andrzeja Chybickiego.

Jakie są najczęstsze potrzeby firm, które szukają współpracy w obszarze cyberbezpieczeństwa?

Keycloak jest specyficznym, ale i kompleksowym rozwiązaniem, które pozwala tworzyć rozbudowane systemy zarządzania autoryzacją użytkowników. Jego największą zaletą jest możliwość wdrażania jako software on-premise. 

Firmy z bogatym doświadczeniem również mogą napotkać wyzwania, wprowadzając istotną zmianę jaką jest customowy flow autoryzacji w swoich systemach logowania i często poszukują konsultacji. W takich sytuacjach szukają one partnerów, którzy mają praktykę w realizacji podobnych projektów, znają typowe problemy i posiadają sprawdzone metody ich rozwiązywania. 

Klientami naszej firmy są organizacje na różnorodnych poziomach doświadczenia z IAM – niektóre rozważają implementację, zdając sobie sprawę z korzyści płynących z zarządzania tożsamością i dostępem, ale niepewne, od gdzie zacząć. Inne już rozpoczęły wdrożenie i zainstalowały potrzebne komponenty, lecz napotykają wyzwania w sferze konfiguracji dostosowania do użytkowników, partnerów i pracowników, na przykład przy projektowaniu skomplikowanych schematów autoryzacji wymaganych przez ich działalność. 

Jak przygotować się do wdrożenia Keycloak, aby przebiegło ona sprawie? 

Pomagając firmom w tworzeniu wewnętrznych rozwiązań IAM nasze działania prowadzą do dwóch podstawowych pytań. Najpierw, należy ocenić czy Keycloak w porównaniu z innymi rozwiązaniami, takimi jak Okta czy AWS Cognito, które mogą oferować prostszą obsługę i automatyzację z poziomu chmury, jest najlepszym wyborem. Następnie, kluczowe staje się rozpisanie procesów autoryzacji, integracja aplikacji, typ instalacji (on-demand lub lokalnie), wsparcie techniczne oraz długofalowa strategia z akutalizacjami systemu. To są podstawowe kwestie do przedyskutowania na samym początku. 

Czego klienci oczekują od nas jako od firmy kompleksowo wdrażającej Keycloak? 

Nasze doświadczenie pokazuje, że największą pomocą dla naszych partnerów jest wiedza specjalistyczna zdobyta przy realizacji podobnych inicjatyw. Najczęściej poszukują specjalistów, gdy mają szczególne wymagania dotyczące dostosowania oprogramowania produkcyjnego lub potrzebują stworzyć dodatek (plugin). Oczekują od nas wsparcia, licząc na to, że wykorzystamy doświadczenia z poprzednich projektów i zaprezentujemy, jak radziliśmy sobie z podobnymi wyzwaniami w przeszłości. Przykładów jest tu bardzo wiele od zapewnienia skalowania, do konfiguracji i integracji z przepływami autoryzacji w chmurze po integrację z systemami baz danych zawierających obsługę milionów użytkowników jednocześnie. Naszym zadaniem jest świadczenie usług doradczych adekwatnych do ich zasadniczych potrzeb. 

Wdrożyliśmy Keycloak, ale co potem? Czy firma musi zatrudniać programistów znających to narzędzie do zarządzania systemem po jego implementacji? 

Proces wdrożenia i konfiguracji Keycloaka jest złożony, a intensywność prac w trakcie trwania projektu nie jest równomierna. Prace takie są najczęściej nadzorowane z działem bezpieczeństwa lub osobami na poziomie głównego technicznego managementu – wymagają zatem koordynacji wielu grup pracowników. Często potrzebna jest również koordynacja z zespołami wsparcia, aby ustalić optymalny czas na wprowadzanie zmian w procesach autoryzacyjnych. 

Implementacja Keycloaka nie wymaga ciągłej obecności dedykowanych ekspertów w organizacji. Keycloak jest generalnie stabilnym narzędziem i kluczowe jest, aby osoby zarządzające systemem posiadały wiedzę na temat jego funkcjonowania i były w stanie obsługiwać panel administracyjny Keycloaka, wykorzystując jego funkcje bez konieczności modyfikacji.  

Niemniej jednak, długoterminowe wsparcie jest kluczowe, w tym regularne aktualizacje bezpieczeństwa, które społeczność Keycloak udostępnia co kilka miesięcy. Takie aktualizacje mają charakter krytyczny i warto mieć dostęp do kompetencji i wiedzy na wypadek krytycznych problemów. 

[1] https://www.enisa.europa.eu/publications/foresight-cybersecurity-threats-for-2030-update-2024-extended-report

Wraz ze wzrostem liczby zagrożeń cybernetycznych, uwierzytelnianie wieloskładnikowe (MFA) stało się dla wielu firm standardem w politykach bezpieczeństwa.  MFA zwiększa ochronę, wymagając od użytkowników weryfikacji tożsamości za pomocą wielu metod. Takie uwierzytelnianie stało się więc standardową praktyk, dodając dodatkową warstwę ochrony.

Wśród różnych metod, uwierzytelnianie oparte na SMS wyróżnia się równowagą między bezpieczeństwem a wygodą użytkownika. Jednak tworzenie niestandardowego uwierzytelnienia SMS w ramach dostawcy tożsamości, takiego jak Keycloak, może być skomplikowanym i złożonym procesem, wymagającym zrozumienia jego architektury i możliwości rozszerzania.

Interfejs Dostawcy Usług (SPI)

Keycloak ma na celu obsługę większości przypadków użycia bez konieczności tworzenia niestandardowego kodu. Oferuje także elastyczność w zakresie dostosowywania. W tym celu Keycloak udostępnia kilka SPI, które pozwalają na wdrażanie własnych rozwiązań. Zamierzamy wdrożyć uwierzytelnianie, które wymaga ważnego kodu SMS. Aby stworzyć tę funkcję, musimy  zaimplementować interfejsy org.keycloak.authentication.AuthenticatorFactory i Authenticator. AuthenticatorFactory jest odpowiedzialny za tworzenie instancji Authenticatora. Oba interfejsy rozszerzają ogólny zestaw interfejsów Provider i ProviderFactory, które są używane przez inne komponenty Keycloak.

Pakietowanie klas

Będziemy pakietować nasze klasy do jednego projektu. Musi on zawierać plik o nazwie org.keycloak.authentication.AuthenticatorFactory, który powinien znajdować się w katalogu META-INF/services/. Plik ten musi zawierać pełne kwalifikowane nazwy klas każdej implementacji AuthenticatorFactory, którą masz w pliku JAR. Na przykład:

pl.inero.keycloakext.authenticator.sms.SmsAuthenticatorFactory
pl.inero.keycloakext.authenticator.custom.CustomUsernamePasswordFormFactory
pl.inero.keycloakext.authenticator.custom.CustomCookieAuthenticatorFactory

Plik services/ jest używany przez Keycloak do skanowania dostawców, których musi załadować do systemu.

CredentialModel i CredentialProvider

Pierwszym krokiem jest skonfigurowanie naszych klas związanych z poświadczeniami, ponieważ numer telefonu użytkownika powinien być przechowywany jako rekord poświadczeń. Jak widać poniżej, klasa Sms2faCredentialData jest prostym kontenerem danych do przechowywania numeru telefonu powiązanego z użytkownikiem.

public class Sms2faCredentialData {

private String phoneNumber;

@SuppressWarnings("unused") //used for credentials deserialization
public Sms2faCredentialData() {
}

public Sms2faCredentialData(String phoneNumber) {
     this.phoneNumber = phoneNumber;
}

public String getPhoneNumber() {
     return phoneNumber;
}

@SuppressWarnings("unused") //used for credentials deserialization
public void setPhoneNumber(String phoneNumber) {
     this.phoneNumber = phoneNumber;
}
}

Kolejnym krokiem jest rozszerzenie klasy CredentialModel, która może generować prawidłowy format poświadczeń w bazie danych. Aby obiekty Sms2faCredentialModel były w pełni funkcjonalne, muszą zawierać nie tylko surowe dane JSON odziedziczone po klasie bazowej, ale także odmarshallowane obiekty wewnątrz swoich własnych atrybutów. Zapewnia to szeroką dostępność i wykorzystanie poświadczeń, umożliwiając łatwą integrację i obsługę procesów uwierzytelniania.

public class Sms2faCredentialModel extends CredentialModel {

public static final String TYPE = "sms2fa";
private Sms2faCredentialData smsCredentials;

public Sms2faCredentialModel(Sms2faCredentialData smsCredentials) {
     try {
         this.smsCredentials = smsCredentials;
         setCredentialData(JsonSerialization.writeValueAsString(smsCredentials));
         setUserLabel("tel: " + smsCredentials.getPhoneNumber());

         setType(TYPE);
     } catch (IOException e) {
         throw new RuntimeException(e);
     }
}

public String getPhoneNumber() {
     return smsCredentials.getPhoneNumber();
}
}

Podobnie jak w przypadku innych dostawców w Keycloak, utworzenie CredentialProvider wymaga obecności odpowiadającej mu CredentialsProviderFactory. Aby spełnić ten wymóg, implementujemy Sms2faCredentialProviderFactory.

public class Sms2faCredentialProviderFactory  implements CredentialProviderFactory<Sms2faCredentialProvider> {

public static final String PROVIDER_ID = "keycloak-ext-sms2fa";

@Override
public String getId() {
     return PROVIDER_ID;
}

@Override
public CredentialProvider<Sms2faCredentialModel> create(KeycloakSession session) {
     return new Sms2faCredentialProvider(session);
}
}

Interfejs CredentialProvider jest zbudowany z parametrem generycznym, który rozszerza CredentialModel, zapewniając kompatybilność z różnymi typami poświadczeń. Dodatkowo musimy zaimplementować interfejs CredentialInputValidator, co wskazuje Keycloak, że ten dostawca jest przygotowany do uwierzytelniania poświadczeń dla naszego niestandardowego Authenticatora. Chociaż nie będziemy tu omawiać pełnej architektury, dokumentacja Keycloak obejmuje dodatkowe metody.

Nasza implementacja obejmuje funkcje tworzenia i usuwania poświadczeń. Funkcje te wykorzystują menedżera poświadczeń, odpowiedzialnego za przechowywanie i pobieranie poświadczeń, niezależnie od tego, czy są one przechowywane lokalnie, czy w systemach magazynowania federacyjnego.

@Override
public CredentialModel createCredential(RealmModel realm, UserModel user, Sms2faCredentialModel credentialModel) {
if (credentialModel.getCreatedDate() == null) {
     credentialModel.setCreatedDate(Time.currentTimeMillis());
return user.credentialManager().createStoredCredential(credentialModel);
}

@Override
public boolean deleteCredential(RealmModel realm, UserModel user, String credentialId) {
logger.debugv("Delete Sms2fa credential. username = {0}, credentialId = {1}", user.getUsername(), credentialId);
return user.credentialManager().removeStoredCredentialById(credentialId);
}

Dla interfejsu CredentialInputValidator główną metodą do zaimplementowania jest isValid, która sprawdza, czy dane poświadczenie jest ważne dla danego użytkownika w danej domenie (realm). Jest to metoda wywoływana przez Authenticator, gdy chce zweryfikować dane wprowadzone przez użytkownika.

@Override
public boolean isValid(RealmModel realm, UserModel user, CredentialInput credentialInput) {
final Sms2faCredentialModel credentialModel = getDefaultCredential(session, realm, user);
final String secretData = credentialModel.getSecretData();
return secretData != null && secretData.equals(credentialInput.getChallengeResponse());

Teraz powinniśmy mieć wszystko, aby móc przejść do implementacji samego Authenticatora.

AuthenticatorFactory i Authenticator

Klasa SmsAuthenticatorFactory zawiera logikę potrzebną do skonfigurowania i tworzenia instancji SmsAuthenticator, który wykonuje walidację OTP opartą na SMS. Obsługuje dostosowywanie poprzez kilka konfigurowalnych właściwości.

supports customization through several configurable properties.
public class SmsAuthenticatorFactory implements AuthenticatorFactory {

@Override
public String getId() {
     return "sms-authenticator";
}

@Override
public String getDisplayType() {
     return "SMS Authentication";
}
@Override
public String getHelpText() {
     return "Validates an OTP sent via SMS to the users mobile phone.";
}
     (…)
}

Teraz przejdźmy do samego Authenticatora. Główna metoda, na której się skupimy, to sendChallenge(). Kiedy przepływ jest początkowo wyzwalany, ta metoda jest wywoływana. Ważne jest, aby zauważyć, że nie obsługuje ona przetwarzania formularza kodu SMS. Jej rola polega na renderowaniu strony lub kontynuowaniu przepływu.

Strona HTML, która prosi o wprowadzenie otrzymanego kodu, jest prezentowana użytkownikowi, który następnie wprowadza kod i przesyła go. Wówczas wysyłane jest żądanie HTTP do przepływu za pomocą adresu URL akcji określonego w formularzu HTML. To wyzwala metodę action() w naszej implementacji Authenticatora. Jeśli podany kod jest nieprawidłowy, rekonstruujemy formularz HTML, dodając komunikat o błędzie. Następnie używamy metody failureChallenge(), przekazując powód niepowodzenia. Działa ona podobnie do challenge(), ale dodatkowo loguje błąd, co pomaga wykryć ewentualne możliwości ataku.

private void sendChallenge(AuthenticationFlowContext context) {
(…)
credentialModel.setSecretData(code);
user.credentialManager().updateStoredCredential(credentialModel);
AuthenticationSessionModel authSession = context.getAuthenticationSession();
authSession.setAuthNote("ttl", Long.toString(System.currentTimeMillis() + (ttl * 1000L)));

try {
     /* sending SMS */
     context.challenge(context.form().setAttribute("realm", context.getRealm()).createForm(TPL_CODE));
} catch (Exception e) {
     context.failureChallenge(AuthenticationFlowError.INTERNAL_ERROR,
             context.form().setError("smsAuthSmsNotSent", e.getMessage())
                     .createErrorPage(Response.Status.INTERNAL_SERVER_ERROR));
}
}

@Override
public void action(AuthenticationFlowContext context) {
(…)
final Sms2faCredentialModel credentialModel = getCredentialProvider(session).getDefaultCredential(session, context.getRealm(), user);
boolean isValid = getCredentialProvider(context.getSession()).isValid(context.getRealm(), context.getUser(),
       new UserCredentialModel(credentialModel.getId(), getCredentialProvider(context.getSession()).getType(), enteredCode));
if (isValid) {
     if (Long.parseLong(ttl) < System.currentTimeMillis()) {
         // expired
         context.failureChallenge(AuthenticationFlowError.EXPIRED_CODE,

                 context.form().setError("smsAuthCodeExpired").createErrorPage(Response.Status.BAD_REQUEST));
     } else {
         // valid
         context.success();
     }
} else {
     context.getEvent().user(user).error(Errors.INVALID_USER_CREDENTIALS);
     context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
             context.form().setAttribute("realm", context.getRealm())
                     .setError("smsAuthCodeInvalid").createForm(TPL_CODE));
}
}

Authentication Flow

Aby dodać Authenticator do przepływu, administrator musi przejść do Konsoli. W sekcji Uwierzytelnianie (Authentication) i zakładce Przepływy (Flows) powinien zobaczyć istniejące przepływy. Wbudowane przepływy nie mogą być bezpośrednio modyfikowane, więc aby zintegrować nowo utworzony Authenticator, musimy albo zduplikować istniejący przepływ, albo stworzyć nowy od podstaw.

Required actions

Jeśli telefon nie jest skonfigurowany, powinniśmy wywołać niestandardowe wymagane działanie. Ponownie, powinniśmy dodać pełną kwalifikowaną nazwę klasy do katalogu META-INF/services i zaimplementować interfejs RequiredActionProvider. Metoda requiredActionChallenge() jest odpowiedzialna za renderowanie HTML, który poprowadzi wymagane działanie.

@Override
public void requiredActionChallenge(RequiredActionContext context) {
LoginFormsProvider form = context.form();
if (getSmsAuthenticatorConfig(context) == null) {
     form.setError("smsAuthMissingAuthenticatorConfig");
}
final Response response = form.createForm("sms-2fa-register.ftl");
context.challenge(response);
}

Ta część jest odpowiedzialna za przetwarzanie danych wejściowych z formularza HTML wymaganego działania. Po wprowadzeniu otrzymanego kodu SMS, numer telefonu powinien zostać zapisany w bazie danych jako poświadczenie. Przy następnym logowaniu będziemy mogli skorzystać z tej formy OTP.

@Override
public void processAction(RequiredActionContext context) {
    (…)
final String phoneNumber = params.getFirst("phoneNumber");
final String code = params.getFirst("code");

if(StringUtils.isBlank(phoneNumber) && StringUtils.isBlank(authSession.getAuthNote("phone_number"))) {
     //if no phone number is set, redirect to the first page
     requiredActionChallenge(context);
     return;
}
if (phoneNumber != null) {
     sendPhoneNumberVerificationChallenge(context, authSession, phoneNumber, smsAuthenticatorConfig.getConfig());
     return;
}
if (code != null) {
     /* verify provided SMS code */ 
    }
}

Ostatnią rzeczą, którą musisz zrobić, jest przejście do Konsoli Administratora i zakładki Wymagane Działania (Required Actions). Twoje nowe działanie powinno teraz być wyświetlone i włączone na liście wymaganych działań.

Jeśli użytkownik nie podał wcześniej numeru telefonu, a uwierzytelnianie SMS jest ustawione jako wymagane w przepływie uwierzytelniania, powinna pojawić się nowa widok.

Podsumowując, konfiguracja SMS MFA obejmuje ustawienie niestandardowych wymaganych działań oraz dostawców uwierzytelniania, ale oczywiście istnieją inne kwestie do uwzględnienia, takie jak komunikacja między Keycloak a bramką SMS. Zagadnienia, które omówiliśmy w tym poście, to oczywiście tylko część możliwej konfiguracji, ale najważniejsza i specyficzna dla Keycloak.

Jedną z istotnych zalet wdrożenia SMS MFA jest jego powszechna dostępność, ponieważ większość użytkowników posiada telefony komórkowe zdolne do odbierania wiadomości SMS. Dodatkowo, zapewnia to prostą obsługę dla użytkowników, wymagając minimalnej konfiguracji i znajomości. Jednak mechanizm ten ma swoje wady, w tym potencjalne zagrożenia, takie jak ataki polegające na zamianie kart SIM lub przechwytywaniu kodów SMS. Ponadto, dostarczanie wiadomości SMS może czasami być zawodnym procesem, co prowadzi do opóźnień lub nieudanej dostawy, wpływając na doświadczenie użytkownika. Powinniśmy być tego świadomi przed podjęciem decyzji o zastosowaniu tej metody, szczególnie w erze nowszych rozwiązań, takich jak mobilne aplikacje OTP.