Аутентификация запросов (сервис подписи)

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

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


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

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

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

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

  • Указание HTTP-заголовка Authorization — использование HTTP-заголовка авторизации является одним из самых распространенных способов аутентификации запроса сервиса.
  • Параметры строки запроса — вы можете воспользоваться строкой запроса для того, чтобы полностью указать сам запрос в строке URL-адреса. В данном случае вы используете параметры запроса для предоставления информации о запросе, что включает в себя информацию об аутентификации. Так как подпись запроса входит в URL-адрес, этот тип URL-адреса часто называют «заранее подписанный URL-адрес». Вы можете использовать заранее подписанные URL-адреса, чтобы встраивать в HTML гиперссылки, которые могут действовать до семи дней.

Введение в создание подписей для запросов

Информация об аутентификации, отправляемая в запросе, должна включать в себя подпись. Для вычисления подписи вы сначала объединяете избранные элементы запроса для того, чтобы сформировать подписываемую строку StringToSign. Затем вы используете ключ подписи для вычисления HMAC подписываемой строки.

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

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

image

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

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

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

Вычисления подписи для заголовка авторизации: передача полезных данных одним блоком (сервис подписи)

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

Важно

При передаче полезных данных одним блоком вы можете также включать в вычисления подписей хеш-суммы полезных данных. В результате получаются так называемые подписанные полезные данные (signed payload). Если же хеш-суммы полезных данных не включаются в вычисления подписей, то полезные данные считаются не подписанными (unsigned payload). Процедура создания подписи, описываемая в следующем разделе, применима к обоим типам полезных данных, но необходимо отметить некоторые различия между ними.

  • При использовании подписанных полезных данных вы включаете хеш-сумму в формируемый вами канонический запрос (который затем становится частью StringToSign, как описано в разделе, где рассматривается вычисление подписи). Также вы указываете значение, совпадающее со значением заголовка x-amz-content-sha256, во время отправки запроса в сервис.
  • При использовании не подписанных полезных данных вы включаете текстовую строку UNSIGNED-PAYLOAD в формируемый вами канонический запрос и указываете значение, совпадающее со значением заголовка x-amz-content-sha256, во время отправки запроса в сервис.

При отправке запроса в сервис значение заголовка x-amz-content-sha256 несет информацию о том, являются полезные данные подписанными или нет. Затем сервис соответствующим образом создает подпись для проверки.