Способы аутентификации rest api

Авторизация в REST API

В REST API есть публичные и приватные конечные точки. Приватные требуют, чтобы пользователь был авторизован и имел соответствующие права на выполнения действия. Аутентификация в REST API выполняется во время запроса.

Аутентификация по cookies

Авторизация по кукам — это стандартный метод аутентификации в WordPress. Пользователь вводит свой логин/пароль, на основе них создается кука (и сохраняется в браузере). А дальше по этой куке WP каждый раз проверяет авторизован ли пользователь.

До версии 5.6 это был единственный метод авторизации в REST API доступный в WordPress по умолчанию. После появились еще Пароли приложений.

Для авторизации по кукам в REST запросе обязательно нужно передавать nonce-код . Нужно это для безопасности от атак Cross-Site Request Forgery (CSRF). Такой подход нужен только для обработки запросов, которым нужны особые права, например, запрос на удаление/изменение записи, рубрики и т.д.

Если использовать встроенный Javascript API, то можно забыть про nonce-технологию, так как она в этом случае работает автоматически. Это рекомендуемый метод использовать REST API при создании плагинов и тем, с ним можно быть уверенным, что любой запрос будет отправлен правильно. Базу wp.api.models.Base можно расширять.

Если использовать произвольные AJAX запросы, то нужно самому передавать nonce-код при каждом запросе. Для создания такого nonce-кода нужно использовать ключ wp_rest . nonce-код можно передать через:

• _wpnonce — параметр GET/POST запроса.
• X-WP-Nonce — HEADER параметр заголовка запроса.

Если правильный nonce-код НЕ указан, то REST API будет считать что авторизации НЕТ — current_user=0 , даже если юзер авторизован на самом сайте.

Заметка: так как PHP не переводит данные DELETE запроса в суперглобальный массив $_REQUEST , рекомендуется указывать nonce-код в заголовке запроса — через X-WP-Nonce .

Метод авторизации на куках будет работать только:

• когда REST API используется внутри WordPress (при AJAX запросах).
• когда текущий пользователь авторизован на сайте.
• когда у текущего пользователя есть достаточные права для выполнения указанного действия (например, удаления/изменения поста).

Примеры

#1 Как нужно создавать и передавать nonce-код при AJAX запросах.

Теперь используем созданные данные в JS коде:

#2 Изменим заголовок записи, через jQuery AJAX и REST API

В этом примере изменим заголовок поста 1. Для этого используется маршрут /wp/v2/posts/ :

Нет необходимости проверять nonce-код при обработке конечной точки, REST API делает это автоматически. Подробнее см. rest_cookie_check_errors().

Другие способы аутентификации

Когда нужен другой метод авторизации, например для работы с сайтом из стороннего приложения, используйте:

Источник

Требования аутентификации и авторизации API

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

Определяем термины

Во-первых, давайте определимся с некоторыми ключевыми терминами:

• Аутентификация: подтверждение правильности личности
• Авторизация: разрешение определенного действия

API может аутентифицировать, но не разрешит делать определенный запрос.

аутентификация и авторизация

Последствия нехватки безопасности API

Почему даже API-интерфейсы нуждаются в аутентификации? Для API, которые предназначены только для чтения, иногда пользователям не нужны ключи. Но большинство коммерческих API требуют авторизации в виде ключей API или других методов. Если нет никакой защиты API, пользователи могут совершать неограниченное количество запросов API без какой-либо регистрации. Разрешение неограниченных запросов усложнит модель дохода для вашего API.

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

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

В целом, аутентификация и авторизация с помощью API служат следующим целям:

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

Разные виды авторизации

Существует несколько методов авторизации. Ниже рассмотрим несколько вариантов авторизации, которые встречаются чаще всего:

API ключ

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

Ключи APK используют строку в свойстве заголовка для авторизации запросов

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

Basic Auth

Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

Когда сервер API получает сообщение, он дешифрует сообщение и проверяет заголовок. После декодирования строки и анализа имени пользователя и пароля он решает, принять или отклонить запрос.

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

Сервер API (получатель), получая запрос, принимает те же системные свойства (отметка времени запроса плюс идентификатор учетной записи) и использует секретный ключ (который известен только запрашивающей стороне и серверу API) и SHA для генерации одной и той же строки. Если строка соответствует подписи в заголовке запроса, запрос принимается. Если строки не совпадают, запрос отклоняется.

Вот диаграмма, отображающая процесс авторизации HMAC:

Важным моментом является то, что секретный ключ (критический для восстановления хэша) известен только отправителю и получателю. Секретный ключ не включается в запрос. Безопасность HMAC используется, когда нужно убедиться, что запрос является подлинным и не может быть подделан.

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

окно входа в систему, использующую Oauth2.0

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:

• сервер аутентификации;
• сервер API;
• пользователь или приложение.

Вот базовый процесс Oauth2.0:

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

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer , за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

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

Что документируется в разделе аутентификации

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

Тем не менее нужно объяснить необходимую информацию:

• как получить API ключ;
• как пройти аутентификацию запроса;
• сообщения об ошибках, связанных с неверной аутентификацией;
• чувствительность информации аутентификации;
• период действия токена доступа (авторизации).

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

Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

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

Amazon Web Services

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

👨‍💻 Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

• Какого рода авторизация требуется для отправки запросов к API?
• Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
• Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
• Как информация об авторизации интегрируется в раздел “Начало работы”?

Источник

Аутентификация ¶

В отличие от веб-приложений, RESTful API обычно не сохраняют информацию о состоянии, а это означает, что сессии и куки использовать не следует. Следовательно, раз состояние аутентификации пользователя не может быть сохранено в сессиях или куках, каждый запрос должен приходить вместе с определенным видом параметров аутентификации. Общепринятая практика состоит в том, что для аутентификации пользователя с каждым запросом отправляется секретный токен доступа. Так как токен доступа может использоваться для уникальной идентификации и аутентификации пользователя, запросы к API всегда должны отсылаться через протокол HTTPS, чтобы предотвратить атаки «человек посередине» (англ. «man-in-the-middle», MitM).

Есть различные способы отправки токена доступа:

• HTTP Basic Auth: токен доступа отправляется как имя пользователя. Такой подход следует использовать только в том случае, когда токен доступа может быть безопасно сохранен на стороне пользователя API. Например, если API используется программой, запущенной на сервере.
• Параметр запроса: токен доступа отправляется как параметр запроса в URL-адресе API, т.е. примерно таким образом: https://example.com/users?access-token=xxxxxxxx . Так как большинство веб-серверов сохраняют параметры запроса в своих логах, такой подход следует применять только при работе с JSONP -запросами, которые не могут отправлять токены доступа в HTTP-заголовках.
• OAuth 2: токен доступа выдается пользователю API сервером авторизации и отправляется API-серверу через HTTP Bearer Tokens, в соответствии с протоколом OAuth2.

Yii поддерживает все выше перечисленные методы аутентификации. Вы также можете легко создавать новые методы аутентификации.

Чтобы включить аутентификацию для ваших API, выполните следующие шаги:

1. У компонента приложения user установите свойство enableSession равным false .
2. Укажите, какие методы аутентификации вы планируете использовать, настроив поведение authenticator в ваших классах REST-контроллеров.
3. Реализуйте метод yii\web\IdentityInterface::findIdentityByAccessToken() в вашем классе UserIdentity.

Шаг 1 не обязателен, но рекомендуется его всё-таки выполнить, так как RESTful API не должен сохранять информацию о состоянии клиента. Когда свойство enableSession установлено в false , состояние аутентификации пользователя НЕ БУДЕТ сохраняться между запросами с использованием сессий. Вместо этого аутентификация будет выполняться для каждого запроса, что достигается шагами 2 и 3.

Подсказка: если вы разрабатываете RESTful API в пределах приложения, вы можете настроить свойство enableSession компонента приложения user в конфигурации приложения. Если вы разрабатываете RESTful API как модуль, можете добавить следующую строчку в метод init() модуля:

Например, для использования HTTP Basic Auth, вы можете настроить свойство authenticator следующим образом:

Если вы хотите включить поддержку всех трёх описанных выше методов аутентификации, можете использовать CompositeAuth :

Каждый элемент в массиве authMethods должен быть названием класса метода аутентификации или массивом настроек.

Реализация метода findIdentityByAccessToken() определяется особенностями приложения. Например, в простом варианте, когда у каждого пользователя есть только один токен доступа, вы можете хранить этот токен в поле access_token таблицы пользователей. В этом случае метод findIdentityByAccessToken() может быть легко реализован в классе User следующим образом:

После включения аутентификации описанным выше способом при каждом запросе к API запрашиваемый контроллер будет пытаться аутентифицировать пользователя в своем методе beforeAction() .

Если аутентификация прошла успешно, контроллер выполнит другие проверки (ограничение частоты запросов, авторизация) и затем выполнит действие. Информация об аутентифицированном пользователе может быть получена из объекта Yii::$app->user->identity .

Если аутентификация прошла неудачно, будет возвращен ответ с HTTP-кодом состояния 401 вместе с другими необходимыми заголовками (такими, как заголовок WWW-Authenticate для HTTP Basic Auth).

Авторизация ¶

После аутентификации пользователя вы, вероятно, захотите проверить, есть ли у него или у неё разрешение на выполнение запрошенного действия с запрошенным ресурсом. Этот процесс называется авторизацией и подробно описан в разделе «Авторизация».

Если ваши контроллеры унаследованы от yii\rest\ActiveController, вы можете переопределить метод yii\rest\Controller::checkAccess() для выполнения авторизации. Этот метод будет вызываться встроенными действиями, предоставляемыми контроллером yii\rest\ActiveController.

Источник