[pepepanpatryk]

Cześć, może ktoś podrzuci jakimś pomysłem :)

Jak powinno wyglądać uwierzytelnianie i autoryzacja w kontekście mkroserisów?

Mam aplikację składającą się z kilku różnych serwisów. Do tego oczywiście warstwa prezentacyjna.
Macie jakieś przykłady jak np. powinien wyglądać cały flow w takiej architekturze?
Może ktoś z własnego doświadczenia podrzuci jakąś informację :)

#programowanie #mikroserwisy #csharp

[Koliat]

@pepepanpatryk: w sensie chodzi Ci o providera Identity czy o sam kod?

[lkp0]

@pepepanpatryk: Może token JWT?

[P.....s]

@pepepanpatryk: robisz serwis odpowiadający za wydawanie tokenów i ich autoryzacje

[pepepanpatryk]

@Koliat: @lkp0: Bardziej chodzi mi tutaj o to jak spiąć to właśnie z providerem. Kodu nie potrzebuje. Czytałem trochę o tym i trochę zastanawia mnie jedna rzecz.
Aktualnie właśnie mam swój serwis odpowiedzialny za wydawanie tokenów.
Serwis ten udostępnia publicznie politykę dotyczącą walidacji JWT, tj. typ klucza, algorytm, oraz klucz publiczny -> korzystam z RSA. Wszystko jest zrobione automatycznie przy wykorzystaniu biblioteki JWT Bearer od Microsoftu.

Trochę trudno wytłumaczyć o

[Dworki]

@pepepanpatryk: Zwracasz 401 z api, a we froncie masz http interceptor, który w przypadku 401, wywoła przekierowanie do logowania.

[zakopiak]

W każdym z tych kontrolerów będę musiał napisać metody do pobrania tokena, oraz zwrócenia go do klienta końcowego tj. aplikacji frontowej.

@pepepanpatryk: dlatego nie powinieneś robić żadnych przekierowań. To aplikacja frontowa jest odpowiedzialna za uzyskanie jwt i dostarczenie go z requestem do API.

Jak nie ma tokena lub jest nieważny to przecież aplikacja frontowa o tym wie i może sama to obsłużyć.

Jeśli obsługujesz np unieważnienie tokena na serwerze autoryzacyjnym, czyli

[pepepanpatryk]

@zakopiak: W tym przypadku jak mówisz wygląda to jak wersja implicit flow.
Jak wygląda w takim razie wykorzystanie wersji authorization code, lub hybrid? Do jakich zastosowań one pasują?

[zakopiak]

@pepepanpatryk: Tutaj masz w miarę fajnie wyjaśnione wszystkie 4 typy grantów zdefiniowane w standardzie OAuth2: http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/ Oczywiście można implementować też customowe.

Tak czy inaczej te wszystkie flow'y dotyczą jedynie komunikacji pomiędzy aplikacją w której robisz autentykację, czyli client (u Ciebie appka frontowa), a serwerem autoryzacyjnym (serwis OAuth na przykład).
To w ogóle nie ma związku z usługami, które wymagają tokena. To jest jakby obok, po prostu token ma być dostarczony w

[pepepanpatryk]

@zakopiak:
Rozumiem. Niemniej jednak trochę mi ta wersja nie leży a to np. dlatego:

"Attention! This type of authorization should only be used if no other type of authorization is available. Indeed, it is the least secure because the access token is exposed (and therefore vulnerable) on the client side."

Czy w przypadku mikroserwisów działających jako api dla aplikacji frontowej jest to jedyne sensowne rozwiązanie?

[zakopiak]

@pepepanpatryk: Jaka wersja Ci nie leży? Nie bardzo rozumiem.

Mam wrażenie, że chcesz na siłę wpakować autentykację w miejsca gdzie jej nie powinno być.

Masz trzy strefy:
Client - appka frontowa
Auth Serv - czyli serwer autoryzacyjny
Resource Server - dowolne inne usługi, które wymagają tokena, u Ciebie to będzie jakieś tam API.

Wszystkie elementy tej infrastruktury należą do Ciebie, także jest zaufanie pomiędzy nimi, więc możesz zastosować standardowo password grant,