Trudno mi wybrać przyzwoitą / bezpieczną strategię uwierzytelniania dla architektury mikrousług. Jedyny post SO, jaki znalazłem na ten temat, to ten: Single Sign-On in Microservice Architecture
Moim pomysłem jest posiadanie w każdej usłudze (np. Uwierzytelnianie, przesyłanie wiadomości, powiadomienie, profil itp.) Unikalnego odniesienia do każdego użytkownika (całkiem logicznie niż jego user_id) i możliwość uzyskania aktualnego użytkownika, idjeśli jest zalogowany.
Z moich badań wynika, że istnieją dwie możliwe strategie:
1. Architektura współdzielona
W tej strategii aplikacja uwierzytelniająca jest jedną z usług. Ale każda usługa musi mieć możliwość wykonania konwersji session_id=>, user_idwięc musi być śmiertelnie prosta. Dlatego pomyślałem o Redisie, który przechowywałby klucz: wartość session_id:user_id.
2. Architektura zapory
W tej strategii przechowywanie sesji nie ma tak naprawdę znaczenia, ponieważ jest obsługiwane tylko przez aplikację uwierzytelniającą. Następnie user_idmożna je przekazać do innych usług. Pomyślałem o Rails + Devise (+ Redis lub pamięć podręczna lub przechowywanie plików cookie itp.), Ale jest mnóstwo możliwości. Liczy się tylko to, że Service X nigdy nie będzie musiał uwierzytelniać użytkownika.
Jak wypada porównanie tych dwóch rozwiązań pod względem:
- bezpieczeństwo
- krzepkość
- skalowalność
- łatwość użycia
A może zasugerowałbyś inne rozwiązanie, o którym tutaj nie wspomniałem?
Rozwiązanie nr 1 podoba mi się bardziej, ale nie znalazłem zbyt wielu domyślnych implementacji, które zabezpieczyłyby mnie w tym, że idę w dobrym kierunku.
Mam nadzieję, że moje pytanie nie zostanie zamknięte. Naprawdę nie wiem, gdzie jeszcze o to zapytać.
Z góry dziękuję
