Глава 5: API-аутентификация, часть 2 (OAuth)

Структура мини-курса

1. Введение в API

2. Протоколы API

3. Типы и форматы API

4. Проверка подлинности API, часть 1: Основные и ключевые

5. Проверка подлинности API, часть 2: OAuth

6. Проектирование API

7. Взаимодействие с API в режиме реального времени

8. Реализация API

В Главе 4 мы упомянули, что большинство веб-сайтов используют имя пользователя и пароль для аутентификации учетных данных. Мы также обсудили, что повторное использование этих учетных данных для доступа к API небезопасно, поэтому API часто требуют другой набор учетных данных, нежели те, которые используются для входа на веб-сайт. Распространенным примером являются ключи API. В этой главе мы рассмотрим другое решение — открытую авторизацию (OAuth), которая становится наиболее широко используемой схемой аутентификации в Интернете.

Структура главы 5

1. Аутентификация против авторизации

2. Проблема с API-аутентификацией

3. Как OAuth решает проблему

4. OAuth 2.0

5. Шаг 1: Пользователь просит клиента подключиться к серверу.

6. Шаг 2: Клиент направляет пользователя на сервер

7. Шаг 3: Пользователь регистрируется на сервере и предоставляет клиенту доступ

8. Шаг 4: Сервер отправляет пользователя обратно клиенту вместе с кодом

9. Шаг 5: Клиент обменивается кодом и секретным ключом на токен доступа

10. Шаг 6: Клиент извлекает данные с сервера

11. Клиент обновляет токен (необязательно)

12. Чем отличается OAuth 1.0

13. Краткое изложение главы 5

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

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

В контексте API:

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

• Авторизация "authorization" — это связанный процесс подтверждения привилегии доступа, в данном случае подтверждение того, что у агента есть разрешение на доступ к тому, к чему он пытается получить доступ. Одним из все более распространенных примеров авторизации является OAuth 2.0, который (осторожно, спойлер) мы рассмотрим ниже.

Проблема с API-аутентификацией

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

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

Как OAuth решает проблему

Введите: OAuth. Автоматизация обмена ключами - одна из основных проблем, решаемых с помощью OAuth. Она предоставляет клиенту стандартный способ получения ключа с сервера путем выполнения пользователем простого набора действий. Все, что нужно сделать пользователю, это ввести свои учетные данные. За кулисами клиент и сервер обмениваются информацией, чтобы получить от клиента действительный ключ. Все более популярным (и удобным) примером этого является использование Google login agent для входа на веб-сайт, и других аналогов не принадлежащих Google, таких как Reddit (или Zapier). Больше примеров представлено по ссылке от автора (or Zapier).

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

OAuth 2.0

Для начала нам нужно узнать состав персонажей, участвующих в обмене OAuth:

• Пользователь (user): Человек, который хочет соединить два используемых им веб-сайта

• Клиент (client): Веб-сайт, которому будет предоставлен доступ к данным пользователя

• Сервер (server): Веб-сайт, на котором находятся данные пользователя

Далее нам нужно сделать краткий отказ от ответственности. Одна из целей OAuth 2.0 — позволить компаниям адаптировать процесс аутентификации к своим потребностям. Из-за этой расширяемой природы API могут иметь немного разные шаги. Рабочий процесс, показанный ниже, является распространенным среди веб-приложений. Мобильные и настольные приложения могут использовать небольшие изменения в этом процессе.

Учитывая это, вот шаги по внедрению OAuth 2.0.

 Шаг 1: Пользователь просит клиента подключиться к серверу.

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

Шаг 2: Клиент направляет пользователя на сервер

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

Шаг 3: Пользователь регистрируется на сервере и предоставляет клиенту доступ

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

 Шаг 4: Сервер отправляет пользователя обратно клиенту вместе с кодом

Сервер отправляет пользователя обратно клиенту (по URL-адресу обратного вызова, указанному в шаге 2). В ответе скрыт уникальный код авторизации для клиента.

Шаг 5: Клиент обменивается кодом и секретным ключом на токен доступа

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

 Шаг 6: Клиент извлекает данные с сервера

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

Клиент обновляет токен (необязательно)

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

Чем отличается OAuth 1.0

Между двумя версиями OAuth есть несколько ключевых отличий:

• Одно из них мы уже упомянули: токены доступа не имеют срока действия.

• Другое отличие заключается в том, что OAuth 1.0 включает дополнительный шаг. Между шагами 1 и 2 выше OAuth 1.0 требует, чтобы клиент запросил у сервера токен запроса. Этот токен действует как код авторизации в OAuth 2.0 и является тем, что обменивается на токен доступа.

• Третье отличие заключается в том, что OAuth 1.0 требует, чтобы запросы были подписаны в цифровом виде. Мы пропустим подробности того, как работает электронная подпись (ЭЦП) (вы можете найти библиотеки кода, которые сделают это за вас), но стоит знать, почему она есть в одной версии, а не в другой. Подпись запроса — это способ защиты данных от подделки во время их перемещения между клиентом и сервером. Подписи позволяют серверу проверять подлинность запросов.

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

Authorization (авторизация)

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

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

Краткое изложение главы 5

В этой главе мы изучили поток процесса аутентификации OAuth. Мы сравнили две версии, указав на основные различия между ними.

Ключевые термины, которые мы изучили:

• OAuth: схема аутентификации, которая автоматизирует обмен ключами между клиентом и сервером

• Токен доступа (Access token): секретный код, который клиент получает после успешного завершения процесса OAuth

• Область действия (Scope): разрешения, которые определяют, какой доступ клиент имеет к данным пользователя

Следующая

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