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

Вам когда-нибудь приходилось заполнять регистрационную форму, подобную приведенной ниже?

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

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

И тут появляется OAuth. Автоматизация обмена ключами — одна из основных проблем, которую решает OAuth. Он предоставляет клиенту стандартный способ получить ключ от сервера, проведя пользователя через простой набор шагов. С точки зрения пользователя, все, что требуется для OAuth — это ввод учетных данных. За кулисами клиент и сервер общаются туда-сюда, чтобы добиться работающего ключа для клиента.

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

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

• Пользователь — человек, который хочет связать два веб-сайта.
• Клиент — веб-сайт, которому будет предоставлен доступ к данным пользователя.
• Сервер — веб-сайт, на котором хранятся данные пользователя.

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

Итак, вот шаги OAuth 2.

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

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

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

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

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

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

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

Между версиями OAuth существует несколько ключевых различий. Один мы уже упоминали; токены доступа не имеют срока действия.

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

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

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

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

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

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

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

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

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