Вы просматриваете документацию 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 из самой спецификации 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.
- неявный — считается упрощенной версией кода авторизации. Обычно этот тип предоставления используется, когда приложение находится на клиенте. Например, код приложения реализуется в браузере с использованием 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.
Ограниченный доступ через области действия
Благодаря механизму областей 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 см. в разделе Настройка токенов и кодов авторизации .