Введение в OAuth 2.0

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

Главная страница OAuth: На главной странице OAuth можно найти общую информацию о протоколе OAuth.

В этом разделе приводится основная информация о протоколе OAuth 2.0 в Apigee Edge.

Что такое OAuth 2.0?

Существует множество книг, блогов и сайтов, посвященных OAuth 2.0. Мы настоятельно рекомендуем вам сначала ознакомиться со спецификацией IETF OAuth 2.0. Вот определение OAuth 2.0 из спецификации IETF:

"Платформа авторизации OAuth 2.0 позволяет стороннему приложению получить ограниченный доступ к HTTP-сервису от имени владельца ресурса, организовав взаимодействие между владельцем ресурса и HTTP-сервисом, или предоставить стороннему приложению возможность получить доступ от своего имени".

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

Процесс OAuth 2.0

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

Важные термины

• Клиент. Также называется приложением. Это может быть приложение, работающее на мобильном устройстве, или традиционное веб-приложение. Приложение отправляет запросы на сервер ресурсов для защищенных объектов от имени владельца ресурса. Владелец ресурса должен предоставить приложению разрешение на доступ к защищенным ресурсам.
• Владелец ресурса. Также называется конечным пользователем. Как правило, это человек (или другая организация), который может предоставить доступ к защищенному ресурсу. Например, если приложению нужны данные из вашей социальной сети, вы будете владельцем ресурса, то есть единственным человеком, который может предоставить приложению доступ к вашим данным.
• Сервер ресурсов. Представьте себе сервер ресурсов как сервис, например Facebook, Google или Twitter, или как сервис отдела кадров в вашей интрасети, или как партнерский сервис в вашей B2B-экстрасети. Apigee Edge выступает в роли сервера ресурсов, когда для обработки запросов API требуется проверка токена OAuth. Серверу ресурсов требуется авторизация, прежде чем он предоставит приложению доступ к защищенным ресурсам.
• Сервер авторизации. Сервер авторизации реализован в соответствии со спецификацией OAuth 2.0 и отвечает за проверку разрешений на авторизацию и выдачу токенов доступа, которые предоставляют приложению доступ к данным пользователя на сервере ресурсов. Вы можете настроить конечные точки токенов в Apigee Edge, и тогда Edge будет выполнять роль сервера авторизации.
• Разрешение на авторизацию. Предоставляет приложению разрешение на получение токена доступа от имени конечного пользователя. В OAuth 2.0 определены четыре типа разрешений на доступ. Подробнее о типах разрешений на доступ по протоколу OAuth 2.0…
• Токен доступа. Длинная строка символов, которая используется в качестве учетных данных для доступа к защищенным ресурсам. Ниже также приведена информация о том, что такое токен доступа.
• Защищенный ресурс. Данные, принадлежащие владельцу ресурса. Например, список контактов пользователя, информацию об аккаунте или другие конфиденциальные данные.

Место Apigee Edge в экосистеме

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

Apigee предоставляет многогранное правило OAuthV2, которое реализует детали каждого типа предоставления, что позволяет относительно легко настроить OAuth в Apigee Edge. Например, вы можете настроить правило, которое получает запрос на токен доступа, проверяет все необходимые учетные данные и возвращает токен доступа, если учетные данные действительны.

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

Что такое типы разрешений на доступ по протоколу OAuth 2.0?

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

Apigee Edge поддерживает четыре основных типа разрешений OAuth 2.0:

• Код авторизации – считается самым безопасным типом предоставления доступа. Прежде чем сервер авторизации выдаст токен доступа, приложение должно получить код авторизации от сервера ресурсов. Вы видели этот процесс, когда приложение открывало браузер на странице входа на сервер ресурсов и предлагало вам войти в свой аккаунт (например, Facebook или Twitter).

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

• implicit – упрощенная версия кода авторизации. Обычно этот тип авторизации используется, когда приложение находится на стороне клиента. Например, код приложения реализован в браузере с помощью JavaScript или другого языка сценариев (вместо того, чтобы размещаться и выполняться на отдельном веб-сервере). При этом типе предоставления авторизационный сервер возвращает токен доступа напрямую после аутентификации пользователя, а не сначала выдает код авторизации. Неявное предоставление прав в некоторых случаях может повысить скорость работы приложения, но этот плюс нужно сопоставить с возможными проблемами безопасности, описанными в спецификации IETF.
• Учетные данные владельца ресурса. В этом потоке клиенту выдается токен доступа, когда сервер авторизации проверяет имя пользователя и пароль. Этот вариант рекомендуется для приложений с высоким уровнем доверия. Преимущество этого процесса по сравнению, например, с базовой аутентификацией заключается в том, что пользователь вводит имя пользователя и пароль только один раз. После этого используется токен доступа.
• Учетные данные клиента – рекомендуется использовать, когда клиентское приложение действует от своего имени. То есть клиент также является владельцем ресурса. Этот тип авторизации обычно используется, когда приложению требуется доступ к сервису хранения данных на сервере. Приложение должно использовать сервис для своей работы, и этот сервис не виден конечному пользователю. При использовании этого типа предоставления приложение может получить токен доступа, предоставив серверу авторизации свой идентификатор клиента и секретный код клиента. Дополнительные действия не требуются. Edge предоставляет готовое решение для учетных данных клиента, которое легко реализовать для любого прокси-сервера API.

Что такое токен доступа?

Токен доступа – это длинная строка символов, которая используется в качестве учетных данных для доступа к защищенным ресурсам. Токены ресурсов (также называемые токенами носителя) передаются в заголовках Authorization следующим образом:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Сервер ресурсов понимает, что токен доступа заменяет учетные данные, такие как имя пользователя и пароль. Кроме того, токены доступа могут выдаваться с ограничениями, например приложение может читать, но не записывать или удалять данные на сервере ресурсов. Обратите внимание, что токен доступа может быть отозван, например если приложение взломано. В этом случае вам потребуется получить новый токен доступа, чтобы продолжить пользоваться приложением, но вам не придется менять имя пользователя или пароль на сервере защищенных ресурсов (например, Facebook или Twitter).

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

Ограниченный доступ через области действия

С помощью областей действия OAuth 2.0 можно предоставить приложению ограниченный доступ к защищенным ресурсам. Например, у приложения может быть доступ только к определенным ресурсам, возможность обновлять ресурсы или только доступ для чтения. В так называемых трехсторонних потоках OAuth пользователь обычно указывает уровень доступа на странице согласия (например, на веб-странице, где он выбирает область действия с помощью флажка или другого механизма).

Как зарегистрировать приложение

Все клиенты (приложения) должны быть зарегистрированы на сервере авторизации OAuth 2.0, с которого они планируют запрашивать токены доступа. После регистрации приложения вы получите набор ключей. Один из них – открытый ключ, называемый идентификатором клиента, а другой – секретный ключ, называемый секретным кодом клиента. Без этих ключей приложение не может отправлять на сервер авторизации запросы на коды авторизации или токены доступа. Обратите внимание, что в спецификации IETF OAuth эти ключи называются идентификатором клиента и секретным кодом клиента, а в интерфейсе Apigee Edge – идентификатором потребителя и секретным кодом потребителя. Они эквивалентны.

Сводная информация о вариантах использования OAuth 2.0

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

OAuth 2.0 и ключ API: безопасность

Для проверки ключа API приложению необходимо отправить ключ в Edge. Ключ должен быть действительным идентификатором клиента из приложения для разработчиков Apigee Edge, связанного с прокси-сервером API. Если вам по какой-либо причине нужно отозвать разрешение клиентского приложения на вызовы прокси, вы должны отозвать идентификатор клиента. Клиентские приложения, использующие этот ключ, также не смогут получить доступ к прокси-серверу API. С другой стороны, токен OAuth можно отозвать в любой момент, не отзывая ключи приложения. Приложение может просто запросить новый токен от имени пользователя, и если токен будет предоставлен, приложение сможет продолжить использовать прокси-сервер API.

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

Подробнее о ключах API… Чтобы узнать, как использовать специальные атрибуты с токенами OAuth, ознакомьтесь со статьей Настройка токенов и кодов авторизации.

Рекомендуемые ресурсы

Чтение

Подробнее о протоколе OAuth 2.0…