Política de OAuthV2

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Qué

OAuthV2 es una política multifacética para realizar operaciones de tipo de otorgamiento de OAuth 2.0. Este es el política principal usada para configurar extremos de OAuth 2.0 en Apigee Edge.

Sugerencia: Si deseas obtener más información sobre OAuth en Apigee Edge, consulta la página principal de OAuth. Proporciona vínculos a recursos, muestras, videos y mucho más. Consulta las funciones avanzadas de OAuth en GitHub para obtener una buena demostración de cómo se usa esta política en un entorno y mantener la integridad de su aplicación.

Ejemplos

<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)));

Consulta también "Codificación básica credenciales de autenticación”.

Referencia de elementos

La referencia de política describe los elementos y atributos de la política OAuthV2.

La política de muestra que se presenta a continuación es una de las muchas configuraciones posibles. En esta muestra, se presenta una política de OAuthV2 configurada para la operación GenerateAccessToken. Incluye elementos obligatorios y opcionales. Consulta las descripciones de los elementos en esta sección para obtener más detalles.

<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>

Atributos de <OAuthV2>

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

En la siguiente tabla, se describen los atributos que son comunes a todos los elementos principales de las políticas:

Elemento <DisplayName>

Se usan además del atributo name para etiquetar la política en el editor de proxy de la IU de administración con un nombre de lenguaje natural diferente.

<DisplayName>Policy Display Name</DisplayName>

Elemento <AccessToken>

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

De forma predeterminada, VerifyAccessToken espera que se envíe el token de acceso en el encabezado Authorization. Puedes cambiar ese valor predeterminado con este elemento. Por ejemplo, request.queryparam.access_token indica que el token de acceso debe estar presente como un parámetro de consulta llamado 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"

Elemento <AccessTokenPrefix>

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

De forma predeterminada, VerifyAccessToken espera que el token de acceso se envíe en un encabezado de autorización como un token del portador. Por ejemplo:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

Por el momento, el portador es el único prefijo admitido.

Elemento <AppEndUser>

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

Cuando se debe enviar el ID de usuario final de la aplicación al servidor de autorización, este elemento debes especificar dónde debe buscar Edge para encontrar el ID del usuario final. Por ejemplo, podría enviarse como parámetro de consulta o en un encabezado HTTP.

Por ejemplo, request.queryparam.app_enduser indica que AppEndUser debe estar presente como un parámetro de consulta, por ejemplo, ?app_enduser=ntesla@theramin.com. Para solicitar el AppEndUser en un encabezado HTTP, por ejemplo, configura este valor como request.header.app_enduser.

Proporcionar esta configuración te permite incluir un ID de usuario final de la app en el token de acceso. Esta función es útil si deseas recuperar o revocar tokens de acceso de OAuth 2.0 por ID de usuario final. Para obtener más información, consulta Habilita la recuperación y revocación de tokens de acceso de OAuth 2.0 por ID de usuario final, ID de LA app o ambos.

<Atributos/Atributo>

<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>

Usa este elemento para agregar atributos personalizados a un token de acceso o código de autorización. Por ejemplo, es posible que desees incorporar un ID de usuario o identificador de sesión en un token de acceso que se puede extraer y verificar en el entorno de ejecución.

Este elemento te permite especificar un valor en una variable de flujo o desde una string literal. Si especificas una variable y una string, se usa el valor especificado en la variable de flujo. Si la variable no se puede resolver, la string es la predeterminada.

Si deseas obtener más información para usar este elemento, consulta Personaliza tokens y códigos de autorización.

Muestra u oculta atributos personalizados en la respuesta

Recuerda que si configuras el elemento GenerateResponse de esta política como true, la representación JSON completa del token se mostrará en la respuesta, incluidos los atributos personalizados que establezcas. En algunos casos, te recomendamos ocultar algunos o todos tus atributos personalizados en la respuesta para que no sean visibles para las apps cliente.

De forma predeterminada, los atributos personalizados aparecen en la respuesta. Si deseas ocultarlos, puedes establecer el parámetro display en false. Por ejemplo:

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

El valor del atributo display no es persistente. Supongamos que generas un token de acceso con atributos personalizados que deseas ocultar en la respuesta generada. Establecer display=false logra ese objetivo. Sin embargo, si se genera un nuevo token de acceso más adelante con un token de actualización, los atributos personalizados originales del token de acceso aparecerán en la respuesta del token de actualización. Esto se debe a que Edge no recuerda el atributo display se configuró originalmente como false en la política para generar tokens de acceso, el es simplemente parte de los metadatos del token de acceso.

Verás el mismo comportamiento si agregas atributos personalizados a un código de autorización: cuando se genera un token de acceso con ese código, esos atributos personalizados se mostrarán en la respuesta del token de acceso. Una vez más, es posible que este no sea el comportamiento que pretendes.

Para ocultar los atributos personalizados en estos casos, tienes las siguientes opciones:

• Restablece de forma explícita los atributos personalizados de la política de token de actualización y configura su pantalla como false. En este caso, es posible que debas recuperar los valores personalizados originales del token de acceso original con la política GetOAuthV2Info.
• Usa una política de procesamiento posterior de JavaScript para extraer de forma manual cualquier atributo personalizado que no desees ver en la respuesta.

Consulta también Personaliza tokens y códigos de autorización.

Elemento <ClientId>

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

En varios casos, la app cliente debe enviar el ID de cliente al servidor de autorización. Esta te permite especificar dónde debe buscar Edge para encontrar el ID de cliente. La única ubicación válida que puedes establecer es la ubicación predeterminada, la variable de flujo request.formparam.client_id. No se puede configurar ClientId en cualquier otra variable. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <Code>

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

En el flujo de tipo de otorgamiento de autorización, el cliente debe enviar un código de autorización al de autorización (Apigee Edge). Este elemento te permite especificar dónde debe buscar Edge código de autorización. Por ejemplo, podría enviarse como un parámetro de consulta, un encabezado HTTP o un parámetro de forma (predeterminado).

La variable request.queryparam.auth_code indica que el código de autorización debe estar presente como un parámetro de consulta, por ejemplo, ?auth_code=AfGlvs9. Para solicitar el código de autorización en un encabezado HTTP, por ejemplo, establece este valor en request.header.auth_code. Consulta también Solicita tokens de acceso y códigos de autorización.

elemento <ExpiresIn>

<ExpiresIn>10000</ExpiresIn> 

Aplica la hora de vencimiento de los tokens de acceso y códigos de autorización en milisegundos. (Para actualizar tokens, usa <RefreshTokenExpiresIn>). El valor de la hora de vencimiento es un el valor generado por el sistema más el valor <ExpiresIn>. Si <ExpiresIn> se establece en -1; el token o el código vencerá según el vencimiento máximo del token de acceso de OAuth. Si no se especifica <ExpiresIn>, el sistema aplica un valor predeterminado configurado a nivel del sistema.

La hora de vencimiento también se puede configurar en el entorno de ejecución con un hard-coded, un valor predeterminado o mediante la referencia a una variable de flujo. Por ejemplo, puedes almacenar un valor de vencimiento de token en un mapa de par clave-valor, recuperarlo, asignarlo a una variable y hacer referencia a él en la política. Por ejemplo, kvm.oauth.expires_in.

Con Apigee Edge para la nube pública, Edge mantiene las Seguir las entidades en caché durante un mínimo de 180 segundos después de que se acceda a ellas.

• Tokens de acceso de OAuth. Esto significa que un token revocado puede seguir funcionando correctamente durante un máximo de tres minutos, hasta que caduque el límite.
• Entidades del servicio de administración de claves (KMS) (apps, desarrolladores, productos de API).
• Atributos personalizados de entidades de KMS y tokens de OAuth.

En la siguiente estrofa, se especifica una variable de flujo y, también, un valor predeterminado. Ten en cuenta que el valor de la variable de flujo tiene prioridad sobre el valor predeterminado especificado.

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

Edge no admite una forma de forzar el vencimiento de un token una vez que se crea. Si necesitas forzar el vencimiento del token (por ejemplo, basado en una condición), se describe una solución posible en esta publicación de la comunidad de Apigee.

De forma predeterminada, los tokens de acceso vencidos se borran definitivamente del espacio de nombres de Apigee El sistema perimetral automáticamente 3 días después del vencimiento. Consulta también Borrar definitivamente tokens de acceso

Nube privada: Para una instalación perimetral para la nube privada, la configuración valor lo establece la propiedad conf_keymanagement_oauth_auth_code_expiry_time_in_millis. Para configurar esta propiedad, sigue estos pasos:

1. Abre el archivo message-processor.properties en un editor. Si el archivo no existe, créalo:

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

2. Configura la propiedad como desees:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. Asegúrate de que el archivo de propiedades sea propiedad de “apigee” usuario:

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

4. Reinicia el procesador de mensajes.

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

Elemento <ExternalAccessToken>

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

Le indica a Apigee Edge dónde encontrar un token de acceso externo (un token de acceso que no generó Apigee Edge).

La variable request.queryparam.external_access_token indica que el token de acceso externo debe estar presente como un parámetro de consulta, por ejemplo, ?external_access_token=12345678. Para solicitar el token de acceso externo en un encabezado HTTP, por ejemplo, establece este valor en request.header.external_access_token. Consulta también el Usa tokens OAuth de terceros.

Elemento <ExternalAuthorization>

<ExternalAuthorization>true</ExternalAuthorization>

Si este elemento es falso o no está presente, Edge valida el client_id y client_secret normalmente en el almacén de autorización de Apigee Edge. Usa este elemento cuando desees trabajar con tokens OAuth de terceros. Para obtener detalles sobre el uso de este elemento, consulta Usa tokens de OAuth de terceros.

Elemento <ExternalAuthorizationCode>

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

Le indica a Apigee Edge dónde encontrar un código de Auth externo (un código de Auth que no genera Apigee Edge).

La variable request.queryparam.external_auth_code indica que el código de autenticación externo debe estar presente como un parámetro de consulta, por ejemplo, ?external_auth_code=12345678. Para solicitar el código de autenticación externo en un encabezado HTTP, por ejemplo, establece este valor en request.header.external_auth_code. Consulta también el Usa tokens OAuth de terceros.

Elemento <ExternalRefreshToken>

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

Le indica a Apigee Edge dónde encontrar un token de actualización externo (un token de actualización que no generó Apigee Edge).

La variable request.queryparam.external_refresh_token indica que el token de actualización externo debe estar presente como un parámetro de consulta, por ejemplo, ?external_refresh_token=12345678. Para solicitar el token de actualización externo en un encabezado HTTP, por ejemplo, establece este valor en request.header.external_refresh_token. Consulta también el Usa tokens OAuth de terceros.

Elemento <GenerateResponse>

<GenerateResponse enabled='true'/>

Si se configura como true, la política genera y muestra una respuesta. Por ejemplo, para GenerateAccessToken, la respuesta podría ser la siguiente:

{
  "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"
}

Si es false, no se envía ninguna respuesta. En su lugar, un conjunto de variables de flujo se propaga con valores relacionados con la función de la política. Por ejemplo, una variable de flujo llamada oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code se propaga con el nuevo código de autenticación. Ten en cuenta que expires_in se expresa en segundos en la respuesta.

Elemento <GenerateErrorResponse>

<GenerateErrorResponse enabled='true'/>

Si se configura como true, la política genera y muestra una respuesta si el atributo ContinueOnError se establece como verdadero. Si false (el valor predeterminado), no se envía ninguna respuesta. En su lugar, un conjunto de variables de flujo se propaga con valores relacionados con la función de la política.

<GrantType>

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

Indica a la política dónde buscar el parámetro de tipo de concesión que se pasa en una solicitud. Según la especificación OAuth 2.0, el tipo de concesión debe proporcionar solicitudes para tokens de acceso y códigos de autorización. La variable puede ser un encabezado, un parámetro de consulta o un parámetro de forma (predeterminado).

Por ejemplo, request.queryparam.grant_type indica que la contraseña debe estar presente como un parámetro de búsqueda, por ejemplo, ?grant_type=password. Para requerir el tipo de concesión en un encabezado HTTP, por ejemplo, establece este valor en request.header.grant_type. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <Operation>

<Operation>GenerateAuthorizationCode</Operation>

La operación de OAuth 2.0 que ejecuta la política.

Elemento <PassWord>

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

Este elemento se usa solo con el tipo de otorgamiento de contraseña. Con el tipo de otorgamiento de contraseña, las credenciales de usuario (contraseña y nombre de usuario) deben estar disponibles para la política de OAuthV2. Los elementos <PassWord> y <UserName> son para especificar variables en las que Edge puede encontrar estos valores. Si no se especifican estos elementos, la política espera encontrar los valores (de forma predeterminada) en los parámetros de formulario llamados username y password. Si no se encuentran los valores, la política muestra un error. Puedes usar los elementos <PassWord> y <UserName> para hacer referencia a cualquier variable de flujo que contenga las credenciales.

Por ejemplo, puedes pasar la contraseña en una solicitud de token con un parámetro de consulta y configurar el elemento de esta manera: <PassWord>request.queryparam.password</PassWord>.. Para solicitar la contraseña en un encabezado HTTP, configura este valor en request.header.password.

La política OAuthV2 no hace nada más con estos valores de credenciales. Edge solo es para verificar que estén presentes. Depende del desarrollador de la API recuperar la solicitud de valores y enviarla a un proveedor de identidad antes de que se ejecute la política de generación de tokens.

Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <RedirectUri>

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

Especifica en qué lugar Edge debe buscar el parámetro redirect_uri en la para cada solicitud.

Acerca de los URI de redireccionamiento

Los URI de redireccionamiento se usan con el código de autorización y los tipos de concesión implícitos. El redireccionamiento El URI le indica al servidor de autorización (Edge) dónde enviar un código de autorización (para el código de autorización) tipo de otorgamiento) o token de acceso (para el tipo de otorgamiento implícito). Es importante comprender cuándo se requiere este parámetro, cuándo es opcional y cómo se usa:

• Si una URL de devolución de llamada está registrada con la app para desarrolladores asociada con las claves de cliente de la solicitud, y redirect_uri está presente en la solicitud, entonces ambas deberán coincidir exactamente (obligatorio). Si no coinciden, se muestra un error. Información sobre el registro de apps de desarrollador en Edge y la especificación de una URL de devolución de llamada, consulta Registra apps y administra la API claves.

• Opcional: Si se registra una URL de devolución de llamada y falta redirect_uri a partir de la solicitud, Edge lo redireccionará a la URL de devolución de llamada registrada.
• Si no hay una URL de devolución de llamada registrada, entonces la redirect_uri es obligatoria (obligatorio). Ten en cuenta que, en este caso, Edge aceptará CUALQUIER URL. Este caso puede presentar un problema de seguridad y, por lo tanto, solo debe usarse con apps cliente confiables. Si las apps cliente no son de confianza, la práctica recomendada es solicitar siempre el registro de una URL de devolución de llamada.

Puedes enviar este parámetro a un parámetro de consulta o en un encabezado. La variable request.queryparam.redirect_uri indica que RedirectUri debe estar presente como un parámetro de consulta, por ejemplo, ?redirect_uri=login.myapp.com. Para solicitar el permiso en un encabezado HTTP, por ejemplo, configura este valor como request.header.redirect_uri. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <RefreshToken>

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

Cuando solicitas un token de acceso con un token de actualización, debes suministrarlo en la solicitud. Este elemento te permite especificar dónde debe buscar Edge el token de actualización. Por ejemplo, podría enviarse como un parámetro de consulta, un encabezado HTTP o un parámetro de forma (predeterminado).

La variable request.queryparam.refreshtoken indica que el token de actualización debe estar presente como un parámetro de búsqueda, por ejemplo, ?refresh_token=login.myapp.com. Para solicitar el RefreshToken en un encabezado HTTP, por ejemplo, configura este valor como request.header.refresh_token. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <RefreshTokenExpiresIn>

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Aplica el tiempo de vencimiento de los tokens de actualización en milisegundos. El valor de tiempo de vencimiento es un valor generado por el sistema y el valor <RefreshTokenExpiresIn>. Si <RefreshTokenExpiresIn> se configura como -1, el token de actualización vence según el vencimiento máximo del token de actualización de OAuth. Si <RefreshTokenExpiresIn> no se especifica, el sistema aplica un valor predeterminado configurado a nivel del sistema. Comunícate con el equipo de asistencia de Apigee Edge para obtener más información información sobre la configuración predeterminada del sistema.

La hora de vencimiento también se puede configurar en el entorno de ejecución con un hard-coded, un valor predeterminado o mediante la referencia a una variable de flujo. Por ejemplo, puedes almacenar un valor de vencimiento de token en un mapa de par clave-valor, recuperarlo, asignarlo a una variable y hacer referencia a él en la política. Por ejemplo, kvm.oauth.expires_in.

En la siguiente estrofa, se especifica una variable de flujo y, también, un valor predeterminado. Ten en cuenta que el valor de la variable de flujo tiene prioridad sobre el valor predeterminado especificado.

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

Nube privada: Para una instalación perimetral para la nube privada, la configuración valor lo establece la propiedad conf_keymanagement_oauth_refresh_token_expiry_time_in_millis. Para configurar esta propiedad, sigue estos pasos:

1. Abre el archivo message-processor.properties en un editor. Si el archivo no existe, créalo:

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

2. Configura la propiedad como desees:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. Asegúrate de que el archivo de propiedades sea propiedad de “apigee” usuario:

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

4. Reinicia el procesador de mensajes.

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

Elemento <ResponseType>

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

Este elemento informa a Edge qué tipo de otorgamiento solicita la app cliente. Solo se usa con el código de autorización y los flujos de tipos de otorgamiento implícito.

De forma predeterminada, Edge busca el valor del tipo de respuesta en una consulta response_type. parámetro. Si deseas anular este comportamiento predeterminado, usa el elemento <ResponseType> para configurar una variable de flujo que contenga el valor del tipo de respuesta. Por ejemplo, si estableces este elemento en request.header.response_type, Edge busca que el tipo de respuesta sea se pasa en el encabezado de la solicitud. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <ReuseRefreshToken>

<ReuseRefreshToken>true</ReuseRefreshToken>

Cuando se configura como true, el token de actualización existente se vuelve a usar hasta que vence. Si false, Apigee Edge emite un nuevo token de actualización cuando se agrega un token de actualización presentada.

Elemento <Scope>

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

Si este elemento está presente en una de las políticas GenerateAccessToken o GenerateAuthorizationCode, se usa para especificar qué permisos otorgar el token o el código. Por lo general, estos valores se pasan a la política en una solicitud desde una aplicación cliente. Puedes configurar el elemento para que tome una variable de flujo, lo que te brinda la opción de elegir cómo se pasan los permisos en una solicitud. En el siguiente ejemplo, request.queryparam.scope indica que el permiso debe estar presente como un parámetro de consulta, por ejemplo, ?scope=READ. Para solicitar el permiso en un encabezado HTTP, por ejemplo, configura este valor como request.header.scope.

Si este elemento aparece en una política "VerifyAccessToken", se usa para especificar los permisos que debe cumplir la política. En este tipo de política, el valor debe ser un nombre de permiso "codificado". No puedes usar variables. Por ejemplo:

<Scope>A B</Scope>

Consulta también Trabaja con los permisos de OAuth2 y Solicita tokens de acceso y códigos de autorización.

Elemento <State>

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

Cuando la app cliente debe enviar la información de estado al servidor de autorización, este elemento te permite especificar dónde Edge debe buscar los valores de estado. Por ejemplo, podría enviarse como parámetro de consulta o en un encabezado HTTP. Por lo general, el valor del estado se usa como una medida de seguridad para evitar ataques del CSRF.

Por ejemplo, request.queryparam.state indica que el estado debe estar presente como un parámetro de consulta, por ejemplo, ?state=HjoiuKJH32. Para solicitar el permiso en un encabezado HTTP, por ejemplo, configura este valor como request.header.state. Consulta también Solicita tokens de acceso y códigos de autorización.

Elemento <StoreToken>

 <StoreToken>true</StoreToken> 

Establece este elemento en true cuando el elemento <ExternalAuthorization> es true. El elemento <StoreToken> le indica a Apigee Edge que almacenar el token de acceso externo. De lo contrario, no se conservará.

Elemento <SupportedGrantTypes>/<GrantType>

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

Especifica los tipos de otorgamiento que admite un extremo de token de OAuth en Apigee Edge. Un extremo puede admitir varios tipos de otorgamiento (es decir, un solo extremo se puede configurar a fin de distribuir tokens de acceso para varios tipos de otorgamiento). Para obtener más información sobre los extremos, consulta Comprende los extremos de OAuth. El tipo de concesión se pasa en solicitudes de token en un parámetro grant_type.

Si no se especifican tipos de otorgamiento de acceso compatibles, los únicos tipos de otorgamiento permitidos son authorization_code y implicit. Consulta también el elemento &lt;GrantType&gt; (un elemento de nivel superior que se usa para lo siguiente: especificar dónde debe buscar Apigee Edge el parámetro grant_type que se pasa una solicitud del cliente. Edge se asegurará de que el valor del parámetro grant_type coincida con uno de los tipos de otorgamiento admitidos).

Elemento <Tokens>/<Token>

Se usa con las operaciones InvalidToken e InvalidateToken. Consulta también Aprueba y revoca tokens de acceso. El elemento <Token> identifica la variable de flujo que define la fuente del token que se revocará. Si se espera que los desarrolladores envíen tokens de acceso como parámetros de consulta llamados access_token, usa request.queryparam.access_token.

Elemento <UserName>

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

Este elemento se usa solo con el tipo de otorgamiento de contraseña. Con el tipo de otorgamiento de contraseña, las credenciales de usuario (contraseña y nombre de usuario) deben estar disponibles para la política de OAuthV2. Los elementos <PassWord> y <UserName> son para especificar variables en las que Edge puede encontrar estos valores. Si no se especifican estos elementos, la política espera encontrar los valores (de forma predeterminada) en los parámetros de formulario llamados username y password. Si no se encuentran los valores, la política muestra un error. Puedes usar los elementos <PassWord> y <UserName> para hacer referencia a cualquier variable de flujo que contenga las credenciales.

Por ejemplo, puedes pasar el nombre de usuario en un parámetro de consulta y configurar el elemento <UserName> de la siguiente manera: <UserName>request.queryparam.username</UserName>. Para solicitar el nombre de usuario en un encabezado HTTP, configura este valor en request.header.username.

La política OAuthV2 no hace nada más con estos valores de credenciales. Edge solo es para verificar que estén presentes. Depende del desarrollador de la API recuperar la solicitud de valores y enviarla a un proveedor de identidad antes de que se ejecute la política de generación de tokens.

Consulta también Solicita tokens de acceso y códigos de autorización.

Verifica tokens de acceso

Una vez que se configura un extremo de token para un proxy de API, una política de OAuthV2 correspondiente que especifica la operación VerifyAccessToken se adjunta al flujo que expone el recurso protegido.

Por ejemplo, para garantizar que las solicitudes a una API estén autorizadas, la siguiente política aplica la verificación de token de acceso:

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

La política se adjunta al recurso de la API que se protegerá. Para garantizar que se verifiquen todas las solicitudes a una API, adjunta la política a la solicitud de PreFlow de solicitud de extremo del proxy de la siguiente manera:

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

Los siguientes elementos opcionales se pueden usar para anular la configuración predeterminada de la operación VerifyAccessToken.

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

Consulta también Verifica tokens de acceso y Solicita tokens de acceso y códigos de autorización.

Especifica ubicaciones de variables de solicitud

Para cada tipo de concesión, la política hace suposiciones sobre la ubicación o la información requerida en los mensajes de solicitud. Estas suposiciones se basan en la especificación de OAuth 2.0. Si tus aplicaciones necesitan desviarse de la especificación de OAuth 2.0, puedes especificar las ubicaciones esperadas para cada parámetro. Por ejemplo, cuando se controla un código de autorización, puedes especificar la ubicación del código de autorización, el ID de cliente, el URI de redireccionamiento y el alcance. Estos se pueden especificar como encabezados HTTP, parámetros de búsqueda o parámetros de formulario.

El siguiente ejemplo demuestra cómo puedes especificar la ubicación de los parámetros de código de autorización requeridos como encabezados 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>
  ...

O bien, si es necesario para admitir tu base de apps cliente, puedes mezclar y combinar encabezados y parámetros de consulta:

  ...
  <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>
  ...

Solo se puede configurar una ubicación por parámetro.

Variables de flujo

Las variables de flujo definidas en esta tabla se propagan cuando se ejecutan las políticas de OAuth correspondientes. Por lo tanto, están disponibles para otras políticas o aplicaciones que se ejecutan en el flujo de proxy de API.

Operación VerifyAccessToken

Cuando se ejecuta la operación VerifyAccessToken, se propaga una gran cantidad de variables de flujo en el contexto de ejecución del proxy. Estas variables te otorgan propiedades relacionadas con el token de acceso, la app para desarrolladores, el desarrollador y la empresa. Puedes usar una política de AssignMessage o JavaScript, por ejemplo, para leer cualquiera de estas variables y usarlas según sea necesario más adelante en el flujo. Estas variables también pueden ser útiles para fines de depuración.

Variables específicas de token

Variables específicas de la app

Estas variables están relacionadas con la app para desarrolladores asociada con el token.

Variables específicas para desarrolladores

Si el archivo app.appType es “Company” (Empresa), los atributos de la empresa se propagan y si app.appType es “Developer”, entonces los atributos del desarrollador se propagan.

Variables específicas de la empresa

Si el archivo app.appType es “Company” (Empresa), los atributos de la empresa se propagan y si app.appType es “Developer”, entonces los atributos del desarrollador se propagan.

Operación GenerateAuthorizationCode

Estas variables se configuran cuando la operación GenerateAuthorizationCode se ejecuta de forma correcta:

Prefijo: oauthv2authcode.{policy_name}.{variable_name}

Ejemplo: oauthv2authcode.GenerateCodePolicy.code

Operaciones de GenerateAccessToken y RefreshAccessToken

Estas variables se configuran cuando las operaciones GenerateAccessToken y RefreshAccessToken se ejecutan de forma correcta. Ten en cuenta que las variables de token de actualización no se aplican para el flujo de tipos de otorgamiento de credenciales de cliente.

Prefijo: oauthv2accesstoken.{policy_name}.{variable_name}

Ejemplo: oauthv2accesstoken.GenerateTokenPolicy.access_token

GenerateAccessTokenImplicitGrant

Estas variables se configuran cuando la operación GenerateAccessTokenImplicit se ejecuta de manera correcta para el flujo de tipo de otorgamiento implícito.

Prefijo: oauthv2accesstoken.{policy_name}.{variable_name}

Ejemplo: oauthv2accesstoken.RefreshTokenPolicy.access_token

Referencia de errores

En esta sección, se describen los códigos y mensajes de error que se muestran, y las variables de falla que establece Edge cuando esta política activa un error. Esta información es importante para saber si estás desarrollando reglas de fallas con el propósito de manejar fallas. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo solucionar fallas.

Errores de entorno de ejecución

Estos errores pueden producirse cuando se ejecuta la política.

Errores en la implementación

Estos errores pueden generarse cuando implementas un proxy que contiene esta política.

Variables con fallas

Estas variables se configuran cuando esta política activa un error en el entorno de ejecución.

Ejemplo de respuesta de error

Estas respuestas se envían al cliente si el elemento <GenerateResponse> es verdadero.

Si <GenerateResponse> es verdadero, la política muestra errores en este formato para las operaciones que generan tokens y códigos. Para obtener una lista completa, consulta la referencia de respuesta de error de HTTP de OAuth.

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

Si <GenerateResponse> es verdadero, la política muestra errores en este formato para verificar y validar operaciones. Para obtener una lista completa, consulta la referencia de respuesta de falla de HTTP de OAuth.

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

Ejemplo de regla de falla

<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>

Esquema de política

Un esquema XML (.xsd) define cada tipo de política. Como referencia, los esquemas de políticas están disponibles en GitHub.

Trabaja con la configuración de OAuth predeterminada

Cada organización (incluso una organización de prueba gratuita) en Apigee Edge se aprovisiona con un token de OAuth extremo. El extremo está preconfigurado con políticas en el proxy de API llamado oauth. Puedes comenzar a usar el extremo del token apenas crees una cuenta de Apigee Edge. Para obtener más detalles, consulta Información sobre los extremos de OAuth.

Borra definitivamente tokens de acceso

De forma predeterminada, los tokens de OAuth2 se borran definitivamente del sistema Apigee Edge durante 3 días (259,200 segundos) una vez que hayan vencido el token de acceso y el token de actualización (si existe). En algunos casos, es posible que desees cambiar esta configuración predeterminada. Por ejemplo, tal vez quieras acortar el tiempo de borrado definitivo para ahorrar espacio en el disco si se genera una gran cantidad de tokens.

Si estás en Edge for Private Cloud, puedes cambiar este valor predeterminado estableciendo de Google Cloud, como se explica en esta sección. (La eliminación definitiva de los tokens vencidos durante 3 días se aplica a Edge para la nube privada versión 4.19.01 y posteriores. Para versiones anteriores, el intervalo de eliminación predeterminado es de 180 días).

Actualiza la configuración de eliminación definitiva de la nube privada perimetral 4.16.01 y versiones posteriores

Nota: Solo se generan tokens generados después de esta configuración. se ven afectadas; Los parámetros de configuración no se aplican a los tokens que se generaron anteriormente.

Actualizando la eliminación definitiva Configuración de Edge Private Cloud 4.15.07

Nota: Solo se aplican los tokens generados después de esta configuración. se vean afectadas; Los parámetros de configuración no se aplican a los tokens que se generaron anteriormente.

Comportamiento que no cumple con RFC

La política OAuthV2 muestra una respuesta de token que contiene ciertas propiedades que no cumplen con RFC. En la siguiente tabla, se muestran las propiedades que no cumplen con las políticas que se muestran en la política OAuthV2 y las que cumplen con los requisitos correspondientes.

Además, la respuesta de error de un token de actualización vencido cuando grant_type = refresh_token es este:

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

Sin embargo, la respuesta compatible con RFC es la siguiente:

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

Temas relacionados

• Introducción a OAuth 2.0