Cześć! Macie jakieś sprawdzone podejście/sposób/nugeta/cokolwiek do kluczy API? Muszę zabezpieczyć API różnymi kluczami, każdy klucz będzie miał określony poziom dostępu (lista API które może używać). Kluczy może być wiele i każdy ma inny poziom dostępu. Coś ktoś? :D
@Slodkie_Mango_Z_Ananasem: To bardziej nie .net tylko kwestia DevOpsowa. Podmieniasz w appsettings.json klucz na właściwy z jakiegoś vaulta podczas deploymentu.
@Slodkie_Mango_Z_Ananasem: PASETO + sprawdzanie ważności tokenu w DB. Ewentualnie generujesz losowy string i to jest token, a przy każdym zapytaniu robisz request do DB (to drugie jeśli wymagana jest możliwość zmiany uprawnień tokena, który już istnieje).
@rationalistic: może i tak, ale devopsa u mnie nie ma, seniora nawet nie ma (XD) a kazali mi zrobić publiczne API zabezpieczone kluczami. I nie wiem za bardzo jak je przechowywać. Hardkodowanie i porównywanie headerów w kontrolerze nie wydaje mi się dobre, ale nie wiem jak inaczej to zrobić
@Hauleth: czy dobrze rozumiem, że generuję losowy string jako token po stronie serwera, wysyłam go do klienta, klient mi odpowiada za jego pomocą, sprawdzam uprawnienia i procesuję? To chyba jest ok jak ma się logowanie usera, problem taki że mam z góry narzucone, że nie ma logowania użytkownika, jest URL z parametrami (guid user, guid czegoś tam) i na tej podstawie znam usera. Ładuje się strona która pobiera dane z serwera
@passage: niestety nie mam jakby kont użytkowników, więc takie coś nie zadziała. Potrzebuję po prostu ograniczyć zapytania, że ktoś randomowo zeskanuje API i coś wyśle. Tylko nie wiem jak zabezpieczyć i przesłać API po stronie FE (appka angularowa) i jak go przechowywać w BE. Mam to narzucone z góry, ale JAK to zrobić to już nikt mi nie mówi
@Slodkie_Mango_Z_Ananasem: możesz po stronie BE wygenerować TOKEN JWT. Wtedy nie musisz go trzymać po stronie BE tylko sprawdzać czy jest poprawny (przy pomocy security key). Ustawić możesz też czas życia tokenu np 24g. W tokenie możesz zapisać swoje dane (PAYLOAD JWT) czy np jakiś znacznik mówiący, że ten token ma dostęp do tego i tego api. Po stronie FE trzymasz go np w local storage. A jak chcesz się wylogować to
możesz po stronie BE wygenerować TOKEN JWT. Wtedy nie musisz go trzymać po stronie BE tylko sprawdzać czy jest poprawny (przy pomocy security key)
@passage: chyba, że chcesz mieć możliwość anulowania takiego tokenu w czasie jego życia. IMHO jeśli JWT żyje dłużej niż 1h, to znaczy, że coś jest nie tak (tak samo jeśli ma istnieć refresh token).
czy dobrze rozumiem, że generuję losowy string jako token po stronie serwera, wysyłam
Tak aby API wymagało Bearer tokena w każdym żądaniu. Na podstawie tego tokena będziesz sprawdzać czy użytkownik ma odpowiednie uprawnienia używając (Role/Claim/Policy)-Based Authorization.
IMHO jeśli JWT żyje dłużej niż 1h, to znaczy, że coś jest nie tak (tak samo jeśli ma istnieć refresh token).
@Hauleth: wszystko zależy od zastosowania. Do autoryzacji płatności czy giełdzie walut warto mieć jednorazowe tokeny o czasie życia pojedynczych sekund. Ale np. taki facebook do autoryzacji np aplikacji mobilnych generuje tokeny o czasie życia 60 dni.
#csharp #dotnet #dotnetcore #programowanie
https://en.wikipedia.org/wiki/Role-based_access_control
https://en.wikipedia.org/wiki/Attribute-based_access_control
uprawnienia przesyłaj w payloadzie klucza/tokena lub trzymaj w bazie i sprawdzaj przy pomocy id usera
https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbiBLb3dhbHNraSIsImFjY2VzcyI6WyIvYXBpL2VuZHBvaW50MSIsIi9hcGkvZW5kcG9pbnQyIiwiL2FwaS9lbmRwb2ludDMiXSwiaWF0IjoxNTkzNjk3NDIyLCJleHAiOjE1OTM3MDEwMjJ9.As9ZSxOIb3zDWi1HygTw63RSpZbtOX8huxY4PvYhkPY
@passage: chyba, że chcesz mieć możliwość anulowania takiego tokenu w czasie jego życia. IMHO jeśli JWT żyje dłużej niż 1h, to znaczy, że coś jest nie tak (tak samo jeśli ma istnieć refresh token).
Zaimplementuj JWT z lub bez Identity.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-3.1
(jest też masa innych tutoriali w necie)
Tak aby API wymagało Bearer tokena w każdym żądaniu.
Na podstawie tego tokena będziesz sprawdzać czy użytkownik ma odpowiednie uprawnienia używając (Role/Claim/Policy)-Based Authorization.
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles?view=aspnetcore-3.1
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims?view=aspnetcore-3.1
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-3.1
@Hauleth: wszystko zależy od zastosowania. Do autoryzacji płatności czy giełdzie walut warto mieć jednorazowe tokeny o czasie życia pojedynczych sekund. Ale np. taki facebook do autoryzacji np aplikacji mobilnych generuje tokeny o czasie życia 60 dni.
@Hektorrr: wydaje się to ok, myślę że starczy na moje zastosowanie. Dziękuję ślicznie!
@passage: poczytałam trochę o tym jak wysłałeś, tak jak napisałam do @Hektorrr to to zadziała u mnie. Również dziękuję ślicznie!