Autentykacja

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

@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.

@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

@mp2w dzięki za odpowiedź, przeanalizuje to sobię.