WP REST API: настройка и использование аутентификации OAuth 1.0a

В предыдущей части серии мы настраивали базовую HTTP-аутентификацию на сервере, устанавливая плагин, доступный на GitHub командой WP REST API. Основной метод аутентификации позволяет нам отправлять аутентифицированные запросы, отправляя учетные данные для входа в заголовок запроса. Будучи быстрым и удобным, есть также шанс, что эти учетные данные могут попасть в чужие руки. Следовательно, этот метод должен использоваться только в защищенных сетях только для целей разработки и тестирования.

Для использования аутентификации на производственных серверах должен быть более безопасный способ отправки аутентифицированных запросов без риска раскрытия учетных данных для входа. Благодаря методу аутентификации OAuth эти запросы можно отправлять без раскрытия имени пользователя и пароля небезопасным способом.

В текущей части серии мы научимся настраивать и использовать метод аутентификации OAuth для использования с плагином WP REST API. Чтобы быть конкретным, мы будем:

• рассмотрим метод проверки подлинности OAuth и его работу
• установить плагин OAuth-сервера
• создать токен доступа OAuth для использования в нашем приложении

Давайте начнем с знакомства с методом аутентификации OAuth.

Представляем аутентификацию OAuth

Что вы делаете, когда вам нужно войти в систему администратора WordPress? Вы просто заходите на страницу входа и вводите свои учетные данные, верно? Это просто! Но что, если вы используете стороннюю службу, которая требует доступа к вашим ресурсам WordPress (сообщениям, страницам, медиафайлам или чему-либо еще)? Не могли бы вы просто передать свои учетные данные для входа в эту службу, зная, что они могут оказаться в чужих руках, когда нарушается целостность этой службы? Ответ, вероятно, будет «Нет».

В традиционной модели аутентификации есть две роли:

1. Клиент: может быть пользователем, приложением или службой
2. Поставщик ресурсов: сервер, на котором расположены защищенные ресурсы.

Если клиент хочет получить доступ к защищенным ресурсам, он или она будет аутентифицирован путем предоставления соответствующих учетных данных серверу и получит доступ.

Проблема возникает, когда сторонней службе требуется доступ к этим защищенным ресурсам на сервере. Эта служба не может (и не должна) предоставляться учетными данными пользователя для доступа к ресурсам. Предоставление учетных данных третьему лицу означает предоставление полного контроля над ресурсом, расположенным на сервере.

Вот где методология аутентификации OAuth приходит на помощь. Он вводит новую роль в процессе аутентификации и является владельцем ресурса . Теперь в процессе аутентификации есть три роли:

1. Клиент: не сам пользователь, а стороннее приложение или служба, действующая от имени пользователя и получающая доступ к защищенным ресурсам.
2. Сервер: сервер, на котором расположены защищенные ресурсы
3. Владелец ресурса: сам пользователь

Вышеупомянутые три роли вместе составляют то, что называют трехсторонней аутентификацией OAuth. Количество ветвей определяет роли, вовлеченные в процесс аутентификации. Когда владелец ресурса также является клиентом, поток становится известен как двухсторонняя аутентификация.

Согласно Вебопедии :

OAuth — это открытый стандарт авторизации, используемый для обеспечения безопасного доступа клиентских приложений к ресурсам сервера. Инфраструктура авторизации OAuth позволяет стороннему приложению получать ограниченный доступ к службе HTTP, либо от имени владельца ресурса, либо позволяя стороннему приложению получать доступ от своего имени.

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

Следовательно, в процессе аутентификации OAuth пользователю не нужно предоставлять учетные данные, но он может разрешить клиенту действовать от его имени, решая, к каким ресурсам клиент может получить доступ. Другими словами, не предоставляя учетные данные для входа в систему, пользователь также может решить объем доступа, который предоставляется клиенту.

Это позволяет не только веб-сайтам, но и настольным и мобильным приложениям получать ограниченный доступ к ресурсу на сервере.

Что касается WordPress, OAuth информирует поставщика ресурсов (установка WordPress) о том, что владелец ресурса (пользователь WordPress) предоставил разрешение на доступ к стороннему приложению для доступа к своим ресурсам. Этими ресурсами могут быть что угодно: посты, страницы, таксономия, медиа и т. Д. Это разрешение может быть для ограниченного или полного доступа, как мы увидим позже в этом руководстве.

Как работает поток аутентификации OAuth

API аутентификации OAuth для WordPress построен на основе спецификаций OAuth 1.0a, поэтому мы рассмотрим, как работает OAuth 1.0a.

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

Эти учетные данные токена имеют ограниченное время жизни и могут быть отозваны сервером по запросу владельца ресурса.

Поток OAuth выглядит следующим образом:

1. Клиент отправляет подписанный запрос на сервер для получения токена запроса , также известного как временные учетные данные . Этот запрос отправляется на URI конечной точки временных учетных данных и содержит следующее:
   • oauth_consumer_key : предоставляется сервером
   • oauth_timestamp
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oath_callback
   • oauth_version (необязательно)
2. Сервер проверяет запрос и, если он действителен, выдает маркер запроса, который содержит:
   • oauth_token
   • oauth_token_secret
   • oauth_callback_confirmed
3. Затем клиент отправляет владельца ресурса (пользователя) на сервер для авторизации запроса. Это делается путем создания URI запроса путем добавления oauth_token полученного на предыдущем шаге, к URI конечной точки авторизации владельца ресурса.
4. Владелец ресурса (пользователь) авторизуется на сервере, предоставляя учетные данные.
5. Если на первом этапе был предоставлен URI oauth_callback , сервер перенаправляет клиента на этот URI и добавляет в качестве строки запроса следующее:
   • oauth_token : получено на втором шаге
   • oauth_verifier : используется, чтобы гарантировать, что владелец ресурса, предоставивший доступ, будет возвращен клиенту
6. Если URI oauth_callback не был предоставлен на первом шаге, то сервер отображает значение oauth_verifier чтобы владелец ресурса мог сообщить клиенту вручную.
7. После получения oauth_verfier клиент запрашивает у сервера учетные данные токена, отправляя запрос на URI конечной точки запроса токена. Этот запрос содержит следующее:
   • oauth_token : получено на втором шаге
   • oauth_verfier : получено на предыдущем шаге
   • oauth_consumer_key : предоставляется поставщиком ресурсов (сервером) перед запуском рукопожатия oauth
   • oauth_signature
   • oauth_signature_method
   • oauth_nonce
   • oauth_version
8. Сервер проверяет запрос и предоставляет следующее, известное как учетные данные токена:
   • oauth_token
   • oauth_token_secret
9. Затем клиент использует учетные данные токена для доступа к защищенным ресурсам на сервере.

Приведенная выше информация может быть передана либо строкой запроса, добавленной к URI запроса, либо включением ее в заголовок Authorization , хотя последний рекомендуется из-за большей безопасности.

Это длительный процесс, который следует учитывать при разработке наших собственных клиентов для взаимодействия с API. Цель клиента — управлять всем этим жаргоном и облегчить пользователю процесс аутентификации. Поскольку мы будем использовать пакет, предоставленный командой API WP REST, вышеприведенные детали будут удалены, и мы сможем получить учетные данные токена за минимальное количество шагов.

В приведенном выше обсуждении мы столкнулись с тремя URI конечной точки, а именно:

1. Временная конечная точка запроса учетных данных
2. Конечная точка авторизации владельца ресурса
3. Конечная точка запроса учетных данных токена

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

Посмотрев, как работает OAuth, наш следующий шаг — установить и включить API аутентификации OAuth для WordPress.

Установка API аутентификации OAuth для WordPress

API аутентификации OAuth для WordPress позволяет серверу принимать аутентифицированные запросы с использованием реализации OAuth. Он построен на основе спецификаций OAuth 1.0a и дополняет их дополнительным параметром — wp_scope — для отправки в конечную точку запроса временных учетных данных . Параметр wp_scope определяет область доступа, предоставляемого клиенту. Вы можете найти больше об этом в официальной документации на GitHub .

Плагин доступен на Github от команды WP REST API и поддерживает только версию 4.4 или более позднюю версию WordPress.

Давайте клонируем плагин, перейдя в каталог /wp-content/plugins/ :

После завершения загрузки активируйте плагин с помощью WP CLI:

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

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

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

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

Запустите ваш HTTP-клиент и отправьте запрос в /wp-json/ endpoint следующим образом:

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

Наше внимание здесь сосредоточено на значении oauth1 значении свойства authentication . Для этого объекта определены следующие свойства:

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

Первые три из них являются абсолютными URL-адресами, с которыми мы столкнулись при изучении механизма OAuth в предыдущем разделе.

Объект oauth1 определенный в значении свойства authentication показывает, что API-интерфейс OAuth был успешно включен для нашего сайта WordPress, и мы можем начать его использовать.

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

Теперь, когда мы установили плагин OAuth1.0a, давайте посмотрим, как мы можем создавать и управлять пользователями для наших приложений.

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

После успешной установки плагина OAuth1.0 мы можем создавать и управлять пользователями наших приложений, перейдя к администратору WordPress, а затем на страницу « Пользователи> Приложения» .

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

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

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

Эти параметры Client Key и Client Secret действуют как параметры oauth_consumer_key и oauth_consumer_secret соответственно.

Новый секрет клиента можно создать, нажав кнопку « Восстановить секрет» в нижней части страницы.

Плагин OAuth также предоставляет функциональность для создания потребителя в консоли через плагин WP CLI. Таким образом, новый потребитель также может быть создан с помощью следующей команды в терминале:

Этот вновь созданный потребитель появится на странице « Зарегистрированные приложения», где вы сможете его редактировать.

После регистрации нашего приложения мы готовы начать процесс авторизации OAuth в следующих разделах.

Установка клиентского пакета CLI

Обратите внимание, что во время написания этого руководства плагин OAuth1.0a больше не поддерживает пакет CLI клиента. Пакет CLI клиента может быть обновлен в ближайшем будущем для работы с последней версией плагина OAuth, но сейчас, пожалуйста, обратитесь к следующему разделу о генерации учетных данных OAuth с помощью HTTP-клиента.

Пакет Client-CLI команды WP REST API позволяет удаленно взаимодействовать с сайтом WordPress с использованием WP-CLI и WP REST API. Источник можно найти на GitHub .

Чтобы использовать этот пакет, вам необходимо установить и активировать следующее на сервере, где находится ваша установка WordPress:

1. WP CLI
2. WP REST API плагин
3. OAuth 1.0a серверный плагин

На компьютере (или клиенте), с которого вы хотите генерировать запросы, должно быть установлено следующее:

1. WP CLI
2. Композитор
3. Сам CLI- репозиторий клиента

Вы можете найти инструкции по установке вышеуказанных пакетов на соответствующих сайтах.

С учетом вышесказанного давайте клонируем репозиторий на клиенте, выполнив следующую команду:

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

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

Теперь, когда мы установили пакет, мы готовы генерировать учетные данные токена и удаленно взаимодействовать с WordPress REST API с помощью OAuth.

Использование клиентского CLI для генерации учетных данных OAuth

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

• oauth_consumer_key
• oauth_consumer_secret

Это можно сгенерировать, направив терминал в каталог установки WordPress на сервере и выполнив следующую команду WP CLI:

Это сгенерирует вывод, подобный следующему:

Key и Secret полученные здесь, являются oauth_consumer_key и oauth_consumer_secret соответственно.

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

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

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

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

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

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

Использование HTTP-клиента для генерации учетных данных OAuth

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

1. Приобретение временных документов
2. Авторизация пользователя
3. Обмен токенами

Давайте начнем реализовывать каждый из вышеперечисленных шагов, используя HTTP-клиент, то есть Postman.

1. Получение временных полномочий

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

Запрос POST должен включать параметры oauth_consumer_key и 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 .

Вышеуказанные параметры могут быть переданы любым из следующих трех способов:

1. Через заголовок Authorization
2. Через ( GET ) параметры запроса в URL
3. Через ( POST ) параметры тела запроса. Тип содержимого в этом случае должен быть application/x-www-form-urlencoded .

Вы можете использовать любой из этих методов для отправки этих параметров на сервер.

Давайте теперь начнем процесс, запустив Postman и отправив запрос POST конечной точке запроса временных учетных данных. Но перед этим скопируйте параметры Consumer Key и Consumer Secret, предоставленные вновь зарегистрированным приложением, так как они понадобятся на этом этапе.

Сконфигурируйте Postman для отправки POST запроса к вашей конечной точке временных учетных данных токена. Затем на вкладке Авторизация выберите опцию OAuth 1.0 из выпадающего списка. Заполните поля Ключ потребителя и Секрет потребителя значениями, предоставленными потребителем. Убедитесь, что для параметра « Метод подписи» установлено значение HMAC-SHA1 .

Нам не нужно вводить какие-либо значения, кроме этих. Нажмите кнопку Обновить запрос и, наконец, отправьте запрос, нажав кнопку Отправить .

Если ошибки нет, сервер вернет код состояния 200 — ОК вместе с телом ответа, имеющим тип содержимого application/x-www-form-urlencoded application/x-www-form-urlencoded . Тело этого запроса выглядит примерно так:

1	oauth_token=tyNCKaL3WAJXib5SI6jCnr4P&oauth_token_secret=1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF&oauth_callback_confirmed=true

Это тело ответа содержит три параметра для следующего шага трехстороннего потока. Эти три параметра:

1. oauth_token : временный токен OAuth для этапа авторизации.
2. oauth_token_secret : временный секрет, который будет использоваться вместе с oauth_token .
3. oauth_callback_confirmed : этот параметр всегда возвращается независимо от того, oauth_callback ли вы параметр oauth_callback на первом шаге.

С этими временными учетными данными мы готовы к этапу авторизации пользователя.

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

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

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

Браузер попросит вас войти в WordPress (если вы еще не вошли в систему), а затем попросит вас авторизовать приложение:

Здесь Awesome Application - это имя зарегистрированного приложения.

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

Этот токен действует как токен oauth_verifier на следующем шаге.

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

3. Обмен токенами

Следующий и последний шаг в трехстороннем потоке - обмен токенами. На этом этапе временные токены, полученные на первом этапе, обмениваются на долгоживущий токен, который может использоваться клиентом.

Чтобы инициировать процесс обмена токенами, переключитесь обратно на Почтальон и настройте его на отправку запроса POST конечной точке запроса токена.

Снова используя опцию OAuth 1.0 на вкладке Авторизация , заполните поля для Consumer Key и Consumer Secret значениями, предоставленными потребителем. Для полей Token и Token Secret используйте значения параметров oauth_token и oauth_token_secret (временные учетные данные), которые были получены на первом шаге.

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

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

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

1	oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>

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

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

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

Теперь, когда мы получили наши учетные данные токена, мы можем отправить тестовый запрос на сервер, используя Postman, чтобы посмотреть, работают ли они (конечно, они будут!).

Мы отправим запрос DELETE на сервер, чтобы удалить сообщение с идентификатором 50. Этот идентификатор может отличаться в вашем случае.

Вам нужно иметь следующее, прежде чем начать:

• oauth_consumer_key : получено на первом шаге
• oauth_consumer_secret : получено на первом шаге
• oauth_token : получено на последнем шаге
• oauth_token_secret : получено на последнем шаге

Выберите OAuth 1.0 из раскрывающегося списка на вкладке « Авторизация » в «Почтальоне» и заполните первые четыре поля, как указано выше. Вот как это выглядит:

Нажмите кнопку « Запрос на обновление» после заполнения полей. Проверка опции Добавить параметры в заголовок отправляет параметры в заголовке запроса вместо добавления их в строку запроса.

Отправьте запрос, и вы получите 200 - ОК код состояния с сервера, показывающий, что сообщение было успешно удалено.

Вывод

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

В следующей части этой серии мы рассмотрим извлечение контента через API WP REST. Так что следите за обновлениями ...