Posted by Na starcie rozróżnijmy te dwie rzeczy. Uwierzytelnianie ma na celu zweryfikowanie czy tożsamość użytkownika jest prawidłowa, tzn. jest on tym za kogo się podaje. Natomiast autoryzacja dotyczy dostępu do danego zasobu (czy użytkownik może pobrać ten zasób albo wykonać odpowiednią operację).
ApiKey
Jest to po prostu ciąg alfanumeryczny, za pomocą którego możemy komunikować się z jakimś API i uzyskujemy dzięki temu dostęp do danego zasobu. Jest to najczęściej metoda jednocześnie uwierzytelniania i autoryzacji. Dobre standardy opisujące prawidłowe przetrzymywanie i zarządzanie API Key’ami:
- Klucz musi być ciągiem znaków najlepiej alfanumerycznych (możliwe są znaki specjalne) i być w miarę długi, aby nie dało się go łatwo odszyfrować.
- Klucz musi być przetrzymywany w bazie danych jako zahaszowany, aby przy jakimkolwiek wycieku nie dało się ich użyć (jak hasło użytkownika).
- Powinien posiadać prefix, który nie będzie hashowany, aby umożliwić późniejsze zarządzanie i odróżnianie użytkowników w systemie. Prefix może być oddzielony np. kropką od reszty ciągu.
- Nie dawać jednemu kluczowi całej „mocy”. Najlepiej jakby dany klucz umożliwiał tylko dostęp do ograniczonych zasobów i akcji (te, które są w danej chwili potrzebne).
- Ustawienie limitu operacji per klucz. Uniemożliwi to włamywaczowi wywołanie sporego zamieszania w systemie, gdy wykradnie jakiś klucz. Limit może się zerować np. każdego dnia.
Takie klucze najczęściej przechowujemy w bazie lub mogą być to klucze bezstanowe typu JWT o długim czasie wygasania.
Federated identity (FIM) vs Single Sign On (SSO)
SSO jest rodzajem uwierzytelniania, w którym używamy tych samych danych w ramach przynależności do danej grupy lub sieci. W takim rozwiązaniu serwer autoryzacyjny jest centralizowany. Zależnie od implementacji sesja może być przekazywana (bez potrzeby ponownego logowania) bądź też użytkownik będzie musiał się zalogować ponownie w każdej aplikacji, ale używając do tego tych samych danych.
Natomiast FIM polega na tym, że uwierzytelnia nas zewnętrzny dostawca (Identity Provider) jak np. Facebook czy Google. Dzięki niemu możemy uwierzytelnić użytkownika w naszej aplikacji, bez potrzeby trzymania haseł w naszej bazie.
Frameworks
OAuth 2.0 (Autoryzacja)
Dostępnych jest kilka flow autoryzacji:
- Client credentials Flow
- Authorization Code Flow
- Refresh Token Flow
- Resource Owner Code Flow
- Inplict Flow
Client Credentials Flow
Jest to najprostsze flow w OAuth2 i najlepsze rozwiązanie do komunikacji Machine To Machine (M2M), gdzie nie ma potrzeby częstego odświeżania tokenu oraz uwierzytelniania. Nie występuje tam również część z RedirectUrl, co sprawia, że pozyskanie tokenu sprowadza się do jednego zapytania na adres /oauth2/token, gdzie klient podaje swoje dane (id oraz secret).
W tym przypadku długość wygasania tokenu jest dłuższa (1h lub więcej), bo nie ma tu obawy o wykradnięcie go za pomocą ataków na stronę klienta, gdyż przeglądarka nie bierze czynnego udziału w tej komunikacji.
Resource Owner Password Flow
Jest ono bardzo podobne do poprzedniego (Client Credentials), z tym że całą akcję inicjalizuje użytkownik, które wpisuje swój login i hasło do aplikacji. Klient autoryzuje się w imieniu użytkonika wykonując zapytanie na endpoint /token. W odpowiedzi (jeżeli wszystko poszło pozytywnie) dostanie access_token.
To flow przestanie istnieć razem z wyjściem OAuth2.1. W głównym założeniu było ono stworzone, aby umożliwić łatwą migrację z innych sposobów autoryzacji właśnie na OAuth2. Głównym niebezpieczeństwem w tym flow jest fakt, że użytkownik podaje swoje dane (login i hasło) na stronie klienta i to klient dopiero się autoryzuje w imieniu użytkownika na serwerze autoryzacyjnym. Czyli poufne dane przechodzą przez dodatkowy podmiot, co może się wiązać z nadużyciami oraz wyciekami.
Authorization Code Flow
Jest to najlepsze flow, jeżeli chodzi o autoryzacje użytkowników na naszej stronie. Kiedy użytkownik chce się zalogować klika przycisk „zaloguj” i jest przekierowywany przez naszą aplikacje do serwera autoryzacyjnego, gdzie podaje swoje dane (login i hasło). Potem zostaje wygenerowany kod autoryzacyjny, który jest przesyłany na redirectUrl, który podaliśmy w 1 zapytaniu. Następnie razem z tym kodem i (client_id oraz client_secret) wykonujemy zapytanie pod endpoint /oauth2/token w celu uzyskania klucza (jeżeli jest to JWT to najczęsciej będzie zwracany jeszcze refresh token, gdyż główny klucz będzie miał krótką wartość).
Refresh token flow
Jeżeli typ tokenu, jaki otrzymaliśmy to JWT i dodatkowo został nam zwrócony jeszcze refrest token to, będziemy mogli skorzystać z tego flow. Chodzi tutaj głównie o pozyskanie nowego tokenu autoryzacyjnego. Musimy uderzyć pod endpoint /token z client_id, client_secret, grant_type oznaczyć jako refresh_token oraz dołączyć otrzymany wczesniej klucz odświeżenia. W odpowiedzi powinniśmy otrzymać nowy access token oraz refresh_token.
Implict flow
Jest to flow dla aplikacji z otwartym kodem źródłowym, które nie mają jak przechować client_id oraz client_secret, a chcą zrealizować logowanie. Użytkownik klika przycisk logowania, który jest odbierany przez aplikacje i z odpowiednimi parametrami wysyłany na serwer autoryzacyjne, gdzie użytkownik zostaje przekierowany do formularza logowania. W przypadku pozytywnej weryfikacji zostaje zwrócony id_token, z którym użytkownik może się autoryzować w naszej aplikacji.
Open ID Connect (Uwierzytelnianie oraz autoryzacja)
https://auth0.com/docs/protocols/openid-connect-protocol
OIDC jest rozszerzeniem OAuth 2.0 o funkcje uwierzytelniania. Więc jeżeli jakaś witryna wspiera OIDC przez Google to jest mozliwe zalogowanie się na nią za pomocą konta Google. Zostaniemy przekierowani na stronę logowania na domenie google.com i po podaniu loginu i hasła powinniśmy zostać zalogowani do aplikacji.
SAML – Security Assertion Markup Language
W SAML chodzi o to samo co w OAuth i OIDC, aby móc logować się na różne witryny jednym kontem. Najważniejszym zastosowaniem tego protokołu jest SSO, dzięki czemu raz zalogowani nie będziemy musieli powtarzać tego dla aplikacji przynależnych do określonej grupy które wspierają ten rodzaj uwierzytelniania.
