Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Главная страница 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:
«Система авторизации OAuth 2.0 позволяет стороннему приложению получать ограниченный доступ к HTTP-сервису либо от имени владельца ресурса путем организации взаимодействия для подтверждения между владельцем ресурса и HTTP-сервисом, либо позволяя стороннему приложению получать доступ от своего собственного имени».
Главное, что нужно знать, это то, что OAuth 2.0 предоставляет приложениям возможность получать ограниченный доступ к защищенным ресурсам пользователя (например, к банковскому счету или любой другой конфиденциальной информации, к которой пользователь может захотеть получить доступ из приложения) без необходимости раскрытия пользователем своих учетных данных приложению.
Процесс OAuth 2.0
Вот общая схема работы системы безопасности OAuth 2.0. Мы обсудим эту схему более подробно в этой теме, начиная с диаграммы, которая наглядно иллюстрирует принцип работы OAuth 2.0. Если вам незнакомы термины, используемые на этой диаграмме, прочтите этот раздел для краткого ознакомления.
Термины, которые вам следует знать
- Клиент: Также называется «приложением». Это может быть приложение, работающее на мобильном устройстве, или традиционное веб-приложение. Приложение отправляет запросы на сервер ресурсов для получения защищенных ресурсов от имени владельца ресурса. Владелец ресурса должен предоставить приложению разрешение на доступ к защищенным ресурсам.
- Владелец ресурса: также называемый «конечным пользователем». Как правило, это лицо (или другая организация), способное предоставить доступ к защищенному ресурсу. Например, если приложению необходимо использовать данные с одной из ваших социальных сетей, то вы являетесь владельцем ресурса — единственным лицом, которое может предоставить приложению доступ к вашим данным.
- Сервер ресурсов: Представьте себе сервер ресурсов как сервис, подобный Facebook, Google или Twitter; или как HR-сервис в вашей внутренней сети; или как партнерский сервис в вашей внешней сети B2B. Apigee Edge выступает в роли сервера ресурсов всякий раз, когда требуется проверка токена OAuth для обработки запросов API. Сервер ресурсов должен пройти авторизацию, прежде чем он сможет предоставить приложению защищенные ресурсы.
- Сервер авторизации: Сервер авторизации реализован в соответствии со спецификацией 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.
- Неявное предоставление доступа — считается упрощенной версией кода авторизации. Обычно этот тип предоставления доступа используется, когда приложение находится на стороне клиента. Например, код приложения реализован в браузере с использованием JavaScript или другого скриптового языка (вместо того, чтобы находиться и работать на отдельном веб-сервере). В этом типе предоставления доступа сервер авторизации возвращает токен доступа непосредственно после аутентификации пользователя, а не выдает сначала код авторизации. Неявное предоставление доступа может в некоторых случаях повысить скорость отклика приложения, но это преимущество необходимо сопоставлять с возможными последствиями для безопасности, как описано в спецификации IETF.
- Учетные данные владельца ресурса (пароль) — В этом процессе клиенту выдается токен доступа после проверки имени пользователя и пароля сервером авторизации. Этот процесс рекомендуется для приложений с высоким уровнем доверия. Преимущество этого процесса по сравнению, например, с базовой аутентификацией, заключается в том, что пользователь вводит свое имя пользователя и пароль только один раз. После этого используется токен доступа.
- Учетные данные клиента — рекомендуется использовать этот тип предоставления доступа в ситуациях, когда клиентское приложение действует от своего имени. То есть клиент также является владельцем ресурса. Этот тип предоставления доступа обычно используется, например, когда приложению необходимо получить доступ к серверной службе хранения данных. Приложению необходимо использовать эту службу для своей работы, и в противном случае служба непрозрачна для конечного пользователя. С этим типом предоставления доступа приложение может получить токен доступа, предоставив свой идентификатор клиента и секретный ключ клиента серверу авторизации. Никаких дополнительных действий не требуется. Edge предоставляет готовое решение для учетных данных клиента, которое легко реализовать для любого API-прокси.
Что такое токен доступа?
Токен доступа — это длинная строка символов, служащая учетными данными для доступа к защищенным ресурсам. Токены ресурсов (также называемые токенами носителя) передаются в заголовках авторизации следующим образом:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Сервер ресурсов понимает, что токен доступа «заменяет» учетные данные, такие как имя пользователя и пароль. Кроме того, токены доступа могут быть выданы с ограничениями, например, приложение может читать, но не записывать или удалять данные на сервере ресурсов. Обратите внимание, что токен доступа может быть отозван, если, например, приложение будет скомпрометировано. В этом случае вам потребуется получить новый токен доступа, чтобы продолжить использование приложения; однако вам не придется менять имя пользователя или пароль на защищенном сервере ресурсов (например, Facebook или Twitter).
Токены доступа обычно имеют срок действия (по соображениям безопасности). Некоторые типы предоставления доступа позволяют серверу авторизации выдавать токен обновления, который позволяет приложению получать новый токен доступа по истечении срока действия старого. Более подробную информацию о токенах доступа и обновления см. в спецификации IETF OAuth 2.0.
Ограниченный доступ через микроскопы.
С помощью механизма областей действия (scopes) OAuth 2.0 может предоставлять приложению ограниченный доступ к защищенным ресурсам. Например, приложение может иметь доступ только к определенным ресурсам, может иметь возможность обновлять ресурсы или может иметь только доступ для чтения. В так называемых «трехэтапных» потоках OAuth пользователь обычно указывает уровень доступа через страницу согласия (например, веб-страницу, где пользователь выбирает область действия с помощью флажка или другого механизма).
Регистрация приложения
Все клиенты (приложения) должны зарегистрироваться на сервере авторизации OAuth 2.0, с которого они намереваются запрашивать токены доступа. При регистрации приложения вы получаете набор ключей. Один из них — открытый ключ, называемый идентификатором клиента, а другой — секретный ключ, называемый секретом клиента. Без этих ключей приложение не может отправлять запросы на коды авторизации или токены доступа на сервер авторизации. Обратите внимание, что хотя в спецификации IETF OAuth эти ключи называются идентификатором клиента и секретом клиента, в пользовательском интерфейсе Apigee Edge они называются идентификатором потребителя и секретом потребителя. Они эквивалентны.
Краткий обзор вариантов использования OAuth 2.0
Выбор типа предоставления доступа OAuth 2.0 зависит от конкретного сценария использования, поскольку некоторые типы предоставления доступа более безопасны, чем другие. Выбор типа предоставления доступа зависит от уровня доверия к клиентскому приложению и требует очень тщательного рассмотрения, как описано в следующей таблице:
| Вариант использования | Доверие | Рекомендуемые типы авторизации OAuth 2.0 | Описание |
|---|---|---|---|
| B2B (экстранет), интранет, прочее | Приложения, заслуживающие высокого доверия, разработанные внутренним разработчиком или разработчиками, имеющими доверительные деловые отношения с поставщиком API. Приложениям, которым необходимо получать доступ к ресурсам от своего имени. |
|
|
| Интранет-сайты, порталы | Надежные приложения, разработанные как собственными силами, так и проверенными сторонними разработчиками. Хороший пример — вход на сайт отдела кадров вашей компании для выбора страховых полисов, написания отзывов или изменения личной информации. |
|
|
| Общедоступные приложения | Ненадежные приложения создаются сторонними разработчиками, у которых нет доверительных деловых отношений с поставщиком API. Например, разработчикам, регистрирующимся в публичных программах API, как правило, нельзя доверять. |
|
|
| B2C | В процессе участвует отдельный конечный пользователь (пользователь мобильного устройства), а учетные данные пользователя хранятся на мобильном устройстве. |
|
|
OAuth 2.0 против безопасности с помощью API-ключей
Для проверки ключа API приложение должно отправить ключ в Edge. Ключ должен быть действительным ключом потребителя из приложения разработчика Apigee Edge, связанного с прокси-сервером API. Если по какой-либо причине вам необходимо отозвать разрешение клиентского приложения на выполнение вызовов к прокси-серверу, вы должны отозвать этот ключ потребителя. Любые клиентские приложения, использующие этот ключ, также не смогут получить доступ к прокси-серверу API. С другой стороны, токен OAuth можно отозвать в любое время без отзыва ключей приложения. Приложение может просто запросить новый токен от имени пользователя, и если токен будет предоставлен, приложение сможет продолжить использование прокси-сервера API.
Еще одно отличие ключа API от токена заключается в том, что токен может содержать метаданные, которые можно получить и использовать позже. Например, вы можете сохранить идентификатор пользователя, совершающего вызов API, и использовать его для настройки вызовов к целевому бэкэнд-сервису.
Подробную информацию о проверке ключей API см. в разделе «Ключи API» . Информацию об использовании пользовательских атрибутов с токенами OAuth см. в разделе «Настройка токенов и кодов авторизации» .