Autoryzacja od końca do końca przez OAuth 2.0: jak połączyliśmy 6 usług w "1C-Bitrix"

Problem: 6 serwisów — 6 systemów autoryzacji

Kiedy dołączyliśmy do projektu, działało w nim 6 serwisów opartych na 1C-Bitrix. Każdy miał własny system autoryzacji. W poprzednim artykule poruszyliśmy już temat autoryzacji.

Co to oznaczało w praktyce?

• Użytkownik musiał rejestrować się i logować osobno w każdym serwisie.

• Bazy klientów były zduplikowane lub niespójne.

• Brakowało jednego, spójnego obrazu użytkownika: ten sam klient mógł mieć różne dane w poszczególnych serwisach.

• Dział wsparcia nie miał pełnego wglądu w informacje dotyczące użytkownika.

Biznes podjął decyzję: potrzebny jest jeden centralny punkt autoryzacji działający jako osobna aplikacja.

Architekt wybrał do tego celu Laravel. Właśnie wtedy dołączyliśmy do projektu.

Architektura: centralny serwis autoryzacji + 6 serwisów na Bitrix

Zaprojektowaliśmy system, w którym:

• Serwis autoryzacji oparty na Laravel stanowi jeden punkt wejścia dla wszystkich użytkowników.

• 6 serwisów opartych na 1C-Bitrix korzysta z autoryzacji za pośrednictwem OAuth 2.0.

• Konta techniczne do obsługi API zostały utworzone dla każdego serwisu Bitrix.

Dlaczego potrzebne były konta techniczne?

Dla każdego serwisu Bitrix utworzyliśmy konto techniczne do komunikacji przez API. Rozwiązanie to realizowało kilka zadań:

• Pobieranie uprawnień użytkowników zgodnie z modelem dostępu opartym na rolach, który opisaliśmy w poprzednim artykule.

• Wewnętrzna wymiana danych — synchronizacja informacji między serwisami.

• Ujednolicenie tożsamości użytkowników — dzięki temu klient mógł logować się do dowolnego serwisu za pośrednictwem wspólnego punktu wejścia.

Jak działa logowanie jednokrotne (SSO)?

Scenariusz dla klienta i użytkownika wewnętrznego:

1. Użytkownik loguje się do serwisu autoryzacji.

2. Widzi menu wyboru serwisów — listę systemów, do których ma dostęp.

3. Wybiera odpowiedni serwis.

4. Przechodzi do niego za pośrednictwem OAuth 2.0.

5. W nagłówku serwisu wyświetlana jest lista dostępnych serwisów, dzięki czemu użytkownik może przejść bezpośrednio do innego systemu, bez konieczności wracania do menu aplikacji autoryzacyjnej.

Wszystko działało zgodnie z założeniami. Wkrótce jednak odkryliśmy problem.

Problem: opóźnienia podczas autoryzacji

Po wdrożeniu logowania jednokrotnego w serwisach Bitrix zauważyliśmy, że wejście do serwisu trwało zbyt długo, nawet gdy użytkownik był już zalogowany.

Przeanalizowaliśmy wszystkie wymiany danych i znaleźliśmy przyczynę. Serwisy Bitrix otrzymywały dwa duże obiekty.

1. Obiekt klienta

Zawierał wszystkie wymagane kolekcje i powiązania. Im więcej danych o kliencie, tym większy obiekt — a im większy obiekt, tym dłuższy czas przesyłania przez sieć.

2. Obiekt zawierający wszystkie serwisy

Obiekt obejmował listę wszystkich serwisów wraz z ich nazwami, opisami i kodem obrazów SVG. Kod SVG był przechowywany w serwisie autoryzacji i za każdym razem przesyłany do serwisu Bitrix, aby wyświetlić ikony serwisów w nagłówku.

Czas przesyłania: kilka sekund. Z perspektywy biznesowej było to nieakceptowalne.

Rozwiązanie: zmniejszenie rozmiaru obiektów

Zoptymalizowaliśmy oba obiekty.

Co zrobiliśmy?

• Obiekt klienta — ograniczyliśmy do niezbędnego minimum. Usunęliśmy zbędne kolekcje i powiązania, pozostawiając wyłącznie dane faktycznie potrzebne serwisowi Bitrix do działania.

• Obiekt serwisów — usunęliśmy z niego kod SVG. Zamiast osadzonego kodu przesyłany jest teraz link do pliku SVG. Obraz ładuje się osobno, zamiast zwiększać rozmiar głównego obiektu.

Rezultat: opóźnienie zniknęło, a autoryzacja stała się szybka.

Nowe wyzwanie: serwisy dostępne dla gości

Wszystko działało dobrze. Pozostały jednak serwisy dostępne dla niezalogowanych użytkowników, na przykład Marketplace.

Scenariusz:

• Klient odwiedza Marketplace bez logowania.

• Dodaje produkty do koszyka.

• Chce złożyć zamówienie — i właśnie wtedy wymagana jest autoryzacja.

Jak wyglądałby ten proces bez dodatkowych zmian?

1. Klient przechodzi do serwisu autoryzacji.

2. Loguje się.

3. Wyszukuje Marketplace na liście dostępnych serwisów.

4. Wraca do koszyka.

Za dużo kroków i niepotrzebne utrudnienia. Klient mógł po prostu zrezygnować z zakupu.

Rozwiązanie: system wewnętrznych przekierowań

Wdrożyliśmy mechanizm wewnętrznych przekierowań, aby obsłużyć takie scenariusze.

Jak to działa?

1. Użytkownik klika przycisk logowania w serwisie dostępnym dla gości.

2. Do linku dodawany jest parametr GET zawierający adres bieżącej strony, z której użytkownik rozpoczął proces.

3. Użytkownik zostaje przekierowany do serwisu autoryzacji.

4. Serwis autoryzacji odczytuje parametr GET.

5. Po zakończeniu logowania użytkownik zostaje przekierowany z powrotem na stronę, na której wcześniej się znajdował.

Rezultat: klient wraca dokładnie tam, gdzie przerwał działanie, i może kontynuować składanie zamówienia.

Kolejne wyzwanie: bezpośrednie linki do plików

Problem dostępu gości został rozwiązany, ale pojawiła się kolejna kwestia.

Scenariusz:

• Niezalogowany użytkownik otrzymuje bezpośredni link do pliku — na przykład protokołu odbioru, faktury lub innego dokumentu.

• Bez autoryzacji nie może pobrać pliku.

• Nie wie też, gdzie przejść po zalogowaniu, aby go znaleźć.

Rozwiązanie: osobny mechanizm udostępniania plików

Przygotowaliśmy osobny scenariusz obsługi pobierania plików.

Jak to działa?

1. Dodaliśmy parametr GET service, który pozwala ustalić, z którego serwisu pochodzi żądanie.

2. Klient klika link do pliku.

3. Zostaje przekierowany do serwisu autoryzacji.

4. Loguje się.

5. Za pośrednictwem API kontaktujemy się z odpowiednim serwisem i pobieramy żądany dokument.

6. Udostępniamy plik bezpośrednio klientowi jako zasób, dzięki czemu może go pobrać.

Rezultat: klient otrzymuje dokument nawet wtedy, gdy link przyszedł do niego e-mailem, a on sam nie był wcześniej zalogowany.

Podsumowanie: nie tylko OAuth, ale także scenariusze biznesowe

Nie ograniczyliśmy się do wdrożenia logowania jednokrotnego za pomocą OAuth 2.0. Rozbudowaliśmy również mechanizm przekierowań, aby obsłużyć różne scenariusze biznesowe:

• szybkie przechodzenie do serwisów bez opóźnień podczas autoryzacji;

• powrót na pierwotną stronę po zalogowaniu;

• udostępnianie plików za pomocą bezpośrednich linków.

Wszystko po to, aby ułatwić życie klientom.

Stack technologiczny

• Serwis autoryzacji: Laravel (PHP)

• Serwisy: 1C-Bitrix

• Autoryzacja: OAuth 2.0

• Wymiana danych: API, JSON

Czego nauczyliśmy się z tego projektu?

1. Logowanie jednokrotne to nie tylko OAuth

OAuth 2.0 rozwiązuje problem logowania, ale rzeczywiste scenariusze — dostęp gości, koszyki zakupowe czy bezpośrednie linki do plików — wymagają dodatkowego mechanizmu przekierowań.

2. Optymalizacja wymiany danych ma kluczowe znaczenie

Kilka sekund opóźnienia może wydawać się drobiazgiem. Dla biznesu może jednak mieć istotne konsekwencje. Zmniejszenie rozmiaru obiektów i zastąpienie osadzonego kodu SVG linkami to proste rozwiązania, które przyniosły znaczącą poprawę.

3. Pamiętaj o niezalogowanych użytkownikach

Nie każdy użytkownik jest zalogowany. Scenariusze dla gości są często pomijane, a to właśnie na tym etapie można stracić potencjalnych klientów.

4. Bezpośrednie linki do plików wymagają osobnego scenariusza

Link do pliku otrzymany e-mailem to osobna ścieżka użytkownika. Trzeba ją zaprojektować świadomie, zamiast zakładać, że użytkownik sam znajdzie właściwe rozwiązanie.

Podsumowanie

Ta historia pokazuje, że wdrożenie logowania jednokrotnego to nie tylko konfiguracja OAuth i uznanie zadania za zakończone. To przede wszystkim projektowanie kompletnych ścieżek użytkownika: szybkiego logowania, powrotu na pierwotną stronę, obsługi koszyków zakupowych gości oraz pobierania plików z bezpośrednich linków.

Przepracowaliśmy te wyzwania i rozbudowaliśmy mechanizm przekierowań, aby obsłużyć różne scenariusze biznesowe. Klient loguje się tylko raz — i trafia dokładnie tam, gdzie potrzebuje.