Bezpieczeństwo i tożsamość w Salesforce: kiedy używać single sign-on, a kiedy OAuth
W tym wpisie chcę wyjaśnić kwestie bezpieczeństwa i tożsamości w Salesforce, skupiając się na tym, kiedy używać single sign-on (SSO), a kiedy OAuth. Ta wiedza jest kluczowa, żeby poruszać się po różnych scenariuszach dostępu do Salesforce: przez bezpośrednie logowanie, SSO albo OAuth.
Kiedy używać zwykłego logowania, single sign-on, a kiedy OAuth
Bezpośrednie logowanie:
Scenariusz: użytkownik chce przez przeglądarkę wejść do Salesforce i oglądać jego strony.
Metoda dostępu: bezpośrednie logowanie do Salesforce albo single sign-on przez zewnętrznego dostawcę tożsamości, które daje płynny dostęp bez ponownego uwierzytelniania.
OAuth w aplikacjach mobilnych:
Scenariusz: użytkownik korzysta z aplikacji mobilnej, która pobiera dane z Salesforce przez API, a nie wyświetla natywnych stron Salesforce.
Metoda dostępu: tu stosuje się OAuth, zwłaszcza gdy interakcja odbywa się przez urządzenia mobilne, w tym telefony lub tablety korzystające z technologii przeglądarkowej. To podejście pozwala aplikacjom mobilnym bezpiecznie współpracować z API Salesforce.
OAuth z serwerami zewnętrznymi:
Scenariusz: użytkownik korzysta z przeglądarki, żeby komunikować się z zewnętrznym serwerem, który potrzebuje dostępu do danych Salesforce w imieniu użytkownika. Przykłady to wtyczki do poczty e-mail albo inne systemy zintegrowane z Salesforce.
Metoda dostępu: do bezpiecznego dostępu używa się OAuth ze specjalnym protokołem „Web Server with PKCE” (Proof Key for Code Exchange).
Przepływy OAuth dla różnych scenariuszy
Client Credentials Flow: przeznaczony dla procesu klienckiego (na przykład serwerów zewnętrznych wykonujących ładowania wsadowe lub eksporty), który korzysta z Salesforce przez wyznaczone konto użytkownika integracyjnego.
Przepływy JWT, SAML Bearer Assertion i SAML Assertion: służą do scenariuszy, w których proces kliencki musi działać w imieniu konkretnego użytkownika bez jego bezpośredniego udziału. Proces podszywa się wtedy pod wyznaczonego użytkownika, zachowując kontekst bezpieczeństwa jego plików.
Device Flow: ten przepływ inicjuje urządzenie, które wymaga zatwierdzenia przez człowieka. Na przykład aplikacja na smart TV prosi użytkownika o wpisanie kodu, żeby zatwierdzić dostęp.
Asset Flow: przydatny dla urządzeń internetu rzeczy (IoT), które muszą łączyć się z Salesforce, żeby odczytywać lub zapisywać dane.
Podsumowanie i wnioski
Krótko mówiąc, metoda dostępu zależy w dużej mierze od scenariusza:
Do bezpośredniego dostępu do Salesforce przez przeglądarkę używaj bezpośredniego logowania albo single sign-on, jeśli masz usługę tożsamości.
Do dostępu pośredniego przez urządzenia mobilne, serwery zewnętrzne lub zautomatyzowane procesy preferowaną metodą jest OAuth. Trzeba wtedy zdecydować, czy OAuth będzie działać w imieniu użytkownika-człowieka, czy konta użytkownika integracyjnego.
W kolejnych artykułach zagłębimy się w każdy scenariusz i przypadek użycia, żeby dać pełny obraz.
Bądźmy w kontakcie
Wyrusz w swoją podróż po tożsamości w Salesforce z pewnością siebie! Więcej spostrzeżeń i wskazówek znajdziesz tutaj, na www.SteveTechArc.com, i na kanale YouTube @SteveTechArc (opens in a new tab). Zasubskrybuj i pogłębiaj swoje zrozumienie tożsamości w Salesforce.
Pomagam zmieniać świat, dzieląc się wiedzą o integracji z innymi architektami i z tymi, którzy są na drodze do architektury!
STA 3.9