Политика OAuthV2

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

Что

OAuthV2 — это многогранная политика для выполнения операций типа предоставления OAuth 2.0. Это основная политика, используемая для настройки конечных точек OAuth 2.0 в Apigee Edge.

Совет: Если вы хотите узнать больше об OAuth в Apigee Edge, посетите домашнюю страницу OAuth . Он предоставляет ссылки на ресурсы, образцы, видео и многое другое. См. пример расширенного OAuth на GitHub, чтобы наглядно продемонстрировать, как эта политика используется в работающем приложении.

Образцы

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2">
    <DisplayName>OAuth v2.0 2</DisplayName>
    <Operation>VerifyAccessToken</Operation>
    <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer -->
</OAuthV2>

$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

var client_id = context.getVariable("local_clientid");
var client_secret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(client_id + ':' + client_secret)));

См. также « Кодирование учетных данных базовой аутентификации ».

Ссылка на элемент

Справочник по политике описывает элементы и атрибуты политики OAuthV2.

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

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

Атрибуты <OAuthV2>

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

В следующей таблице описаны атрибуты, общие для всех родительских элементов политики:

Элемент <DisplayName>

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

<DisplayName>Policy Display Name</DisplayName>

Элемент <AccessToken>

<AccessToken>request.header.access_token</AccessToken>

По умолчанию VerifyAccessToken ожидает, что токен доступа будет отправлен в заголовке Authorization . Вы можете изменить это значение по умолчанию, используя этот элемент. Например, request.queryparam.access_token указывает, что токен доступа должен присутствовать как параметр запроса с именем access_token .

curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"

Элемент <AccessTokenPrefix>

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

По умолчанию VerifyAccessToken ожидает, что токен доступа будет отправлен в заголовке авторизации в качестве токена носителя. Например:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

В настоящее время Bearer является единственным поддерживаемым префиксом.

Элемент <AppEndUser>

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

В тех случаях, когда идентификатор конечного пользователя приложения необходимо отправить на сервер авторизации, этот элемент позволяет указать, где Edge должен искать идентификатор конечного пользователя. Например, его можно отправить как параметр запроса или в HTTP-заголовке.

Например, request.queryparam.app_enduser указывает, что AppEndUser должен присутствовать в качестве параметра запроса, как, например, ?app_enduser=ntesla@theramin.com . Например, чтобы потребовать AppEndUser в заголовке HTTP, установите для этого значения значение request.header.app_enduser .

Предоставление этого параметра позволяет включить идентификатор конечного пользователя приложения в токен доступа. Эта функция полезна, если вы хотите иметь возможность получать или отзывать токены доступа OAuth 2.0 по идентификатору конечного пользователя. Дополнительные сведения см. в разделе Включение получения и отзыва токенов доступа OAuth 2.0 по идентификатору конечного пользователя, идентификатору приложения или по тому и другому .

<Атрибуты/Атрибут>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

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

Этот элемент позволяет указать значение в переменной потока или в строке литерала. Если вы указываете и переменную, и строку, используется значение, указанное в переменной потока. Если переменную невозможно разрешить, строка используется по умолчанию.

Дополнительную информацию об использовании этого элемента см. в разделе Настройка токенов и кодов авторизации .

Отображение или скрытие пользовательских атрибутов в ответе

Помните, что если вы установите для элемента GenerateResponse этой политики значение true , в ответе будет возвращено полное JSON-представление токена, включая все заданные вами настраиваемые атрибуты. В некоторых случаях вам может потребоваться скрыть некоторые или все ваши настраиваемые атрибуты в ответе, чтобы они не были видны клиентским приложениям.

По умолчанию в ответе появляются пользовательские атрибуты. Если вы хотите их скрыть, вы можете установить для параметра display значение false . Например:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

Значение атрибута display не сохраняется. Допустим, вы создаете токен доступа с настраиваемыми атрибутами, которые хотите скрыть в сгенерированном ответе. Установка display=false достигает этой цели. Однако если новый токен доступа будет создан позже с использованием токена обновления, исходные пользовательские атрибуты токена доступа будут отображаться в ответе токена обновления. Это связано с тем, что Edge не помнит, что атрибут display изначально был установлен в false в политике создания токена доступа — пользовательский атрибут является просто частью метаданных токена доступа.

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

Чтобы скрыть пользовательские атрибуты в этих случаях, у вас есть следующие варианты:

• Явно сбросьте настраиваемые атрибуты в политике токена обновления и установите для них значение false. В этом случае вам может потребоваться получить исходные пользовательские значения из исходного токена доступа с помощью политики GetOAuthV2Info.
• Используйте политику постобработки JavaScript, чтобы вручную извлечь любые пользовательские атрибуты, которые вы не хотите видеть в ответе.

См. также Настройка токенов и кодов авторизации .

Элемент <ClientId>

<ClientId>request.formparam.client_id</ClientId>

В некоторых случаях клиентское приложение должно отправить идентификатор клиента на сервер авторизации. Этот элемент указывает, что Apigee должен искать идентификатор клиента в переменной потока request.formparam.client_id . Установка ClientId в любую другую переменную не поддерживается. См. также Запрос токенов доступа и кодов авторизации .

Элемент <Код>

<Code>request.queryparam.code</Code>

В потоке типа предоставления авторизации клиент должен отправить код авторизации на сервер авторизации (Apigee Edge). Этот элемент позволяет указать, где Edge должен искать код авторизации. Например, его можно отправить как параметр запроса, HTTP-заголовок или параметр формы (по умолчанию).

Переменная request.queryparam.auth_code указывает, что код авторизации должен присутствовать в качестве параметра запроса, как, например, ?auth_code=AfGlvs9 . Например, чтобы запросить код авторизации в заголовке HTTP, установите для этого значения значение request.header.auth_code . См. также Запрос токенов доступа и кодов авторизации .

Элемент <ExpiresIn>

<ExpiresIn>10000</ExpiresIn> 

Обеспечивает срок действия токенов доступа и кодов авторизации в миллисекундах. (Для токенов обновления используйте <RefreshTokenExpiresIn> .) Значение времени истечения срока действия — это значение, созданное системой, плюс значение <ExpiresIn> . Если для <ExpiresIn> установлено значение -1 , срок действия токена или кода истекает в соответствии с максимальным сроком действия токена доступа OAuth . Если <ExpiresIn> не указан, система применяет значение по умолчанию, настроенное на уровне системы.

Время истечения срока действия также можно установить во время выполнения, используя либо жестко запрограммированное значение по умолчанию, либо путем ссылки на переменную потока. Например, вы можете сохранить значение срока действия токена в карте значений ключей, получить его, назначить переменной и ссылаться на него в политике. Например, kvm.oauth.expires_in .

При использовании Apigee Edge для публичного облака Edge сохраняет следующие объекты в кэше в течение как минимум 180 секунд после доступа к объектам.

• Токены доступа OAuth. Это означает, что отозванный токен может быть успешным в течение трех минут, пока не истечет срок его кэша.
• Объекты службы управления ключами (KMS) (приложения, разработчики, продукты API).
• Пользовательские атрибуты токенов OAuth и объектов KMS.

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

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

Edge не поддерживает способ принудительного истечения срока действия токена после его создания. Если вам необходимо принудительно истечь срок действия токена (например, на основании какого-либо условия), возможное решение описано в этом сообщении сообщества Apigee .

По умолчанию токены доступа с истекшим сроком действия автоматически удаляются из системы Apigee Edge через 3 дня после истечения срока действия. См. также Очистка токенов доступа.

Частное облако: для установки Edge for Private Cloud значение по умолчанию задается свойством conf_keymanagement_oauth_auth_code_expiry_time_in_millis . Чтобы установить это свойство:

1. Откройте файл message-processor.properties в редакторе. Если файл не существует, создайте его:

   vi /opt/apigee/customer/application/message-processor.properties

2. Установите свойство по желанию:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. Убедитесь, что файл свойств принадлежит пользователю «apigee»:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Перезапустите процессор сообщений.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Элемент <ExternalAccessToken>

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Сообщает Apigee Edge, где найти внешний токен доступа (токен доступа, не созданный Apigee Edge).

Переменная request.queryparam.external_access_token указывает, что токен внешнего доступа должен присутствовать в качестве параметра запроса, как, например, ?external_access_token=12345678 . Например, чтобы запросить внешний токен доступа в заголовке HTTP, установите для этого значения значение request.header.external_access_token . См. также Использование сторонних токенов OAuth .

Элемент <ExternalAuthorization>

<ExternalAuthorization>true</ExternalAuthorization>

Если этот элемент имеет значение false или отсутствует, Edge обычно проверяет client_id и client_secret в хранилище авторизации Apigee Edge. Используйте этот элемент, если хотите работать со сторонними токенами OAuth. Подробную информацию об использовании этого элемента см. в разделе Использование сторонних токенов OAuth .

Элемент <ExternalAuthorizationCode>

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Сообщает Apigee Edge, где найти внешний код аутентификации (код аутентификации, не созданный Apigee Edge).

Переменная request.queryparam.external_auth_code указывает, что внешний код аутентификации должен присутствовать в качестве параметра запроса, как, например, ?external_auth_code=12345678 . Например, чтобы потребовать внешний код аутентификации в заголовке HTTP, установите для этого значения значение request.header.external_auth_code . См. также Использование сторонних токенов OAuth .

Элемент <ExternalRefreshToken>

<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>

Сообщает Apigee Edge, где найти внешний токен обновления (токен обновления, не созданный Apigee Edge).

Переменная request.queryparam.external_refresh_token указывает, что внешний токен обновления должен присутствовать в качестве параметра запроса, как, например, ?external_refresh_token=12345678 . Например, чтобы потребовать внешний токен обновления в заголовке HTTP, установите для этого значения значение request.header.external_refresh_token . См. также Использование сторонних токенов OAuth .

Элемент <GenerateResponse>

<GenerateResponse enabled='true'/>

Если установлено значение true , политика генерирует и возвращает ответ. Например, для GenerateAccessToken ответ может быть таким:

{
  "issued_at" : "1467841035013",
  "scope" : "read",
  "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930",
  "refresh_token_issued_at" : "1467841035013",
  "status" : "approved",
  "refresh_token_status" : "approved",
  "api_product_list" : "[Product1, nhl_product]",
  "expires_in" : "1799",
  "developer.email" : "edward@slalom.org",
  "token_type" : "BearerToken",
  "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ",
  "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj",
  "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a",
  "organization_name" : "cerruti",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Если false , ответ не отправляется. Вместо этого набор переменных потока заполняется значениями, связанными с функцией политики. Например, переменная потока с именем oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code заполняется новым кодом аутентификации. Обратите внимание, что expires_in в ответе выражается в секундах.

Элемент <GenerateErrorResponse>

<GenerateErrorResponse enabled='true'/>

Если установлено значение true , политика генерирует и возвращает ответ, если для атрибута ContinueOnError установлено значение true. Если false (по умолчанию), ответ не отправляется. Вместо этого набор переменных потока заполняется значениями, связанными с функцией политики.

<Тип Гранта>

<GrantType>request.queryparam.grant_type</GrantType>

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

Например, request.queryparam.grant_type указывает, что пароль должен присутствовать в качестве параметра запроса, как, например, ?grant_type=password . Например, чтобы указать тип предоставления в заголовке HTTP, установите для этого значения значение request.header.grant_type . См. также Запрос токенов доступа и кодов авторизации .

Элемент <Операция>

<Operation>GenerateAuthorizationCode</Operation>

Операция OAuth 2.0, выполняемая политикой.

Элемент <Пароль>

<PassWord>request.queryparam.password</PassWord>

Этот элемент используется только с типом предоставления пароля . При выборе типа предоставления пароля учетные данные пользователя (пароль и имя пользователя) должны быть доступны для политики OAuthV2. Элементы <PassWord> и <UserName> используются для указания переменных, в которых Edge может найти эти значения. Если эти элементы не указаны, политика ожидает найти значения (по умолчанию) в параметрах формы с именами username и password . Если значения не найдены, политика выдает ошибку. Вы можете использовать элементы <PassWord> и <UserName> для ссылки на любую переменную потока, содержащую учетные данные.

Например, вы можете передать пароль в запросе токена, используя параметр запроса, и установить элемент следующим образом: <PassWord>request.queryparam.password</PassWord> . Чтобы запросить пароль в заголовке HTTP, установите для этого значения значение request.header.password .

Политика OAuthV2 больше ничего не делает с этими значениями учетных данных; Edge просто проверяет их наличие. Разработчик API должен получить запрос значений и отправить их поставщику удостоверений до того, как будет выполнена политика генерации токенов.

См. также Запрос токенов доступа и кодов авторизации .

Элемент <RedirectUri>

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

Указывает, где Edge должен искать параметр redirect_uri в запросе.

Об URI перенаправления

URI перенаправления используются с кодом авторизации и неявными типами предоставления. URI перенаправления сообщает серверу авторизации (Edge), куда отправить код авторизации (для типа предоставления кода аутентификации) или токен доступа (для неявного типа предоставления). Важно понимать, когда этот параметр обязателен, когда он необязателен и как он используется:

• (обязательно) Если URL-адрес обратного вызова зарегистрирован в приложении разработчика, связанном с клиентскими ключами запроса, и если в запросе присутствует redirect_uri , то они должны точно совпадать. Если они не совпадают, возвращается ошибка. Информацию о регистрации приложений разработчика в Edge и указании URL-адреса обратного вызова см. в разделе Регистрация приложений и управление ключами API .

• (необязательно) Если URL-адрес обратного вызова зарегистрирован, а redirect_uri отсутствует в запросе, Edge перенаправляет на зарегистрированный URL-адрес обратного вызова.
• (обязательно) Если URL-адрес обратного вызова не зарегистрирован, необходимо указать redirect_uri . Обратите внимание, что в этом случае Edge примет ЛЮБОЙ URL-адрес. В этом случае может возникнуть проблема с безопасностью, поэтому его следует использовать только с доверенными клиентскими приложениями. Если клиентские приложения не вызывают доверия, рекомендуется всегда требовать регистрацию URL-адреса обратного вызова.

Вы можете отправить этот параметр в параметре запроса или в заголовке. Переменная request.queryparam.redirect_uri указывает, что RedirectUri должен присутствовать в качестве параметра запроса, как, например, ?redirect_uri=login.myapp.com . Например, чтобы потребовать RedirectUri в заголовке HTTP, установите для этого значения значение request.header.redirect_uri . См. также Запрос токенов доступа и кодов авторизации .

Элемент <RefreshToken>

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

При запросе токена доступа с использованием токена обновления вы должны указать токен обновления в запросе. Этот элемент позволяет указать, где Edge должен искать токен обновления. Например, его можно отправить как параметр запроса, HTTP-заголовок или параметр формы (по умолчанию).

Переменная request.queryparam.refreshtoken указывает, что токен обновления должен присутствовать в качестве параметра запроса, как, например, ?refresh_token=login.myapp.com . Например, чтобы требовать RefreshToken в заголовке HTTP, установите для этого значения значение request.header.refresh_token . См. также Запрос токенов доступа и кодов авторизации .

Элемент <RefreshTokenExpiresIn>

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Устанавливает срок действия токенов обновления в миллисекундах. Значение времени истечения срока действия — это значение, созданное системой, плюс значение <RefreshTokenExpiresIn> . Если для <RefreshTokenExpiresIn> установлено значение -1 , срок действия токена обновления истекает в соответствии с максимальным сроком действия токена обновления OAuth . Если <RefreshTokenExpiresIn> не указан, система применяет значение по умолчанию, настроенное на уровне системы. Свяжитесь со службой поддержки Apigee Edge для получения дополнительной информации о настройках системы по умолчанию.

Время истечения срока действия также можно установить во время выполнения, используя либо жестко запрограммированное значение по умолчанию, либо путем ссылки на переменную потока. Например, вы можете сохранить значение срока действия токена в карте значений ключей, получить его, назначить переменной и ссылаться на него в политике. Например, kvm.oauth.expires_in .

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

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</RefreshTokenExpiresIn>

Частное облако: для установки Edge для частного облака значение по умолчанию задается свойством conf_keymanagement_oauth_refresh_token_expiry_time_in_millis . Чтобы установить это свойство:

1. Откройте файл message-processor.properties в редакторе. Если файл не существует, создайте его:

   vi /opt/apigee/customer/application/message-processor.properties

2. Установите свойство по желанию:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. Убедитесь, что файл свойств принадлежит пользователю «apigee»:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Перезапустите процессор сообщений.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Элемент <ResponseType>

<ResponseType>request.queryparam.response_type</ResponseType>

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

По умолчанию Edge ищет значение типа ответа в параметре запроса response_type . Если вы хотите переопределить это поведение по умолчанию, используйте элемент <ResponseType> для настройки переменной потока, содержащей значение типа ответа. Например, если вы установите для этого элемента значение request.header.response_type , Edge будет искать тип ответа, который будет передан в заголовке запроса. См. также Запрос токенов доступа и кодов авторизации .

Элемент <ReuseRefreshToken>

<ReuseRefreshToken>true</ReuseRefreshToken>

Если установлено значение true , существующий токен обновления используется повторно до истечения срока его действия. Если false , Apigee Edge выдает новый токен обновления при представлении действительного токена обновления.

Элемент <Область>

<Scope>request.queryparam.scope</Scope>

Если этот элемент присутствует в одной из политик GenerateAccessToken или GenerateAuthorizationCode, он используется для указания того, каким областям следует предоставить токен или код. Эти значения обычно передаются в политику в запросе от клиентского приложения. Вы можете настроить элемент на прием переменной потока, что дает вам возможность выбирать, как области передаются в запросе. В следующем примере request.queryparam.scope указывает, что область должна присутствовать в качестве параметра запроса, как, например, ?scope=READ . Например, чтобы потребовать область действия в заголовке HTTP, установите для этого значения значение request.header.scope .

Если этот элемент присутствует в политике VerifyAccessToken, он используется для указания областей, которые должна применять политика. В политике этого типа значение должно быть «жестко закодированным» именем области — вы не можете использовать переменные. Например:

<Scope>A B</Scope>

См. также разделы «Работа с областями OAuth2» и «Запрос токенов доступа и кодов авторизации» .

Элемент <Состояние>

<State>request.queryparam.state</State>

В тех случаях, когда клиентское приложение должно отправлять информацию о состоянии на сервер авторизации, этот элемент позволяет указать, где Edge должен искать значения состояния. Например, его можно отправить как параметр запроса или в HTTP-заголовке. Значение состояния обычно используется в качестве меры безопасности для предотвращения атак CSRF.

Например, request.queryparam.state указывает, что состояние должно присутствовать в качестве параметра запроса, как, например, ?state=HjoiuKJH32 . Например, чтобы запросить состояние в заголовке HTTP, установите для этого значения значение request.header.state . См. также См. также Запрос токенов доступа и кодов авторизации .

Элемент <StoreToken>

 <StoreToken>true</StoreToken> 

Установите для этого элемента значение true если элемент <ExternalAuthorization> имеет true . Элемент <StoreToken> сообщает Apigee Edge о необходимости сохранить токен внешнего доступа. В противном случае он не будет сохранен.

Элемент <SupportedGrantTypes>/<GrantType>

<SupportedGrantTypes>
    <GrantType>authorization_code</GrantType>
    <GrantType>client_credentials</GrantType>
    <GrantType>implicit</GrantType>
    <GrantType>password</GrantType>
</SupportedGrantTypes>

Указывает типы грантов, поддерживаемые конечной точкой токена OAuth в Apigee Edge. Конечная точка может поддерживать несколько типов грантов (то есть одну конечную точку можно настроить для распространения токенов доступа для нескольких типов грантов). Дополнительные сведения о конечных точках см. в разделе Общие сведения о конечных точках OAuth . Тип гранта передается в запросах токена в grant_type .

Если не указаны поддерживаемые типы разрешений, то разрешенными типами разрешений являются authorization_code и implicit . См. также элемент <GrantType> (который является элементом более высокого уровня, который используется для указания того, где Apigee Edge должен искать параметр grant_type , передаваемый в клиентском запросе. Edge будет следить за тем, чтобы значение параметра grant_type соответствовало единице). поддерживаемых типов грантов).

Элемент <Tokens>/<Token>

Используется с операциями ValidateToken и InvalidateToken. См. также Утверждение и отзыв токенов доступа . Элемент <Token> идентифицирует переменную потока, которая определяет источник отзываемого токена. Например, если ожидается, что разработчики будут отправлять токены доступа в качестве параметров запроса с именем access_token , используйте request.queryparam.access_token .

Элемент <имя_пользователя>

<UserName>request.queryparam.user_name</UserName>

Этот элемент используется только с типом предоставления пароля . При выборе типа предоставления пароля учетные данные пользователя (пароль и имя пользователя) должны быть доступны политике OAuthV2. Элементы <PassWord> и <UserName> используются для указания переменных, в которых Edge может найти эти значения. Если эти элементы не указаны, политика ожидает найти значения (по умолчанию) в параметрах формы с именами username и password . Если значения не найдены, политика выдает ошибку. Вы можете использовать элементы <PassWord> и <UserName> для ссылки на любую переменную потока, содержащую учетные данные.

Например, вы можете передать имя пользователя в параметре запроса и установить элемент <UserName> , как это: <UserName>request.queryparam.username</UserName> . Чтобы потребовать имя пользователя в заголовке HTTP, установите это значение для request.header.username . Header.username.

Политика OAuthv2 ничего не делает с этими ценностями учетных данных; Край просто проверяет, что они присутствуют. Разработчик API должен получить запрос на значения и отправить их поставщику идентификации до выполнения политики генерации токенов.

См. Также с просьбой запрашивать токены доступа и коды авторизации .

Проверка токенов доступа

После того, как конечная точка токена установлена ​​для прокси -сервера API, соответствующая политика OAuthv2, которая указывает на операцию VerifyAccessToken , прикреплена к потоку, который выявляет защищенный ресурс.

Например, чтобы убедиться, что все запросы на API разрешаются, следующая политика обеспечивает проверку токена доступа:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Политика прикреплена к ресурсу API, который будет защищен. Чтобы гарантировать, что все запросы на API проверены, прикрепите политику к предварительному предварительному предварительному обращению к запросу ProxyendPoint следующим образом:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthAccessToken</Name></Step>
  </Request>
</PreFlow>

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

<OAuthV2 name="ValidateOauthScopePolicy">
  <Operation>VerifyAccessToken</Operation>
  <Scope>READ WRITE</Scope>
</OAuthV2>

См. Также проверка токенов доступа и запрос токенов доступа и кодов авторизации .

Определение местоположений переменных запроса

Для каждого типа гранта политика делает предположения о местоположении или необходимой информации в сообщениях запроса. Эти предположения основаны на спецификации OAuth 2.0. Если ваши приложения должны отклониться от спецификации OAuth 2.0, вы можете указать ожидаемые местоположения для каждого параметра. Например, при обработке кода авторизации вы можете указать местоположение кода авторизации, идентификатор клиента, URI перенаправления и область применения. Они могут быть указаны как заголовки HTTP, параметры запроса или параметры формы.

Приведенный ниже пример демонстрирует, как вы можете указать местоположение необходимых параметров кода авторизации как заголовки HTTP:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.header.client_id</ClientId>
  <RedirectUri>request.header.redirect_uri</RedirectUri>
  <Scope>request.header.scope</Scope>
  ...

Или, если необходимо, для поддержки базы приложений клиента, вы можете смешать и соответствовать заголовкам и параметрам запроса:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
  ...

Только одно местоположение может быть настроено на параметр.

Переменные потока

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

VerifyAccessToken Operation

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

Токен-специфические переменные

Приложение-специфические переменные

Эти переменные связаны с приложением разработчика, которое связано с токеном.

Специфичные для разработчика переменные

Если App.Apptype является «компанией», то атрибуты компании заполняются, и если App.Apptype является «разработчиком», то атрибуты разработчика заполняются.

Компания, переменные

Если App.Apptype является «компанией», то атрибуты компании заполняются, и если App.Apptype является «разработчиком», то атрибуты разработчика заполняются.

Работа об generateauthorizationCode

Эти переменные устанавливаются, когда операция GenerateAuthorizationCode успешно выполняется:

Prefix: oauthv2authcode.{policy_name}.{variable_name}

Пример: oauthv2authcode.GenerateCodePolicy.code

GenerateAccessToken и OperreshaccessToken

Эти переменные устанавливаются, когда операции GenerateAccessToken и RefreshaccessToken успешно выполняются. Обратите внимание, что переменные токена обновления не применяются для потока грантов клиента.

Prefix: oauthv2accesstoken.{policy_name}.{variable_name}

Пример: oauthv2accesstoken.GenerateTokenPolicy.access_token

GenerateAccesstokenimplicitgrant

Эти переменные устанавливаются, когда операция GenerateAccessTokenImplicit успешно выполняется для неявного потока типа гранта.

Prefix: oauthv2accesstoken.{policy_name}.{variable_name}

Пример: oauthv2accesstoken.RefreshTokenPolicy.access_token

Ссылка на ошибку

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые устанавливаются Edge, когда эта политика вызывает ошибку. Эту информацию важно знать, если вы разрабатываете правила обработки ошибок. Дополнительные сведения см. в разделах Что нужно знать об ошибках политики и Обработка ошибок .

Ошибки выполнения

Эти ошибки могут возникнуть при выполнении политики.

Ошибки развертывания

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

Переменные неисправности

Эти переменные устанавливаются, когда эта политика вызывает ошибку во время выполнения.

Пример ответа об ошибке

Эти ответы отправляются обратно клиенту, если элемент <GenerateResponse> имеет значение true .

Если <GenerateResponse> имеет значение true , политика возвращает ошибки в этом формате для операций, генерирующих токены и коды. Полный список см. в разделе «Справочник по ответам на ошибки HTTP OAuth» .

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

Если <GenerateResponse> имеет значение true , политика возвращает ошибки в этом формате для операций проверки и проверки. Полный список см. в разделе «Справочник по ответам на ошибки HTTP OAuth» .

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

Пример правила неисправности

<FaultRule name=OAuthV2 Faults">
    <Step>
        <Name>AM-InvalidClientResponse</Name>
        <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition>
    </Step>
    <Step>
        <Name>AM-InvalidTokenResponse</Name>
        <Condition>(fault.name = "invalid_access_token")</Condition>
    </Step>
    <Condition>(oauthV2.failed = true) </Condition>
</FaultRule>

Политическая схема

Каждый тип политики определяется схемой XML ( .xsd ). Для справки, схемы политики доступны на GitHub.

Работа с конфигурацией OAuth по умолчанию

Каждая организация (даже бесплатная судебная организация) на Apigee Edge обеспечивается конечной точкой токена OAuth. Конечная точка предварительно настроена с политикой в ​​прокси API под названием OAuth . Вы можете начать использовать конечную точку токена, как только вы создадите учетную запись на Apigee Edge . Для получения подробной информации см. Понимание конечных точек OAuth .

Очищение токенов доступа

По умолчанию токены OAuth2 очищаются из системы Apigee Edge 3 дня (259200 секунд) после истечения срока как токена доступа, так и токена обновления (если она существует). В некоторых случаях вы можете изменить это по умолчанию. Например, вы можете сократить время чистки, чтобы сэкономить пространство диска, если генерируется большое количество токенов.

Если вы находитесь на грани частного облака , вы можете изменить это значение по умолчанию, установив свойства организации, как объяснено в этом разделе. (Трехдневная чистка истекших токенов применяется к Edge для частного облака версии 4.19.01, а затем. Для более ранних версий интервал чистки по умолчанию составляет 180 дней.)

Обновление настроек чистки для Edge Private Cloud 4.16.01 и более поздних версий

Примечание: только токены, сгенерированные после применения этих настроек; Настройки не применяются к токенам, которые были сгенерированы ранее.

Обновление настроек чистки для Edge Private Cloud 4.15.07

Примечание: только токены, сгенерированные после применения этих настроек; Настройки не применяются к токенам, которые были сгенерированы ранее.

Не совместимое с RFC поведение

Политика OAuthv2 возвращает реакцию токена, который содержит определенные не соответствующие RFC свойства. В следующей таблице показаны не соответствующие свойства, возвращаемые политикой OAuthv2 и соответствующими соответствующими свойствами.

Кроме того, ответ ошибки для истекшего токена обновления, когда grant_type = refresh_token :

{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}

Тем не менее, ответ RFC-совместимый:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

Связанные темы

• Введение в OAuth 2.0