Hejto.pl
Motyw strony
Dodaj post

Wpisz coś do wyszukania (minimum 2 znaki)

mp2wStatysta

Dołączył/a:

  • 0 wpisów
  • 2 komentarzy
  • 0 obserwujących
ProgramowanieAutentykacja w mojej aplikacji wykonywana jest przez Auth0. Kiedy uzytkownik loguje sie komunikacja przechodzi przez
Statysta0piorunów

@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

Statysta0piorunów

Trudno cokolwiek doradzać nie wiedząc jak jest napisana aplikacja, gdzie przechowujesz tokeny i kilku innych detali (złożoność, architektura, API, WEB, singlePageApp itp). To co obecnie proponujesz wygląda na próbę zastosowania luźnej interpretacji PEP. Tylko, że zamiast decyzji czy user ma prawo dostępu do określonych zasobów chcesz odświeżać tam JWT/token.

Niezależnie gdzie to przeniesiesz (POD/Mikroserwis/Lambda) według Twojego opisu będziesz implementować identyczną funkcjonalność.

Może zacznę od początku:
Po udanej autentykacji `user` jest przenoszony na Twoją stronę oraz gdzieś przechowujesz oba tokeny:
- Access token
- Refresh Token
Dodatkowo masz `timeout` na sesji.

Zamiast przepisywać serwisy to prościej będzie generować nowy `access token` wykorzystując `refersh token` i to powinno odbywać się po stronie klienta.

Jeśli będziesz odświeżać token automatycznie to sesja nigdy nie wygaśnie, jeśli pasywnie to musisz wybrać sobie logikę jak to ma działać

Oczywiście, jeśli masz wiele serwisów i serwisy pomiędzy sobą się komunikują, a do komunikacji wewnętrznej wykorzystujesz `access token` to można pomyśleć o offline session. Jednak i tutaj potrzebny jest mechanizm zapewniający wygenerowanie `świeżego` `access token`