Hej, prośba o Waszą opinię:

Mam serwis A, który korzysta z serwisu B wg standardu OAUTH2, użytkownicy nie są wspólni, w serwisie B ma być tylko jedno konto z którego to mają korzystać użytkownicy serwisu A. Czyli niezależnie na kogo się zalogujesz w serwisie A, zawsze logujesz się na B np. jako admin/admin.
I teraz pytanie, jak rozwiązać problem kontekstu aplikacji (gdzie jest np. access_token, refresh_token etc.) - do tej pory zawsze używałem sesji, jednak w sytuacji gdy jedno konto na A odpowiadało jednemu na B - w sytuacji tylko jednego konta na B nie wydaje mi się to właściwe i chcę po prostu kontekst zapisywać w bazie danych.
Ktoś ma może lepszy pomysł? Może sesja mimo wszystko? Spotkałem się nawet z użyciem ciastek.

Musisz rozwiązać problem przechowywania wielu tokenów w B więc sesja będzie mocno ograniczona. Można ale czy warto? Czyli tak na prawdę w B robić parowanie z kontem A.

B mnie jakby nie interesuje, bo tam już jest wszystko zaimplementowane (standard OAUTH2), udostępniają A najprostszą metodę autoryzacji (grant type = password), wysyłam credentials, dostaję token i go potem używam.
Problem mam z A, bo nie wiem, czy po zalogowaniu powiedzmy usera Y do A mam pytać B o token, czy lepiej sprawdzić w bazie, czy np. 10 minut wcześniej logował się X i jest ważny token, którego mogę użyć. Rozwiązanie drugie wydaje się lepsze, bo będzie mniej requestów.

Aaa ok. Nie zrozumiałem W 1 miejscu zapisz sobie Token + resztę info i po prostu każdemu userowi go udostępniaj. Generalnie obie wersje które powiedziałes sprowadzają się do tego samego: zapisania danych z oAuth w 1 miejscu dla wszystkich. Jak ktoś będzie chciał użyć tych danych a będą expired to wykona request do B i zapisze nowe dane, potem już X i Y będą używały świeżych danych.

Możesz to do Redisa zapisać jak masz albo gdzie kolwiek.