И вот мы уже гораздо лучше понимаем, как устроены API. Мы знаем, кто такие клиент и сервер, мы знаем, что они используют HTTP, чтобы общаться друг с другом, и мы знаем, что они говорят в определенных форматах данных, чтобы понимать друг друга. Однако понимание, того, как они разговаривают, вызывает новый важный вопрос: как сервер узнает, что клиент является тем, кем он себя называет? В этой главе мы исследуем два способа, с помощью которых клиент может подтвердить свою личность серверу.

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

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

API-интерфейсы используют несколько методов для аутентификации клиента. Это так называемые схемы аутентификации. Давайте теперь посмотрим на две из этих схем.

Приведенный выше пример входа в систему является самой простой формой аутентификации. Фактически, его официальное название — Базовая аутентификация («Базовая аутентификация» для его друзей). Хотя это имя и не получило никаких наград за творческие достижения, эта схема является вполне приемлемым способом для сервера аутентифицировать клиента в API.

Для базовой аутентификации требуется только имя пользователя и пароль. Клиент берет эти два учетных данных, смешивает их вместе, чтобы сформировать единое значение, и передает его в запросе в заголовке HTTP под названием «Авторизация» (Authorization).

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

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

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

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

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

Итак, где же находится ключ API? Заголовок для него тоже есть, да? К сожалению, нет. В отличие от Basic Auth, который является установленным стандартом со строгими правилами, ключи API были разработаны в нескольких компаниях на заре интернета. В результате аутентификация с помощью ключа API немного похожа на дикий запад; у каждого свой способ делать это.

Однако со временем появилось несколько общих подходов. Один из них заключается в том, чтобы клиент поместил ключ в заголовок Авторизации вместо имени пользователя и пароля. Другой — добавить ключ в URL-адрес (http://example.com? api_key=my_secret_key ). Реже ключ закапывают где-нибудь в теле запроса рядом с данными. Куда бы ни пошел ключ, эффект будет одинаковым — он позволяет серверу аутентифицировать клиента.

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

• Аутентификация: процесс подтверждения клиентом своей личности серверу.
• Учетные данные: секретные данные, используемые для подтверждения личности клиента (имя пользователя, пароль ...).
• Базовая аутентификация: схема, использующая закодированные имя пользователя и пароль для учетных данных.
• API Key Auth: схема, использующая уникальный ключ для учетных данных.
• Заголовок авторизации: заголовок HTTP, используемый для хранения учетных данных.

В следующей главе мы продолжим обсуждение аутентификации, рассмотрев третий метод; тот, который быстро становится стандартом Интернета.