«1. Обзор

В этом руководстве мы проанализируем, как мы можем пройти аутентификацию с помощью REST Assured для правильного тестирования и проверки защищенного API.

Инструмент обеспечивает поддержку нескольких схем аутентификации:

    Базовая аутентификация Дайджест-аутентификация Аутентификация по форме Аутентификация OAuth 1 и OAuth 2

И мы увидим примеры для каждой из них.

2. Использование базовой аутентификации

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

REST Assured предоставляет простой способ настройки учетных данных, которые требуются для запроса: 

given().auth()
  .basic("user1", "user1Pass")
  .when()
  .get("http://localhost:8080/spring-security-rest-basic-auth/api/foos/1")
  .then()
  .assertThat()
  .statusCode(HttpStatus.OK.value());

2.1. Упреждающая аутентификация

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

По умолчанию REST Assured ожидает запроса сервера перед отправкой учетных данных.

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

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

given().auth()
  .preemptive()
  .basic("user1", "user1Pass")
  .when()
  // ...

С ее помощью REST Assured отправит учетные данные, не дожидаясь ответа Unauthorized.

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

3. Использование дайджест-аутентификации

Несмотря на то, что этот метод также считается «слабым» методом аутентификации, использование дайджест-аутентификации дает преимущество перед базовым протоколом.

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

Несмотря на эту разницу, реализация этой формы аутентификации с помощью REST Assured очень похожа на ту, которой мы следовали в предыдущем разделе: 

given().auth()
  .digest("user1", "user1Pass")
  .when()
  // ...

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

4. Использование аутентификации с помощью формы

Многие сервисы предоставляют HTML-форму для аутентификации пользователя путем заполнения полей своими учетными данными.

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

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

Если форма входа достаточно проста и соответствует этим правилам, то мы можем положиться на REST Assured, чтобы вычислить эти значения для нас: 

given().auth()
  .form("user1", "user1Pass")
  .when()
  // ...

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

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

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

given().auth()
  .form(
    "user1",
    "user1Pass",
    new FormAuthConfig("/perform_login", "username", "password"))
  // ...

Помимо этих базовых конфигураций, REST Assured поставляется с функциями, позволяющими:

    обнаруживать или указывать токен CSRF поле на веб-странице использовать дополнительные поля формы в журнале запросов информация о процессе аутентификации

5. Поддержка OAuth

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

Тем не менее, его можно использовать в качестве основы для построения протокола аутентификации и идентификации, как в случае с OpenID Connect.

5.1. OAuth 2.0

REST Assured позволяет настроить токен доступа OAuth 2.0 для запроса защищенного ресурса: 

given().auth()
  .oauth2(accessToken)
  .when()
  .// ...

Библиотека не предоставляет никакой помощи в получении токена доступа, поэтому нам нужно выяснить, как делаем это сами.

Для потоков учетных данных клиента и пароля это простая задача, поскольку токен получается путем простого предоставления соответствующих учетных данных.

«С другой стороны, автоматизация потока кода авторизации может быть не такой простой, и нам, вероятно, также понадобится помощь других инструментов.

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

5.2. OAuth 1.0a

В случае OAuth 1.0a REST Assured предоставляет метод, который получает ключ потребителя, секрет, токен доступа и секретный токен для доступа к защищенному ресурсу: 

given().accept(ContentType.JSON)
  .auth()
  .oauth(consumerKey, consumerSecret, accessToken, tokenSecret)
  // ...

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

Обратите внимание, что нам нужно будет добавить зависимость scribejava-apis в наш проект, если мы используем функции OAuth 2.0 с версией до 2.5.0 или если мы используем функциональность OAuth 1.0a.

6. Заключение

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

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

Как всегда, рабочие примеры с инструкциями можно найти в нашем репозитории Github.