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

В предыдущей части серии мы настроили базовую HTTP аутентификацию, но её главная проблема в том, что в запросе присутствует имя пользователя и пароль, поэтому она не безопасна для использования в открытых сетях. Чаще всего такая аутентификация используется только для разработки и тестирования.

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

В этом материале мы:

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

Знакомимся с OAuth аутентификацией

Что вы делаете, когда вам необходимо зайти в админку WordPress? Вы просто переходите на страницу авторизации и вводите свои имя пользователя и пароль, верно? Всё просто! А что если вы используете сторонний сервис, которому необходим доступ к вашим WordPress ресурсам (посты, страницы, медиа и т.п.)? Отдадите ли вы им свои учётные данные? Ответ тут, вероятнее всего, "Нет".

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

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

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

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

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

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

Итак, согласно Webopedia:

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

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

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

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

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

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

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

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

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

Ниже представлен путь прохождения запроса в OAuth:

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

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

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

Всё это привело нас к трём конечным точкам URI:

1. Temporary Credential Request (запрос временных учётных данных)
2. Resource Owner Authorization (авторизаци владельца ресурсов)
3. Token Credentials Request (запрос учётных данных токена)

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

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

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

API OAuth аутентификации API для WordPress позволяет серверу принимать аутентифицированные запросы используя реализацию OAuth. Он построен на спецификациях OAuth 1.0a и расширяет их с помощью дополнительного параметра wp_scope, который посылается в конечную точку временных учётных данных (Temporary Credential Request). Этот параметр определяет область доступа, которая предоставляется клиенту. Подробнее вы может прочитать в официальной документации на GitHub.

Плагин доступен на Github и поддерживает только версию WordPress 4.4 или выше.

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

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

После того, как плагин скачан, активируйте его при помощи WP CLI:

wp plugin activate OAuth1

Либо активируйте плагин через админку WordPress.

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

Проверка наличия OAuth API

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

Откройте ваш HTTP клиент и отправьте запрос:

GET http://your-dev-server/wp-json/>

Он вернёт следующий JSON ответ:

Здесь мы должны обратить внимание на значение oauth1 в значении свойства authentication. У этого объекта обозначены следующие свойства:

• request - конечная точка Temporary Credential Request
• authorize - конечная точка Resource Owner Authorization
• access - конечная точкаToken Credentials Request
• version - версия OAuth плагина

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

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

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

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

Как только OAuth плагин установлен, мы можем создавать потребителей для наших приложений и управлять ими через админку WordPress в разделе Users (Пользователи) > Applications (Приложения).

На странице Registered Applications (Зарегистрированные приложения) мы может зарегистрировать новое приложение, кликнув на кнопку Add New (Добавить новое) и заполнив три поля:

1. Имя потребителя - это имя показывается пользователю во время процесса авторизации и также на странице профиля в разделе Авторизованные приложения.
2. Описание - опциональное описание приложения.
3. Callback URL - используется для генерации временных учётных данных.

После заполнения и сохранения на странице появятся учётные данные в виде Client key (Клиентский ключ) и Client Secret (Секретная строка).

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

Новый Client Secret может быть создан после клика на кнопку Regenerate Secret.

Нового потребителя можно создать также и через WP CLI:

wp oauth1 add --name=<consumer_name> --description=<consumer_description>

Теперь мы готовы начать процесс OAuth авторизации.

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

Генерация учётных данных OAuth включает в себя три шага:

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

Давайте начнём реализацию каждого из шагов при помощи HTTP клиента, например Postman.

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

Для получения временных учётных данных мы отправляем POST запрос в конечную точку /oauth1/request. Запрос должен содержать параметры oauth_consumer_key и oauth_consumer_secret, которые были получены при генерации нового потребителя приложения. Запрос также может включать параметр oauth_callback, который должен совпадать со схемой, хостом, портом и путём callback URL, который был указан при регистрации приложения.

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

Эти параметры могут быть переданы любым из трёх способов:

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

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

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

Настройте Postman для отправки POST запроса вашу конечную точку временных учётных данных. Далее во вкладке Authorization выберите опцию OAuth 1.0. Заполните Consumer Key and Consumer Secret. Убедитесь, что опция Signature Method выставлена в HMAC-SHA1.

Кликните на Update Request и далее на кнопку Send. Если ошибки не было, то сервер вернёт код статуса 200 – OK вместе с телом ответа:

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 или нет.

Теперь мы готовы к шагу авторизации.

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

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

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

Браузер попросит вас залогиниться в WordPress (если вы ещё не залогинены) и потом попросит авторизовать приложение:

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

Авторизуйте приложение, кликнув на кнопку Authorize, и на следующем экране вам станет доступен токен верификации:

Этот токен выступает в роли oauth_verifier на следующем шаге.

Как только пользователь авторизовал клиента, приложение появится в разделе Authorized Applications (Авторизованные приложения) на странице Users (Пользователи) > Your Profile (Ваш профиль).

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

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

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

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

Так как мы можем передать параметры в URL, добавьте параметр oauth_verifier:

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

Когда все параметры на месте, отправьте запрос. Если всё прошло успешно, сервер вернёт код статуса 200 – OK вместе с телом ответа, содержащим параметры oauth_token и oauth_token_secret:

oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>

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

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

Отправка тестового аутентифицированного запроса

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

Мы отправим запрос DELETE для удаления поста с id равным 50.

Для этого вам понадобятся:

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

Выберите опцию OAuth 1.0 во вкладке Authorization и заполните первые четыре поля:

Кликните на кнопку Update Request. Если у вас отмечена опция Add params to header, то запрос будет отправлен в заголовке, а не строке запроса URL.

Отправьте запрос и вы должны получить код статуса 200 – OK от сервера, что говорит о том, что пост был удалён успешно.

Итог

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

В следующем части мы рассмотрим получение контента через WP REST API.