Esta página se aplica a Apigee y Apigee hybrid.
Consulta la documentación de
Apigee Edge.
Con el tipo de autorización de credenciales de cliente, una aplicación envía sus propias credenciales (el ID de cliente y el secreto de cliente) a un endpoint de Apigee configurado para generar un token de acceso. Si las credenciales son válidas, Apigee devuelve un token de acceso a la aplicación cliente.
Sobre este tema
En este tema se ofrece una descripción general del tipo de autorización de credenciales de cliente de OAuth 2.0 y se explica cómo implementar este flujo en Apigee.
Casos prácticos
Por lo general, este tipo de concesión se usa cuando la aplicación también es el propietario del recurso. Por ejemplo, una aplicación puede necesitar acceder a un servicio de almacenamiento basado en la nube backend para almacenar y recuperar datos que utiliza para realizar su trabajo, en lugar de datos que sean propiedad específica del usuario final. Este flujo de tipo de concesión se produce estrictamente entre una aplicación cliente y el servidor de autorización. El usuario final no participa en este flujo de tipo de concesión.
Roles
Los roles especifican los "actores" que participan en el flujo de OAuth. Vamos a hacer un breve resumen de los roles de las credenciales de cliente para ilustrar dónde encaja Apigee. Para obtener una descripción completa de los roles de OAuth 2.0, consulta la especificación de OAuth 2.0 de IETF.
- Aplicación cliente: la aplicación que necesita acceder a los recursos protegidos del usuario. Normalmente, con este flujo, la aplicación se ejecuta en el servidor en lugar de hacerlo de forma local en el portátil o el dispositivo del usuario.
- Apigee: en este flujo, Apigee es el servidor de autorización de OAuth. Su función es generar tokens de acceso, validarlos y enviar solicitudes autorizadas de recursos protegidos al servidor de recursos.
- Servidor de recursos: el servicio backend que almacena los datos protegidos a los que la aplicación cliente necesita permiso para acceder. Si proteges proxies de API alojados en Apigee, Apigee también es el servidor de recursos.
Código de ejemplo
Puedes encontrar una implementación de ejemplo completa y funcional del tipo de autorización de credenciales de cliente en GitHub. Consulta los recursos adicionales que aparecen más abajo para ver enlaces a más ejemplos.
Diagrama de flujo
En el siguiente diagrama de flujo se muestra el flujo de credenciales de cliente con Apigee como servidor de autorización. Por lo general, Apigee también es el servidor de recursos en este flujo, es decir, los proxies de API son los recursos protegidos.
Pasos del flujo de credenciales de cliente
A continuación, se resumen los pasos necesarios para implementar el tipo de autorización de credenciales de cliente en el que Apigee actúa como servidor de autorización. Recuerda que, con este flujo, la aplicación cliente solo presenta su ID de cliente y su secreto de cliente. Si son válidos, Apigee devuelve un token de acceso.
Requisito previo: La aplicación cliente debe registrarse en Apigee para obtener las claves de ID de cliente y secreto de cliente. Para obtener más información, consulta el artículo Registrar aplicaciones cliente.
1. El cliente solicita un token de acceso
Para recibir un token de acceso, el cliente envía una llamada a la API de Apigee con los valores del ID de cliente y del secreto de cliente obtenidos de una aplicación de desarrollador registrada (en este ejemplo, los valores están
codificados en Base64 y se transfieren en el encabezado Authorization). Además, el parámetro grant_type=client_credentials debe enviarse como parámetro de consulta. Sin embargo, puedes configurar la política OAuthV2 para que acepte este parámetro en el encabezado o el cuerpo de la solicitud. Consulta la política OAuthV2 para obtener más información.
Por ejemplo:
curl -H "Content-Type: application/x-www-form-urlencoded" \ -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \ -X POST "https://apitest.acme.com/oauth/token" \ -d "grant_type=client_credentials"
Consulta también Usar el tipo de autorización de credenciales de cliente.
2. Apigee valida las credenciales
Ten en cuenta que la llamada a la API se envía al endpoint /oauth/token. Este endpoint tiene una política
adjunta que valida las credenciales de la aplicación. Es decir, la política compara las claves enviadas con las que creó Apigee cuando se registró la aplicación. Si quieres obtener más información sobre los endpoints de OAuth en Apigee, consulta Configurar endpoints y políticas de OAuth.
3. Apigee devuelve una respuesta
Si las credenciales son correctas, Apigee devuelve un token de acceso al cliente. Si no es así, se devuelve un error.
4. El cliente llama a la API protegida
Ahora, con un token de acceso válido, el cliente puede hacer llamadas a la API protegida. En este caso, las solicitudes se envían a Apigee (el proxy) y Apigee es responsable de validar el token de acceso antes de enviar la llamada a la API al servidor de recursos de destino. Por ejemplo, consulta Llamar a la API protegida más abajo.
Configurar flujos y políticas
Como servidor de autorización, Apigee procesa las solicitudes de tokens de acceso. Como desarrollador de la API, debes crear un proxy con un flujo personalizado para gestionar las solicitudes de tokens, así como añadir y configurar una política OAuthV2. En esta sección se explica cómo configurar ese endpoint.
Configuración de flujo personalizada
La forma más sencilla de mostrar cómo se configura el flujo del proxy de API es mostrar la definición del flujo XML. A continuación, se muestra un ejemplo de flujo de proxy de API diseñado para procesar una solicitud de token de acceso. Por ejemplo, cuando llega una solicitud y el sufijo de la ruta coincide con /oauth/token, se activa la política GetAccessToken. Consulta Configurar endpoints y políticas de OAuth para ver un resumen rápido de los pasos necesarios para crear un flujo personalizado como este.
<Flows>
<Flow name="GetAccessToken">
<!-- This policy flow is triggered when the URI path suffix
matches /oauth/token. Publish this URL to app developers
to use when obtaining an access token using an auth code
-->
<Condition>proxy.pathsuffix == "/oauth/token"</Condition>
<Request>
<Step><Name>GetAccessToken</Name></Step>
</Request>
</Flow>
</Flows>Configurar el flujo con una política
Debes adjuntar una política al endpoint, tal como se indica a continuación. Consulta Configurar puntos de conexión y políticas de OAuth para ver un resumen rápido de los pasos necesarios para añadir una política OAuthV2 a un endpoint de proxy.
Obtener token de acceso
Esta política se adjunta a la ruta /oauth/token. Usa la política OAuthV2
con la operación GenerateAccessToken especificada.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>3600000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<GenerateResponse/>
</OAuthV2>La llamada a la API para obtener el token de acceso es una solicitud POST e incluye un encabezado Authorization con
client_id + client_secret codificado en Base64 y el parámetro de consulta
grant_type=client_credentials. También puede incluir
parámetros opcionales para el ámbito y el estado. Por ejemplo:
curl -i \ -H 'Content-Type: application/x-www-form-urlencoded' \ -X POST 'https://docs-test.apigee.net/oauth/accesstoken' \ -d 'grant_type=client_credentials' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
Asociar la política de verificación de tokens de acceso
Para proteger tu API con la seguridad de OAuth 2.0, debes añadir una política OAuthV2 con la operación VerifyAccessToken. Esta política comprueba que las solicitudes entrantes tengan un token de acceso válido. Si el token es válido, Apigee procesa la solicitud. Si no es válido, Apigee devuelve un error. Para ver los pasos básicos, consulta Verificar tokens de acceso.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
<DisplayName>VerifyAccessToken</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>VerifyAccessToken</Operation>
<SupportedGrantTypes/>
<GenerateResponse enabled="true"/>
<Tokens/>
</OAuthV2>Llamar a la API protegida
Para llamar a una API protegida con seguridad OAuth 2.0, debes proporcionar un token de acceso válido. El patrón correcto consiste en incluir el token en un encabezado Authorization, como se indica a continuación. Ten en cuenta que el token de acceso también se conoce como "token de portador".
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Consulta también Enviar un token de acceso.
Recursos adicionales
- Apigee ofrece formación online para desarrolladores de APIs, incluido un curso sobre seguridad de las APIs, que incluye OAuth.
- Política de OAuthV2: incluye muchos ejemplos que muestran cómo hacer solicitudes al servidor de autorización y cómo configurar la política de OAuthV2.