2014-12-08 20 views
6

Chciałbym użyć samodzielnie hostowanego serwera OpenID Connect (OIDC) w połączeniu z JWT jako tokena autoryzacji (token dostępu w warunkach OIDC). JWT byłby używany do ochrony usług REST, podczas gdy interfejs użytkownika jest połączeniem klasycznych i jednostronicowych aplikacji (Angular). W ten sposób warstwa REST byłby w stanie zrobić autoryzację w oparciu o bezpaństwowym JWT żeton więc żadnych dodatkowych połączeń DB są konieczne, jak opisano tutaj:OpenID Połącz z bezpaństwowymi tokenami JWT

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Dla pojedynczej aplikacji stron, OIDC niejawny Flow właściwy. Jednak widzę problem z bezpieczeństwem, gdy Implicit Flow jest używany w połączeniu z tokenami JNT bezpaństwowymi: token jest dostarczany jako fragment w adresie URL, co oznacza, że ​​nie ma sposobu na ich usunięcie (są one łatwo dostępne w historii przeglądarki) ani unieważnić ich (są bezpaństwowcami) -> nie ma możliwości wylogowania.

widzę 2 opcje, aby złagodzić to:

  1. użyć bardzo krótko znaki (max do kilku minut). Może to znacznie utrudnić użyteczność.
  2. Użyj przepływu kodu autoryzacji za pomocą AJAX. Jest to nie zgodne z OIDC, ale umożliwiłoby wylogowanie, ponieważ tokeny nie byłyby widoczne w adresie URL.

Trzecią opcją jest rezygnacja ze statusu bezstanowego tokena JWT i użycie prostych żetonów okaziciela z czekami DB.

Czy coś mi brakuje? Co byś wybrał?

Odpowiedz

1

jeden może argumentować o ryzyku fragmentów kończących się w historii przeglądarki, lecz „proste” nieprzezroczyste tokeny okaziciela będzie podlegać takim samym ograniczeniom, które można opisać za JWT tokeny

stosując przepływ kodu z AJAX jest z pewnością nie uniemożliwione przez specyfikację OpenID Connect, więc możesz użyć właśnie tego; niejawny przepływ jest jedynie zaleceniem dla klientów przeglądarek, ponieważ optymalizuje liczbę podróży w obie strony, aby uzyskać token do klienta użytkownika.

+0

Proste nieprzejrzyste tokeny na okaziciela mogą być jawnie odwołane przez użytkownika, przynajmniej teoretycznie. W rzeczywistości jest to mało prawdopodobne. –

+0

zgadzam się, ale chodziło mi tylko o to, że kończą się historią przeglądarki w taki sam sposób jak tokeny JWT, z możliwością ich ponownego wykorzystania przed ich odwołaniem (wyobraźcie sobie zamknięcie przeglądarki lub nawet awarię) –