@mp2w - Hejto.pl (demo semantyczne)

Autentykacja w mojej aplikacji wykonywana jest przez Auth0. Kiedy uzytkownik loguje sie komunikacja przechodzi przez load balancer, ktory pobiera token z Auth0 i zwraca go do aplikacji. Przy wykonywaniu kolejnych requestow, mimo oczekiwan load balancer, nie weryfikuje i nie odswieza tokenu. Moj uzytkownik przez 24h moze pracowac na tym samym tokenie. Mimo tego, ze token moze byc juz dawno nieaktywny.

Odnosnie tej dokumentacji: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html

"If the session timeout is longer than the access token expiration and the IdP supports refresh tokens, the load balancer refreshes the user session each time the access token expires. The load balancer has the user log in again only after the authentication session times out or the refresh flow fails."

Oczekiwalem ze token bedzie sie odswiezal. Moje ustawienia dla Auth0 sa poprawne i prawidlowo odswiezaja i uniewazniaja token.

Jest jakies optymalne rozwiazanie dla mojego problemu? Nie da sie prawdopodobnie zrobic przez konfiguracje ALB, kontaktowalem sie nawet z wsparciem AWS i nie maja na to rozwiazania.

Aktualnie 2 opcje jakie widze to:

* przeniesienie logiki odswiezania do mikroservice, ale to wymaga przerobienia chyba połowe aplikacji
* utworzenie lambdy, do ktorej bedzie przekierowanie z Load Balancera i ona byla by odpowiedziala za odswiezenie i sprawdzenie waznosci tokenu. Ale nie wiem czy to zadziala.

#aws #programowanie

DobraDupaPLSpecjalista3 lata temu0

@mp2w Oswiezanie bedzie wykonywac sie automatycznie jesli zrobie request do Auth0, tak jak opisales przy pomocy refresh token.
Wiem ze nie wszystko opisalem, ale tez nie moge wszystkiego niestety udostepniac.

mp2wStatysta3 lata temu0

@DobraDupaPL Wydaje mi się, iż ALB Auth nie spełnia Twoich wymagań. Może prościej będzie skorzystać z jakiś gotowych paczek/rozwiązań które są opisane na stronach Auth0/Okta. Jak dodasz to do kodu swojej aplikacji będziesz miał lepszą kontrolę.

Korzystasz z Auth0 więc zakładam, że używasz JWT i tokenów.

Ogólnie to request do Auth0 powinien być wykonywany w tle, w momencie kiedy:
- dostajesz odpowiedź z serwisu, że access token jest już nieważny
- tuż przed wygaśnięciem access tokenu (jakiś proces odświeża to w tle)
-- od Ciebie zależy, czy będzie to powiązane z session timeout
*zależy od charakterystyki działania aplikacji (najlepiej opcja2, prościej dorobić opcja1)

Nie wiem jaki masz szacowany ruch, ale w rozwiązaniu z Lambda sprawdziłbym, czy nie będzie Cię ograniczało w jakikolwiek sposób liczba równoległych zapytań.

Jeśli myślisz nad offline token (token ważny do 30 dni - domyślnie) to sprawdziłbym ograniczenia na Auth0, ile możesz przechowywać takich tokenów per client/realm

Lambda (jak ja to rozumiem):
- komponent, który działa jak "auth proxy" który waliduje każdy request i sprawdza ważność tokenu
-- problem to brak refresh token w zapytaniu, chyba że przesyłasz oba tokeny

Microservice:
- cała logika jest po stronie serwisu,
-- również musisz przekazywać access i refresh token

Korzytanie z offline token:
- klient się loguje. W serwisie coś się mieli i trwa to dużej niż sesja klienta, który sobie już poszedł. Access token ma ważność x godzin.
-- proste, pod warunkiem, że nie wypłynie ten token (będzie to prawidłowo zabezpieczone)

*są tutaj pewne uproszczenia i niekoniecznie musi to być zgodne z dobrymi praktykami

Pokaż więcej komentarzy (5)