Używamy grantu username-password, aby połączyć naszego klienta JS z naszym serwerem REST. W pewnym sensie token zwracany przez oauth / token jest naszą sesją, ponieważ umożliwia dostęp do zaplecza przez ograniczony czas.

Chcielibyśmy odświeżyć tę sesję / token za każdym razem, gdy wykonamy żądanie do zaplecza za pomocą tokena.

Wiem, że serwer wysyła ten token odświeżania i mogę go użyć do odświeżenia tokena po jego wygaśnięciu.

Chodzi o to, że nie chcę, aby klient odpowiadał za wygasły wyjątek tokenów catch i ponownie uwierzytelniał się lub planował odświeżenie przed wygaśnięciem tokena. Chcę, aby token odświeżył się, dopóki nie będzie używany przez ograniczony czas - tak jak sesja. (Nie chciałbym również, aby wysyłało żądanie odświeżania z każdym żądaniem „danych”, chociaż myślę, że pamiętam czytanie, token odświeżania jest ważny tylko raz…?!)

Czy jest jakiś sposób, aby to zrobić wiosną bezpieczeństwa, czy będę musiał zbudować jakąś niestandardową implementację sklepu z tokenami lub jakiejkolwiek części, którą wybiorę?

Ponieważ naprawdę nie mogę znaleźć odpowiedzi (stąd post), myślę: może nie jest to rozsądne, ale nie wiem, dlaczego. Jeśli mogę ukraść żeton, mogę również ukraść żeton odświeżania. Więc chyba nie widzę sensu w posiadaniu żetonu odświeżania na pierwszym miejscu.

EDYTOWAĆ

W odpowiedzi na odpowiedź Luke'a Taylora wyjaśnię nasz przypadek użycia.

Mamy serwer REST, który przechowuje dane aplikacji jak osoby. ale także zapewnia dostęp do naszego zarządzania treścią i pozwala klientom na publikowanie na Facebooku. Obejmuje on logikę aplikacji i przechowywanie danychMamy już w pełni rozwiniętą aplikację kliencką, która ma własną warstwę zabezpieczeń i uzyskuje dostęp do danych na naszym serwerze REST za pośrednictwem przepływu poświadczeń klienta. Kto może robić to, co jest postanowione po stronie klientaMamy kilka średnich i małych aplikacji, takich jak aplikacja kontaktowa na Facebooku, które uzyskują dostęp do danych na serwerze REST również przy użyciu poświadczeń klientaObecnie opracowujemy aplikację kliencką wykorzystującą tylko javascript, która będzie uzyskiwać dostęp do warstwy REST, aby wykonywać wszystkie czynności, które wykonuje duża aplikacja kliencka, ale także musi zapewniać środki do uwierzytelniania poszczególnych użytkowników i zezwalać na wynajem wielu obiektów. Dlatego ta nowa aplikacja kliencka używa przyznania nazwy użytkownika i hasła do uwierzytelnienia i zabezpieczenia na poziomie metody w celu autoryzacji użytkowników

Mamy więc serwer REST, który musi zapewnić pełny dostęp do naszej zaufanej aplikacji, która wykonuje własne zabezpieczenia i ten sam serwer musi zapewniać dostęp użytkownikom naszej nowej aplikacji klienckiej javascript obsługującej wiele podmiotów. W produkcji będziemy mieli kilka serwerów REST, każdy z własną bazą danych, ale rdzeń będzie zawsze taki sam, więc teoretycznie jeden serwer powinien być w stanie obsłużyć wszystkie.