Jak skonfigurować i używać uwierzytelniania OAuth za pomocą WP REST API

Jeśli chodzi o WordPress REST API, OAuth jest najpopularniejszym dostawcą obsługi uwierzytelniania.

Gdy uwierzytelnianie OAuth jest wdrożone, użytkownicy najpierw logują się za pomocą formularza logowania WordPress, który jest używany w witrynie. jednak ten login upoważnia również klientów do obsługi żądań w ich imieniu, a wszystkie kolejne żądania są sprawdzane za pomocą tokenów OAuth. Te tokeny są również używane do zarządzania wszystkimi żądaniami dostępu do interfejsu API. Ten dostęp można było w każdej chwili cofnąć.

Być może najważniejszym zastosowaniem procesu uwierzytelniania OAuth jest bezpieczny proces obsługi żądań REST API bez ujawniania poświadczeń użytkowników. Jest to szczególnie ważne w przypadku serwerów produkcyjnych, gdzie często wymieniane są dane uwierzytelniające. W takich scenariuszach uwierzytelnianie OAuth służy do zapewnienia bezpiecznej procedury obsługi częstych żądań poświadczeń logowania.

Tradycyjne uwierzytelnianie a uwierzytelnianie OAuth

Aby zrozumieć znaczenie uwierzytelniania OAuth, ważne jest zrozumienie modelu uwierzytelniania tradycyjnego i OAuth.

W tradycyjnym modelu uwierzytelniania istnieją dwie kluczowe jednostki; Klient i dostawca zasobów/usług. Klientem może być aplikacja internetowa, usługa lub użytkownik, podczas gdy dostawca zasobów/usług ma żądane zasoby lub usługi w środowisku z ograniczonym dostępem.

Gdy Klient wymaga określonego zasobu, uwierzytelnia się u Dostawcy Zasobów poprzez podanie odpowiednich poświadczeń. Chociaż jest to prosty proces, istnieje również ogromne ryzyko naruszenia bezpieczeństwa.

Z kolei model uwierzytelniania OAuth jest nieco bardziej złożony z trzema jednostkami; Klient działający w imieniu użytkownika, Użytkownik wymagający dostępu do zasobu oraz Serwer utrzymujący zasób.

Ponieważ istnieją trzy jednostki, proces ten jest znany jako uwierzytelnianie trójetapowe. Jednak w przypadku, gdy Klient i Użytkownik są tymi samymi podmiotami, proces uwierzytelnienia staje się uwierzytelnianiem dwuetapowym.

Przepływ pracy uwierzytelniania OAuth

• Klient żąda autoryzacji Użytkownika na dostęp do Serwera .
• W przypadku uznania żądania przez Użytkownika , Klient otrzymuje prawo do dalszego postępowania.
• Klient przedstawia swoją tożsamość i upoważnienie od Klienta do Serwera Autoryzacyjnego (API) i żąda tokena.
• W przypadku pomyślnej weryfikacji tożsamości i upoważnienia Serwer Autoryzacyjny (API) wystawia Klientowi token dostępu. W tym momencie uwierzytelnianie jest zakończone.
• Następnie Klient zbliża się do Serwera, aby zażądać określonego zasobu. W tym momencie Klient wysyła również token dostępu do
• Jeśli token dostępu jest zweryfikowany, serwer udziela dostępu do żądanego zasobu.

Klient jest inicjatorem podpisanego wniosku o token żądania. To żądanie jest również znane jako Tymczasowe Poświadczenia. Żądanie jest wysyłane do odpowiedniego identyfikatora URI punktu końcowego. To żądanie zawiera kilka ważnych parametrów:

• oauth_consumer_key : Ten klucz identyfikuje aplikację, z której pochodzi żądanie.
• oauth_timestamp : Serwery używają tego znacznika czasu do optymalizacji przechowywania jednorazowych przedmiotów.
• oauth_nonce : jest to unikalny token generowany przez aplikację dla każdego indywidualnego żądania.
• oauth_signature : ta ważna część żądania API to skrót wszystkich składników żądania i niektórych wartości OAuth.
• oauth_signature_method : Wtyczka OAuth oferuje pojedynczą metodę podpisu: HMAC-SHA1.
• oath_callback : adres URL, na który użytkownik jest przekierowywany po autoryzacji. Żądanie jest weryfikowane i wystawiany jest Request Token z następującymi parametrami.
• oauth_token : To jest token aplikacji, który jest usuwany z odpowiedzi serwera autoryzacji. Ten token jest następnie wysyłany do serwera API.
• oauth_token_secret : To jest podobne do hasła użytkownika. Żądanie jest następnie autoryzowane przez Klienta. W tym celu tworzony jest identyfikator URI żądania i do identyfikatora URI punktu końcowego autoryzacji serwera dodawany jest token_oauth . Użytkownik autoryzuje wysłanie tego żądania poprzez podanie odpowiednich danych uwierzytelniających.

W przypadku, gdy w pierwszym kroku dostępny jest identyfikator oauth_callback URI, serwer przekierowuje do identyfikatora URI z następującymi parametrami dodanymi do ciągu zapytania:

• oauth_token : masz już token.
• oauth_verifier : weryfikuje tożsamość właściciela zasobu z klientem.

Jeśli identyfikator URI oauth_callback nie został podany w pierwszym kroku, serwer wysyła wartość oauth_verifier, aby właściciel zasobu mógł ręcznie poinformować klienta.

Po otrzymaniu oauth_verfier klient żąda od serwera poświadczeń tokena. Przybiera to formę żądania do identyfikatora URI punktu końcowego żądania tokenu. To żądanie zawiera następujące parametry:

• token_autoryzacji
• oauth_verfier
• oauth_consumer_key
• oauth_signature
• oauth_signature_method
• oauth_nonce
• wersja_autorska

Instalacja uwierzytelniania OAuth

W kontekście WordPress uwierzytelnianie OAuth jest implementowane przez zainstalowanie interfejsu API uwierzytelniania OAuth dla WordPress. Jest to oparte na specyfikacjach OAuth 1.0a i faktycznie rozszerza te specyfikacje o dodatkowy parametr wp_scope. Ten parametr jest wysyłany do punktu końcowego tymczasowego żądania poświadczeń .

Wtyczka jest dostępna na Github od zespołu WP REST API. Obecnie obsługiwane są wersje 4.4 i nowsze.

Proces klonowania wtyczki rozpocznę od przejścia do katalogu /wp-content/plugins/ :

 klon git https://github.com/WP-API/OAuth1.git 

Po zakończeniu pobierania aktywuj wtyczkę przez WordPress CLI:

 Wtyczka wp aktywuje OAuth1

Jeśli nie chcesz korzystać z WordPress CLI, możesz przejść do WordPress Admin >> Wtyczki i aktywować wtyczkę z menu. Alternatywnie możesz go również aktywować, przechodząc w przeglądarce do sekcji wtyczek administratora WordPress, jeśli nie chcesz korzystać z interfejsu WP CLI.

Ocena dostępności interfejsu API OAuth

Zanim zainicjuję uzgadnianie OAuth, najpierw sprawdzę, czy API jest włączone na serwerze. Odbywa się to poprzez wysłanie prostego żądania GET do /wp-json/ punkt końcowy, a następnie analizowanie odpowiedzi wysłanej przez serwer.

 POBIERZ http://Server-Dev/wp-json/

Spowoduje to zwrócenie odpowiedzi JSON w następujący sposób:

Skupiam się tutaj na wartości oauth1 w wartości właściwości uwierzytelniania . Ten obiekt ma zdefiniowane następujące właściwości:

• request : punkt końcowy tymczasowego żądania danych uwierzytelniających
• zezwolić na: punkt końcowy zasobów Właściciel Authorization
• dostęp : punkt końcowy żądania tokena
• wersja : używana wersja OAuth

Jeśli interfejs API OAuth nie jest włączony dla witryny, odpowiedź serwera będzie zawierać pustą wartość właściwości autoryzacji .

Tworzenie i zarządzanie aplikacjami

Pierwszym krokiem jest upewnienie się, że wtyczka OAuth1.0 jest poprawnie zainstalowana i aktywowana.

Następnie mogę tworzyć i zarządzać aplikacjami, przechodząc do administratora WordPressa >> Użytkownicy >> Aplikacje.

Na tej stronie Zarejestrowane aplikacje zarejestruję nową aplikację, klikając przycisk Dodaj nowy , a następnie wypełniając następujące trzy pola:

1. Nazwa Klienta: Nazwa Klienta, która pojawia się w sekcji Autoryzowane aplikacje oraz podczas procesu autoryzacji.
2. Opis : Opcjonalny opis Klienta.
3. Adres URL wywołania zwrotnego : adres URL wywołania zwrotnego jest używany podczas generowania tymczasowych poświadczeń.

Po utworzeniu przez kliknięcie przycisku Zapisz klienta , parametry klucza klienta i klucza klienta pojawią się na dole strony dla tego konkretnego klienta.

Teraz sklonuję repozytorium na kliencie, uruchamiając następujące polecenie:

 klon git https://github.com/WP-API/client-cli 

Teraz przejdź do sklonowanego katalogu i zainstaluj zależności pakietów za pomocą Composera:

 cd klient-cli
instalacja kompozytora

Jeśli wszystko pójdzie dobrze, wiersz poleceń powinien pokazywać coś podobnego do następującego:

Klient CLI do generowania poświadczeń OAuth

Aby rozpocząć proces autoryzacji OAuth, najpierw uzyskam z serwera następujące parametry:

• oauth_consumer_key
• oauth_consumer_secret

Zostanie to wygenerowane przez terminal i uruchomienie następującego polecenia WordPress CLI:

 wp oauth1 dodaj

Klucz i tajny klucz to oauth_consumer_key i odpowiednio oauth_consumer_secret .

Teraz muszę połączyć klienta z witryną WordPress. Na kliencie przejdź do katalogu client-cli (wcześniej sklonowanego) i uruchom następujące polecenie:

 wp --require=client.php api oauth1 connect http://Server-Dev/ --key=<Twój klucz tutaj> --secret=<Twój klucz tajny>

Zastąp adres URL, klucz i sekret w powyższym poleceniu. Dane wyjściowe powinny wyglądać następująco:

 wp --require=client.php api oauth1 connect http://twój-serwer/wordpress-api/ --key=<twój klucz> --secret=<twój tajny kod>
Otwórz w przeglądarce: http://your-server/wordpress-api/oauth1/authorize?oauth_token=<your-token>
Wpisz kod weryfikacyjny:

Przejdź do adresu URL podanego przez serwer i uwierzytelnij się, klikając przycisk Autoryzuj :

Otrzymasz token weryfikacyjny (lub oauth_verifier) ​​na następnym ekranie:

Skopiuj weryfikator i wklej go do terminala. Otrzymasz klucz i klucz tajny , które w zasadzie są odpowiednio oauth_token i oauth_token_secret :

Klient HTTP do generowania poświadczeń OAuth

Ponieważ wtyczka serwera OAuth 1.0a jest zgodna ze standardowym trójetapowym przepływem, generowanie poświadczeń OAuth obejmuje następujące kroki:

• Pozyskiwanie tymczasowych poświadczeń
• Uprawnienia użytkowników
• Wymiana tokenów

Pozyskiwanie tymczasowych poświadczeń

Wyślę żądanie POST do /oauth1/request endpoint, aby uzyskać tymczasowe poświadczenia. Należy zauważyć, że ten punkt końcowy powinien być automatycznie wykrywalny, ponieważ serwer może samodzielnie zastąpić trasę.

Żądanie POST powinno zawierać parametry oauth_consumer_secret uzyskane podczas rejestracji konsumenta dla aplikacji. Żądanie może również zawierać parametr oauth_callback i ten adres URL wywołania zwrotnego powinien być zgodny ze schematem, hostem, portem i ścieżką adresu URL wywołania zwrotnego, który został podany podczas rejestracji aplikacji.

Oprócz parametrów oauth_consumer_key i oauth_consumer_secret żądanie powinno również zawierać parametry oauth_signature i oauth_signature_method .

Podczas korzystania z Postmana oauth_signature jest generowany automatycznie. Muszę tylko wspomnieć o parametrze oauth_signature_method . W tej chwili wtyczka serwera OAuth obsługuje tylko metodę podpisu HMAC-SHA1.

Teraz skonfiguruję Postmana, aby wysyłał żądanie POST do punktu końcowego poświadczeń tokena tymczasowego. Następnie na karcie Autoryzacja wybierz z menu opcję OAuth 1.0 . Wypełnij pola Klucz konsumenta i Klucz konsumenta wartościami podanymi przez konsumenta. Na koniec sprawdź, czy opcja Metoda podpisu jest ustawiona na HMAC-SHA1 .

Autoryzacja użytkownika

Na etapie autoryzacji użytkownika otworzę punkt końcowy autoryzacji właściciela zasobu w przeglądarce i przekażę oauth_token oraz oauth_token_secret uzyskane w poprzednim kroku jako parametry zapytania:

 http://server-dev/oauth1/authorize?oauth_token=<token_tutaj>&oauth_token_secret=<tajemniczy_tutaj> 

Autoryzuj aplikację, klikając przycisk Autoryzuj . Na następnym ekranie pojawi się token weryfikacyjny. Ten token będzie teraz działał jako token oauth_verifier w następnym kroku.

Po autoryzacji klienta przez użytkownika aplikacja pojawi się w sekcji Autoryzowane aplikacje na stronie Użytkownicy > Twój profil .

Wymiana tokenów

Korzystając ponownie z opcji OAuth 1.0 na karcie Autoryzacja , wypełnij pola Klucz konsumenta i Klucz konsumenta wartościami podanymi przez konsumenta. W polach Token i Token Secret wstaw wartości parametrów oauth_token i oauth_token_secret (poświadczenia tymczasowe).

Ponieważ mogę również przekazać parametry w adresie URL jako parametry zapytania, dołącz parametr oauth_verifier do adresu URL w następujący sposób:

 http://server-dev/oauth1/access?oauth_verifier=<oauth_verifier_value>

Po skonfigurowaniu wszystkich parametrów wyślij żądanie, klikając przycisk Wyślij . Jeśli wszystko pójdzie dobrze, serwer zwróci kod statusu 200 – OK wraz z treścią odpowiedzi zawierającą parametry oauth_token i o auth_token_secret .

 oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>

W tym momencie zdobyte wcześniej tymczasowe żetony są odrzucane i nie można ich już używać.

Nowe parametry oauth_token i oauth_token_secret to poświadczenia OAuth, których można używać w kliencie do generowania uwierzytelnionych żądań.

Wysyłanie testowego żądania uwierzytelnionego

Teraz, gdy mam poświadczenia tokena, wyślę żądanie testowe do serwera za pomocą listonosza. Żądanie będzie wymagało następujących parametrów:

Zanim zaczniesz, będziesz potrzebować następujących rzeczy:

• oauth_consumer_key
• oauth_consumer_secret
• token_autoryzacji
• oauth_token_secret

Wybierz OAuth 1.0 z menu rozwijanego na karcie Autoryzacja w aplikacji Postman.

Po wypełnieniu wszystkich pól kliknij przycisk Prośba o aktualizację . Zaznacz opcję Dodaj parametry do nagłówka , aby wysłać parametry w nagłówku żądania zamiast dołączania do ciągu zapytania.

Jeśli żądanie się powiedzie, serwer wyśle ​​kod statusu 200 – OK .

Podsumowanie!

W tym samouczku omówiłem, jak skonfigurować API uwierzytelniania OAuth dla WordPress na serwerze i jak używać klienta HTTP do uzyskiwania poświadczeń tokena. Jeśli odkryjesz problem w kodzie lub chcesz dodać do dyskusji, zostaw komentarz poniżej.