Spis treściKliknij link, aby przejść do wybranego miejsca
Ta treść została automatycznie przetłumaczona z ukraińskiego.
OAuth 1
OAuth 1 został opracowany na początku lat 2000 jako sposób bezpiecznego dostępu aplikacji zewnętrznych do zasobów użytkownika bez przekazywania hasła. Główna idea polegała na tym, że zewnętrzna usługa mogła wysyłać zapytania w imieniu użytkownika, ale każde zapytanie było podpisywane kryptograficznie, aby zapewnić, że nie zostało zmienione i pochodzi od autoryzowanego klienta.
Cecha OAuth 1:
- Kryptograficzny podpis każdego zapytania (HMAC-SHA1 lub RSA-SHA1).
- Używał dwóch typów tokenów: tokena żądania do rozpoczęcia autoryzacji i tokena dostępu do zasobów.
- Mógł działać nawet bez HTTPS, ponieważ bezpieczeństwo zapewniał podpis zapytania.
- Był głównie odpowiedni dla aplikacji serwerowych i ograniczonej liczby scenariuszy autoryzacji.
OAuth 1 był aktywnie wykorzystywany w takich usługach jak Twitter API v1 lub starsze wersje LinkedIn, ale z powodu złożoności w realizacji i problemów z podpisami został stopniowo zastąpiony przez OAuth 2.
OAuth 2
OAuth 2 pojawił się w 2012 roku jako uproszczona, bardziej elastyczna i nowoczesna wersja protokołu do autoryzacji i dostępu do zasobów. Jego celem jest uproszczenie pracy programistów, umożliwienie różnym typom klientów (web, aplikacje mobilne, SPA) łatwego dostępu do zasobów użytkownika bez przekazywania hasła.
Cecha OAuth 2:
- Używa tokenów dostępu (access token) oraz opcjonalnie tokenów odświeżających (refresh token). Token dostępu jest krótkoterminowy, token odświeżający pozwala na przedłużenie sesji.
- Nie wymaga kryptograficznego podpisu zapytania - bezpieczeństwo zapewnia HTTPS.
- Obsługuje różne przepływy autoryzacji: kod autoryzacji (dla serwerowych klientów webowych), implicit (dla SPA), hasło (dla zaufanych klientów) oraz dane uwierzytelniające klienta (dla interakcji serwer-serwer).
- Znacznie łatwiejszy w realizacji i wspierany przez nowoczesne API (Google, Facebook, GitHub, Microsoft, Stripe itp.).
Kiedy co lepiej używać:
- OAuth 1: jeśli pracujesz z bardzo starymi API, które go wymagają, lub w środowisku bez HTTPS, gdzie ważna jest kryptografia na poziomie zapytania.
- OAuth 2: dla nowoczesnych aplikacji webowych i mobilnych, SPA, API, gdzie HTTPS jest gwarantowane. Również wygodny dla zewnętrznych klientów, ponieważ wspiera tokeny odświeżające i różne przepływy autoryzacji.
Porównanie OAuth 1 i OAuth 2 w praktyce
- Składność: OAuth 1 jest bardziej skomplikowany z powodu podpisów, OAuth 2 jest prostszy i bardziej elastyczny.
- Bezpieczeństwo: OAuth 1 jest bezpieczny nawet bez HTTPS, OAuth 2 wymaga HTTPS.
- Elastyczność: OAuth 1 jest ograniczony, OAuth 2 wspiera wiele przepływów autoryzacji.
- Użycie dzisiaj: OAuth 1 jest prawie nieużywany, OAuth 2 to standard dla nowoczesnych API i usług.
OAuth 1 dotyczył bezpiecznej autoryzacji bez HTTPS, OAuth 2 - elastyczności, prostoty i nowoczesnych scenariuszy dla aplikacji webowych i mobilnych.
Ten post nie ma jeszcze żadnych dodatków od autora.
