Czym jest OAuth 2.0?

OAuth to standard, którego aplikacje mogą używać, aby zapewnić „bezpieczny delegowany dostęp” do aplikacji klienckich. OAuth działa przez HTTPS i autoryzuje urządzenia, API, serwery i aplikacje za pomocą tokenów dostępu zamiast poświadczeń.

Protokół OAuth 2.0 został wyraźnie zaprojektowany do obsługi wielu różnych typów klientów uzyskujących dostęp do interfejsów API REST. Dotyczy to zarówno aplikacji działających na serwerach internetowych w organizacji, które wywołują chmurę, jak i aplikacji działających na urządzeniach mobilnych pracowników lub klientów. Protokół OAuth obsługuje tę różnorodność typów klientów poprzez zdefiniowanie wielu mechanizmów pobierania tokena, przy czym różne mechanizmy rozpoznają ograniczenia typu klienta.

 

Token

Tokeny dostępu to tokeny, których klient używa, aby uzyskać dostęp do serwera zasobów (API). Mają być krótkotrwałe. Myśl o nich w kategoriach godzin i minut, a nie dni i miesięcy. Nie potrzebujesz zaufanego klienta, aby uzyskać token dostępu. Możesz uzyskać tokeny dostępu za pomocą klientów publicznych. Mają one na celu optymalizację kwestii związanych ze skalowaniem internetu. Ponieważ te tokeny mogą być krótkotrwałe i skalowane, nie można ich cofnąć, wystarczy poczekać, aż wygaśnie.

Drugim tokenem jest token aktualizacji. To jest znacznie bardziej długotrwałe; dni, miesiące, lata. Można je wykorzystać do zdobycia nowych tokenów. Aby uzyskać token aktualizacji, aplikacje zwykle wymagają zaufanych klientów z uwierzytelnieniem.

Tokeny aktualizacji mogą być cofnięte. Kiedy cofasz dostęp aplikacji w pulpicie nawigacyjnym, usuwasz jej token aktualizacji. Daje to możliwość zmuszenia klientów do rotacji sekretów. Co robisz, to używasz swojego tokena aktualizacji, aby uzyskać nowe tokeny dostępu, a tokeny dostępu przechodzą przez przewód, aby uderzyć we wszystkie zasoby API. Za każdym razem, gdy aktualizujesz swój token dostępu, otrzymujesz nowy kryptograficznie podpisany token. Rotacja kluczy jest wbudowana w system.

 

 

Jak to działa?

  1. Użytkownik (zwany też właścicielem zasobu) przekazuje klientowi swoją nazwę użytkownika i hasło.
  2. Klient składa żądanie tokena do serwera autoryzacji, podając nazwę użytkownika i hasło.
  3. Serwer autoryzacji sprawdza dane uwierzytelniające i w odpowiedzi przekazuje klientowi token dostępu i opcjonalnie token aktualizacji, jeśli są one poprawne.
  4. W żądaniach do serwera REST (aby uzyskać dane takie jak osoby, przedmioty …), klient dostarcza token dostępu.
  5. Gdy usługa REST przetwarza żądanie, waliduje token dostępu, wywołując punkt końcowy walidacji tokena serwera autoryzacji lub walidując token lokalnie (np. jeśli token dostępu jest JWT).
  6. Jeśli token dostępu jest prawidłowy, nie wygasł i ma prawidłowe uprawnienia (znane również jako „zakresy”), usługa REST zwraca dane, których zażądał klient.
  7. Jeśli klient stwierdzi, że access_token wygasł (np. dlatego, że serwer REST zwrócił błąd), prosi serwer autoryzacji o kolejny token dostępu z wykorzystaniem tokenu odświeżającego, używając tzw. grantu/flow na token odświeżający.