Как настроить и использовать аутентификацию OAuth с помощью WP REST API

Когда дело доходит до WordPress REST API, OAuth является наиболее распространенным поставщиком обработки аутентификации.

Когда используется аутентификация OAuth, пользователи сначала входят в систему через форму входа в WordPress, которая используется на веб-сайте. однако этот вход в систему также разрешает клиентам обрабатывать запросы от их имени, и все последующие запросы проверяются с помощью токенов OAuth. Эти токены также используются для управления всеми запросами доступа к API. Этот доступ может быть отменен в любой момент.

Возможно, наиболее важным применением процесса аутентификации OAuth является безопасный процесс обработки запросов REST API без раскрытия учетных данных пользователей. Это особенно важно в случае производственных серверов, на которых часто происходит обмен учетными данными. В таких сценариях аутентификация OAuth используется для обеспечения безопасной процедуры обработки частых запросов учетных данных для входа.

Традиционная аутентификация по сравнению с OAuth

Чтобы понять значение аутентификации OAuth, важно понимать традиционную модель аутентификации и модель аутентификации OAuth.

В традиционной модели аутентификации есть два ключевых объекта; Клиент и поставщик ресурсов / услуг. Клиент может быть веб-приложением, службой или пользователем, в то время как поставщик ресурсов / услуг имеет желаемые ресурсы или службы в среде с ограниченным доступом.

Когда клиенту требуется конкретный ресурс, он аутентифицируется с помощью поставщика ресурсов, предоставляя соответствующие учетные данные. Хотя это простой процесс, существует также огромный риск нарушения безопасности.

Напротив, модель аутентификации OAuth немного сложнее с тремя объектами; Клиент, действующий от имени пользователя, Пользователь, которому требуется доступ к ресурсу, и Сервер, обслуживающий ресурс.

Поскольку существует три объекта, процесс известен как трехсторонняя аутентификация. Однако в случаях, когда Клиент и Пользователь являются одними и теми же объектами, процесс аутентификации становится двусторонней аутентификацией.

Рабочий процесс аутентификации OAuth

• Клиент запрашивает авторизацию Пользователя для доступа к Серверу .
• Если Пользователь удовлетворяет запрос, Клиент получает право продолжить.
• Клиент представляет свою личность и полномочия от Клиента серверу авторизации (API) и запрашивает токен.
• В случае успешной проверки личности и мандата сервер авторизации (API) выдает клиенту токен доступа. На этом аутентификация завершена.
• Затем Клиент обращается к Серверу, чтобы запросить конкретный ресурс. На этом этапе Клиент также отправляет токен доступа в
• Если токен доступа подтвержден, Сервер предоставляет доступ к запрошенному ресурсу.

Клиент отправляет подписанный запрос на токен запроса. Этот запрос также известен как временные учетные данные. Запрос отправляется на соответствующий URI конечной точки. Этот запрос состоит из нескольких важных параметров:

• oauth_consumer_key : этот ключ идентифицирует приложение, отправляющее запрос.
• oauth_timestamp : серверы используют эту временную метку для оптимизации хранения одноразовых номеров.
• oauth_nonce : это уникальный токен, генерируемый приложением для каждого отдельного запроса.
• oauth_signature : эта важная часть запроса API - это хэш всех компонентов запроса и некоторых значений OAuth.
• oauth_signature_method : плагин OAuth предлагает единственный метод подписи: HMAC-SHA1.
• oath_callback : URL-адрес, по которому пользователь перенаправляется после авторизации. Запрос проверяется, и выдается токен запроса со следующими параметрами.
• oauth_token : это токен приложения, который удаляется из ответа сервера авторизации. Затем этот токен отправляется на сервер API.
• oauth_token_secret : это похоже на пароль пользователя. Затем запрос авторизуется Клиентом. Для этого создается URI запроса и к URI конечной точки авторизации сервера добавляется oauth_token . Пользователь разрешает отправку этого запроса, предоставляя соответствующие учетные данные.

Если на первом шаге доступен URI oauth_callback , сервер перенаправляет на URI со следующими параметрами, добавленными в строку запроса:

• oauth_token : токен уже есть.
• oauth_verifier : проверяет личность владельца ресурса перед клиентом.

Если URI oauth_callback не был предоставлен на первом шаге, сервер отправляет значение oauth_verifier, чтобы владелец ресурса мог проинформировать клиента вручную.

После получения oauth_verfier клиент запрашивает у сервера учетные данные токена. Это принимает форму запроса к URI конечной точки запроса токена. Этот запрос содержит следующие параметры:

• oauth_token
• oauth_verfier
• oauth_consumer_key
• oauth_signature
• oauth_signature_method
• oauth_nonce
• oauth_version

Установка аутентификации OAuth

В контексте WordPress аутентификация OAuth реализуется путем установки API аутентификации OAuth для WordPress. Это основано на спецификациях OAuth 1.0a и фактически расширяет эти спецификации дополнительным параметром wp_scope. Этот параметр отправляется в конечную точку запроса временных учетных данных .

Плагин доступен на Github командой WP REST API. На данный момент поддерживаются версии 4.4 и выше.

Я начну процесс клонирования плагина, перейдя в каталог / wp-content / plugins / :

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

После завершения загрузки активируйте плагин через интерфейс командной строки WordPress:

 плагин wp активировать OAuth1

Если вы не хотите использовать WordPress CLI, вы можете перейти в WordPress Admin >> Plugins и активировать плагин из меню. Кроме того, вы также можете активировать его, перейдя в браузере в раздел плагинов администратора WordPress, если вы не хотите использовать WP CLI.

Оценка доступности OAuth API

Прежде чем инициировать рукопожатие OAuth, я сначала проверю, включен ли API на сервере. Это делается путем отправки простого запроса GET на / wp-json / endpoint, а затем анализирует ответ, отправленный сервером.

 ПОЛУЧИТЬ http: // Server-Dev / wp-json /

Это вернет ответ JSON следующим образом:

Мое внимание здесь уделяется значению oauth1 в значении свойства аутентификации . У этого объекта определены следующие свойства:

• запрос : конечная точка запроса временных учетных данных
• authorize : конечная точка авторизации владельца ресурса
• доступ : конечная точка запроса токена
• версия : используемая версия OAuth

Если OAuth API не включен для сайта, ответ сервера будет содержать пустое значение свойства авторизации .

Создание и управление приложениями

Первый шаг - убедиться, что плагин OAuth1.0 правильно установлен и активирован.

Затем я могу создавать приложения и управлять ими, перейдя в WordPress Admin >> Users >> Applications.

На этой странице зарегистрированных приложений я зарегистрирую новое приложение, нажав кнопку « Добавить новое» и заполнив следующие три поля:

1. Имя клиента: имя клиента, которое отображается в разделе « Авторизованные приложения » и в процессе авторизации.
2. Описание : необязательное описание клиента.
3. URL-адрес обратного вызова: URL-адрес обратного вызова используется при создании временных учетных данных.

После создания путем нажатия кнопки « Сохранить клиента» параметры « Ключ клиента» и «Секрет клиента» появятся в нижней части страницы для этого конкретного клиента.

Теперь я клонирую репозиторий на клиенте, выполнив следующую команду:

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

Теперь перейдите в клонированный каталог и установите зависимости пакетов с помощью Composer:

 cd client-cli
композитор установить

Если все пойдет хорошо, в командной строке должно появиться что-то похожее на следующее:

Клиентский интерфейс командной строки для создания учетных данных OAuth

Чтобы запустить процесс авторизации OAuth, я сначала получу от сервера следующие параметры:

• oauth_consumer_key
• oauth_consumer_secret

Это будет сгенерировано через терминал и будет запущена следующая команда WordPress CLI:

 wp oauth1 добавить

Ключ и Секрет - это oauth_consumer_key и oauth_consumer_secret соответственно.

Теперь мне нужно связать клиента с сайтом WordPress. На клиенте перейдите в каталог client-cli (клонированный ранее) и выполните следующую команду:

 wp --require = client.php api oauth1 connect http: // Server-Dev / --key = <ваш ключ здесь> --secret = <ваш секрет здесь>

Замените URL-адрес, ключ и секрет в приведенной выше команде. Результат должен быть таким:

 wp --require = client.php api oauth1 connect http: // your-server / wordpress-api / --key = <ваш ключ> --secret = <ваш секретный код>
Откройте в своем браузере: http: // your-server / wordpress-api / oauth1 / authorize? Oauth_token = <your-token>
Введите проверочный код:

Перейдите к URL-адресу, предоставленному сервером, и выполните аутентификацию, нажав кнопку « Авторизовать» :

Вам будет представлен токен подтверждения (или oauth_verifier) ​​на следующем экране:

Скопируйте верификатор и вставьте его в терминал. Вам будут предоставлены ключ и секрет , которые в основном представляют собой oauth_token и oauth_token_secret соответственно:

HTTP-клиент для создания учетных данных OAuth

Поскольку подключаемый модуль сервера OAuth 1.0a следует стандартному трехстороннему потоку, создание учетных данных OAuth включает следующие шаги:

• Получение временных полномочий
• Авторизация пользователей
• Обмен токенов

Получение временных учетных данных

Я отправлю POST- запрос на конечную точку / oauth1 / request, чтобы получить временные учетные данные. Обратите внимание, что эту конечную точку следует автоматически обнаруживать, поскольку сервер может самостоятельно заменить маршрут.

Запрос POST должен включать параметры и oauth_consumer_secret, полученные при регистрации потребителя для приложения. Запрос может также включать параметр oauth_callback, и этот URL-адрес обратного вызова должен соответствовать схеме, хосту, порту и пути URL-адреса обратного вызова, который был предоставлен при регистрации приложения.

Помимо параметров oauth_consumer_key и oauth_consumer_secret , запрос должен также включать параметры oauth_signature и oauth_signature_method .

При использовании Postman oauth_signature создается автоматически. Мне нужно только упомянуть параметр oauth_signature_method . На данный момент плагином сервера OAuth поддерживается только метод подписи HMAC-SHA1.

Теперь я настрою Postman для отправки запроса POST в конечную точку временных учетных данных токена. Затем на вкладке « Авторизация » выберите в раскрывающемся списке вариант OAuth 1.0 . Заполните поля Consumer Key и Consumer Secret значениями, предоставленными потребителем. Наконец, убедитесь, что для параметра Метод подписи установлено значение HMAC-SHA1 .

Авторизация пользователя

На этапе авторизации пользователя я открою конечную точку авторизации владельца ресурса в браузере и передам oauth_token и oauth_token_secret, полученный на предыдущем шаге, в качестве параметров запроса:

 http: // server-dev / oauth1 / authorize? oauth_token = <token_here> & oauth_token_secret = <secret_here> 

Авторизуйте приложение, нажав кнопку « Авторизовать» . На следующем экране будет представлен токен подтверждения. Этот токен теперь будет действовать как токен oauth_verifier на следующем шаге.

После того, как пользователь авторизует клиента, приложение появится в разделе « Авторизованные приложения » на странице « Пользователи»> «Ваш профиль» .

Обмен токенов

Снова используя параметр OAuth 1.0 на вкладке « Авторизация », заполните поля « Ключ потребителя» и «Секрет потребителя» значениями, предоставленными потребителем. В полях Token и Token Secret вставьте значения параметров oauth_token и oauth_token_secret (временные учетные данные).

Поскольку я также могу передавать параметры в URL-адресе в качестве параметров запроса, добавьте параметр oauth_verifier к URL-адресу следующим образом:

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

Установив все параметры, отправьте запрос, нажав кнопку « Отправить» . Если все пойдет хорошо, сервер вернет код состояния 200 - OK вместе с телом ответа, содержащим параметры oauth_token и o auth_token_secret .

 oauth_token = <oauth_token_value> & oauth_token_secret = <oauth_secret_value>

На этом этапе временные жетоны, полученные ранее, сбрасываются и больше не могут быть использованы.

Новые параметры oauth_token и oauth_token_secret - это учетные данные OAuth, которые вы можете использовать в клиенте для генерации аутентифицированных запросов.

Отправка тестового запроса с проверкой подлинности

Теперь, когда у меня есть учетные данные токена, я отправлю тестовый запрос на сервер с помощью Postman. Для запроса потребуются следующие параметры:

Перед началом работы вам потребуется следующее:

• oauth_consumer_key
• oauth_consumer_secret
• oauth_token
• oauth_token_secret

Выберите OAuth 1.0 из раскрывающегося списка на вкладке « Авторизация » в Postman.

После того, как вы заполнили все поля, нажмите кнопку « Запрос на обновление» . Установите флажок Добавить параметры в заголовок, чтобы отправлять параметры в заголовке запроса вместо добавления в строку запроса.

Если запрос будет успешным, сервер отправит код состояния 200 - OK .

Подведение итогов!

В этом руководстве я обсудил, как настроить API аутентификации OAuth для WordPress на сервере и как использовать HTTP-клиент для получения учетных данных токена. Если вы обнаружите проблему в коде или хотите добавить что-то в обсуждение, оставьте комментарий ниже.