Se usó la API de Cloud Translation para traducir esta página.

Usa tokens de OAuth de terceros

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

En este tema, analizaremos cómo importar tokens de acceso generados externamente, tokens de actualización, o códigos de autorización al almacén de tokens de Edge. Puedes usar esta técnica si quieres configurar Apigee Edge para validar los tokens que se generan fuera de Apigee Edge

En el caso habitual, Apigee Edge generará y almacenará un token de OAuth, que luego devolverá al que realiza la llamada. Luego, la app que realiza la llamada presenta ese token a Apigee Edge cuando lo solicita y Apigee Edge, mediante la política OAuthV2 con Operation = VerifyAccessToken, verificarás que el token sea válido. En este tema, se describe cómo configurar Apigee Edge para almacenar un token de OAuth que se generó en otro lugar y que, al mismo tiempo, mantiene la parte de verificación del token igual del mismo modo que si Edge generara el token.

Ejemplo

Si deseas ver un ejemplo funcional en el que se ilustra la técnica descrita en este tema, consulta la muestra de administración de tokens delegados de Apigee.

¿Qué es esto?

Supongamos que ya tienes implementado un sistema de autorización y quieres usar el los valores de token o código generados por ese sistema en lugar de los valores de código o token OAuth2 que Edge genera. Luego, puede realizar solicitudes seguras de proxy de API con el token o código sustituidos. y Edge los validará como si los hubiera generado Edge.

Información general

En el caso habitual, Apigee Edge genera un token produciendo una cadena aleatoria de letras y y números de serie. Apigee Edge asocia a ese token otros datos, como la hora en que se emitió el token, el vencimiento, la lista de productos de API para los que el token es válido y el alcance. Toda esta información se puede mostrar en una respuesta la política de OAuthV2 configuró de forma automática con la operación = GenerateAccessToken. La respuesta es similar a la que se muestra a continuación:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

El valor del atributo access_token es efectivamente la clave de búsqueda de los datos de respuesta. Una app podría enviar una solicitud a un proxy de API alojado en Edge por medio del token del portador zBC90HhCGmGlaMBWeZAai2s3za5j y Edge, con la interfaz OAuthV2 política con el parámetro Operation = VerifyAccessToken: buscará el token, recuperará toda la información, y usar esa información para determinar si el token es válido o no para el proxy de API solicitado. Esto se denomina validación de tokens. Toda la información anterior comprende el token. El access_token es solo la forma de buscar esa información.

Por otro lado, si sigues los pasos que se describen aquí, puedes configurar Edge para que almacene un token para que su valor de access_token sea generado por un servicio. Todos los demás metadatos podrían ser iguales. Por ejemplo, supongamos que tienes un sistema externo a Apigee Edge que genera tokens con el formato "TOKEN-<16 aleatorio" números>" de Google Cloud. En ese caso, los metadatos del token completos que almacena Apigee Edge podrían ser los siguientes:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

En este caso, una app podría realizar una solicitud a un proxy de API alojado en Edge que lleve el portador token TOKEN-1092837373654221 y Edge mediante la política OAuthV2 con la operación = VerifyAccessToken podrá validarlo. Puedes aplicar un patrón de importación similar a los códigos de autorización y a los tokens de actualización.

Hablemos sobre la validación de credenciales de cliente

Un requisito para generar un token es validar el cliente solicitante. De forma predeterminada, el La política OAuthV2/GenerateAccessToken en Apigee Edge verifica implícitamente las credenciales del cliente. Normalmente, en una solicitud de un token OAuthV2, el client_id y client_secret se pasan en la Encabezado de autorización, codificado mediante la autorización básica HTTP (concatenación de dos puntos, luego codificada en base64). La política OAuthV2/GenerateAccessToken de Apigee Edge decodifica ese encabezado y busca client_id y verifica que el client_secret que se pasó sea válido para eso client_id. Esto funciona si Apigee Edge conoce las credenciales; es decir, App de desarrollador almacenada dentro de Apigee Edge que contiene una credencial, que, a su vez, incluye la proporcionados client_id y client_secret.

En caso de que Apigee Edge no valide las credenciales del cliente, debes diseñar tu proxy de API, antes de que genere un token, para validar explícitamente al cliente a través de algún por otros medios. A menudo, esto se hace a través de una política de ServiceCallout que se conecta a un extremo remoto en tu red.

De una forma o de la otra, ya sea implícita o explícitamente, debes asegurarte de que el proxy de API que genera tokens, primero valida las credenciales del cliente. Ten en cuenta que validar el cliente es independiente de la generación del token de acceso. Puedes configurar Apigee Edge para que realice ambas tareas hacer una de las dos o ninguna de las dos.

Si quieres que la política OAuthV2/GenerateAccessToken en Apigee Edge valide al cliente. en el almacén de Edge, configura el elemento <ExternalAuthorization> como false dentro de la configuración de la política, o bien omítelo por completo. Si deseas usar un servicio de autorización externo para validar de forma explícita las credenciales del cliente, establece <ExternalAuthorization> como true.

Aunque es posible que Apigee Edge no valide las credenciales del cliente, de todas formas es necesario client_id que conocerá y administrará Apigee Edge. Cada access_token de Apigee Edge, ya sea generados por Apigee Edge o por un sistema externo y, luego, importados a Apigee Edge debe estar asociado a una aplicación cliente, indicado por client_id. Incluso en el caso en la que la política OAuthV2/GenerateAccessToken de Apigee Edge no validará que el ID de cliente y client_secret, la política validará que el client_id sea válido, esté presente y no revocado. Por lo tanto, como paso de configuración de requisito previo, es posible que debas importar los client_id a través de Edge. Administrative.

Flujo de políticas para OAuth de terceros en Apigee

Para usar tokens de sistemas OAuth de terceros en Apigee Edge, el flujo para generar acceso los tokens deben seguir uno de los siguientes patrones.

Validación externa de credenciales de cliente

ServiceCallout para verificar las credenciales del cliente entrante y adquirir un token externo.
ExtractVariables o un paso de JavaScript para extraer el token generado de forma externa a partir de la respuesta.
AssignMessage para establecer la variable especial conocida llamada oauth_external_authorization_status. El valor debe ser verdadero para indicar que las credenciales del cliente son válidas.
OAuthV2/GenerateAccessToken con el elemento <ExternalAuthorization> configurado como true y al menos uno de <ExternalAccessToken>, <ExternalRefreshToken> o <ExternalAuthorizationCode>.

Validación interna de las credenciales de cliente

ServiceCallout para adquirir un token externo.
ExtractVariables o un paso de JavaScript para extraer el token generado de forma externa a partir de la respuesta.
OAuthV2/GenerateAccessToken con el elemento <ExternalAuthorization> configurado como false y al menos uno de <ExternalAccessToken>, <ExternalRefreshToken> o <ExternalAuthorizationCode>.

Notas sobre la configuración de políticas y el flujo

En el caso de que desees usar un sistema externo para validar credenciales de cliente, depende de ti desarrollar un flujo de políticas que haga lo que sea necesario. Por lo general, usarías una política ServiceCallout para enviar las credenciales reconocidas externamente al servicio de autenticación externo. Por lo general, el servicio de autenticación externo muestra una respuesta y, si las credenciales son válidas, también un token de acceso.
Después de ServiceOverflow, el proxy de la API debe analizar la respuesta para extraer el estado de validez, así como el acceso_token generado de manera externa y posiblemente el refresh_token.
En la política OAuthV2/GenerateAccessToken, configura el elemento <StoreToken> como true y configura el elemento <ExternalAuthorization> como true o false según corresponda.

Cuando se ejecuta la política OAuthV2/GenerateAccessToken, se lee la variable oauth_external_authorization_status. Si la variable está establecida y el valor es true, Apigee Edge no intenta validar las credenciales del cliente. Si la variable si no se establece o el valor no es verdadero, Apigee Edge intentará validar credenciales.
La política de OAuthV2 tiene tres elementos que te permiten especificar los datos externos que se importarán: <ExternalAccessToken>, <ExternalRefreshToken> y <ExternalAuthorizationCode>. Cada uno de estos elementos acepta una variable de flujo. La política de Edge leerá esa variable para encontrar la un token de acceso, un token de actualización o un código de autorización generados de forma externa. Depende de ti implementar políticas y lógica para colocar los tokens o códigos externos en las variables adecuadas.

Por ejemplo, la siguiente configuración en la política OAuthV2 le indica a Edge que busque el en una variable de contexto llamada external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
También necesitarías tener un paso anterior que establezca esa variable.
En cuanto a la configuración de la variable oauth_external_authorization_status, una técnica común para configurar esta variable es usar una política de AssignMessage con el elemento AssignVariable, como se muestra a continuación:
```
<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
Recuerda que esta política debe ser anterior a la política de OAuthV2 con Operation = GenerateAccessToken.

Ejemplo de política de OAuthV2

La siguiente política OAuthV2 genera un token de acceso de Apigee Edge, ya que Edge encuentra un valor del token en la variable de flujo external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Por lo general, con el cliente otorga el tipo de otorgamiento de credenciales, debes proporcionar un encabezado de autenticación básica con el cliente codificado. y el secreto del cliente. Sin embargo, en este caso, no es necesario que proporciones encabezado. La política aún espera que el client_id esté presente en la solicitud, y que el elemento la validará. Edge espera que se envíe client_id como parte. de los datos del formulario de solicitud, p.ej., en request.formparam.client_id.

En teoría, podrías aplicar este patrón con cualquier servicio de autorización de OAuth2 de terceros.