Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
OAuth surgió como el protocolo líder de autorización para APIs. La versión de OAuth que se trata en detalle en este tema se define en el OAuth 2.0 Especificación.
OAuth es un protocolo que permite que los usuarios finales de la app autoricen apps para que actúen en su nombre. Para ello, las apps obtienen acceso tokens de proveedores de API. El proveedor de la API autentica el final de la app las credenciales del usuario, garantiza que este haya autorizado la aplicación y emite un token de acceso a la app. Cuando la app consume una API protegida, Apigee Edge verifica el token de acceso para asegurarse que sea válido y que no haya vencido. Como proveedor de API, debes exponer los extremos que permiten que las apps obtengan tokens de acceso.
Para que sea más fácil comenzar a usar OAuth, Apigee Edge te permite configurar y aplicar OAuth con políticas, sin necesidad de que escribir código. En este tema, aprenderás a proteger tus APIs, a obtener acceso tokens y cómo usarlos para acceder a APIs protegidas.
La configuración de OAuth predeterminada para tus organización
Para mayor comodidad, todas las organizaciones en Apigee Edge vienen preconfiguradas con un conjunto de OAuth 2.0 extremos que implementan el tipo de otorgamiento de credenciales de cliente. El cliente el tipo de otorgamiento de credenciales define un procedimiento para emitir tokens de acceso a cambio de una app credenciales. Estas credenciales de aplicación son simplemente el par de clave de consumidor y secreto que Problemas de Apigee Edge para cada app que se registra en una organización. Credenciales de cliente hace referencia a la clave de consumidor y el par secreto.
Para obtener más información sobre cómo emitir credenciales a las apps que usan los servicios para desarrolladores de Edge, consulta Registra apps y administra claves.
Por este motivo, es bastante simple avanzar tu esquema de seguridad de API a partir de la clave de API la validación a credenciales de clientes de OAuth. Ambos esquemas usan la misma clave de consumidor y el mismo secreto para validar la app cliente. La diferencia es que las credenciales de cliente proporcionan una capa adicional de control de acceso, ya que puedes revocar fácilmente un token de acceso cuando sea necesario, sin requerir que lo revoques la clave de consumidor de la aplicación. Para trabajar con los extremos de OAuth predeterminados, puedes usar cualquier clave de consumidor y el Secret generados para que la app en tu organización recupere tokens de acceso del token extremo. (Incluso puedes habilitar las credenciales de cliente para las apps que ya tienen claves de consumidor y secrets.)
La especificación completa para el otorgamiento de credenciales de cliente se puede encontrar en OAuth 2.0 Especificación.
Protege tu API con una política
Antes de poder usar tokens de acceso, debes configurar tus APIs para validar el acceso de OAuth tokens en el entorno de ejecución. Para ello, debes configurar un proxy de API para validar tokens de acceso Esto significa que cada vez que una app solicita consumir una de tus APIs, la aplicación debe presentar un token de acceso válido junto con la solicitud a la API. Apigee Edge controla la complejidad que implica generar, almacenar y validar los tokens de acceso que se presentan.
Puedes agregar fácilmente la verificación de OAuth a una API cuando creas un nuevo proxy de API. Cuando creas un proxy de API nuevo, puedes Agregar funciones. Como que se muestra a continuación, puedes agregar la verificación de los tokens de acceso de OAuth 2.0 con el botón de selección junto a Proteger con tokens de acceso de OAuth v2.0. Cuando seleccionas esta opción, dos las políticas se adjuntarán al proxy de API recién creado, uno para verificar los tokens de acceso y otro para para quitar el token de acceso después de que se haya verificado.
Además, cuando seleccionas la opción Proteger con tokens de acceso de OAuth v2.0, la casilla de verificación Publish API Product se puede seleccionar y se convierte automáticamente seleccionado. Marca esta opción si quieres generar automáticamente un producto cuando compiles la nueva API. proxy. El producto generado automáticamente se creará con una asociación con el nuevo proxy de API. Si tienes un producto existente al que quieras asociar esta nueva API, asegúrate de borrar este para evitar crear un producto innecesario. Para obtener información sobre los productos, consulta ¿Qué es un producto de API?
Si necesitas habilitar la verificación del token de acceso para el proxy de API que ya existe, lo único que debes hacer es adjuntar una política de tipo OAuthV2 a la API que quieres proteger. Para funcionar, las políticas de OAuthV2 especifican una operación. Si quieres para validar los tokens de acceso, debes especificar la operación denominada VerifyAccessToken. (otros tipos de operaciones compatibles con el tipo de política OAuthV2 son GenerateAccessToken y GenerateRefreshToken. Aprenderás sobre esas operaciones cuando configures extremos de OAuth).
Política VerifyOAuthTokens de tipo OAuthV2
Una política de ejemplo para validar tokens de acceso se ve de la siguiente manera. (Los parámetros de configuración son que se explica en la siguiente tabla).
<OAuthV2 name="VerifyOAuthTokens"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Configuración de la política
| Nombre | Descripción | Predeterminada | ¿Obligatorio? |
|---|---|---|---|
OAuthV2 |
El tipo de política | ||
name |
El nombre de la política, al que se hace referencia en el extremo del proxy de API configuración. | N/A | Sí |
Operation |
La operación que ejecutará la política OAuthV2. Con VerifyAccessToken, configurarás la política para comprobar las solicitudes de tokens de acceso y verificar que la política de el token es válido, no venció y está aprobado para consumir el recurso de API solicitado (URI). (Para comprobar esto, la política lee el producto de API para el que está aprobada la app consume.) | N/A | Sí |
Para crear esta política en la IU de administración, ve a APIs > API Proxies
En la lista de proxies de API, selecciona weatherapi.
En Overview de weatherapi, selecciona Develop vista.
En el menú desplegable, selecciona Política nueva > OAuth v2.0
Después de seleccionar la política de OAuth v2.0, el menú de configuración Política nueva un código de Google.
Asigna un nombre descriptivo a la política y asegúrate de seleccionar Adjuntar política. Flow PreFlow y Request como opciones de configuración del adjunto de política.
Selecciona Agregar para que la política se cree y se adjunte a la solicitud de la weatherapi previo al flujo.
Después de agregar la política, la configuración de la solicitud PreFlow que aparece a continuación se mostrará en el Panel Designer
Si trabajas a nivel local en un editor de texto o IDE, puedes adjuntar la política para la solicitud de PreFlow del proxy de API que quieres proteger:
<PreFlow>
<Request>
<Step><Name>VerifyOAuthTokens</Name></Step>
</Request>
</PreFlow>
Cuando adjuntas la política a la solicitud PreFlow, te aseguras de que la política siempre se aplique en todos los mensajes de solicitud.
Ya protegiste una API con credenciales de cliente de OAuth 2.0. El siguiente paso es aprender para obtener un token de acceso y usarlo para acceder a la API segura.
El uso de un token de acceso para acceder a una recurso
Ahora que weatherapi está protegida con OAuth 2.0, las aplicaciones deben presentar tokens de acceso para consumir la API. Para acceder a un recurso protegido, la app presenta un token de acceso en la solicitud como un "Autorización" encabezado HTTP de la siguiente manera:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
Debido a que la API tiene una política OAuthV2 adjunta, Apigee Edge verificará que el token de acceso presentado es válido, otorga acceso a la API y muestra el informe del clima a la app que realizó la solicitud.
Pero ¿cómo obtienen tokens de acceso las apps? Abordaremos ese tema en la próxima sección.
Cómo intercambiar credenciales de cliente de un token de acceso
Las apps obtienen tokens de acceso presentando sus pares clave/secretos de consumidor al token extremo. El extremo del token se configura en el proxy de API llamado oauth. Por lo tanto, las apps deben llamar a la API que expone la API de oauth. para obtener un token de acceso. Una vez que la app tiene un token de acceso, puede llamar a la weatherapi reiteradamente, hasta que caduque el token de acceso o se revoque.
Ahora tienes que cambiar de marcha para pensar en ti mismo como un desarrollador de aplicaciones. Quieres llamar al climaapi, por lo que necesitas obtener un token de acceso para tu app. Lo primero que debes hacer es obtener una clave de consumidor y un par secreto (también conocido como API tecla o una tecla de aplicación).
Para obtener una clave y un secreto de consumidor, registra una app en tu organización con Apigee Edge.
Puedes ver todas las aplicaciones de tu organización en la IU de administración de Apigee Edge.
Se mostrará la lista de apps registradas en tu organización.
(Si no se muestran apps, puedes aprender a registrarlas en el tema Register apps and Manage API). claves).
Selecciona una app de la lista para ver su perfil detallado.
En la vista de detalles de la app que seleccionaste, ten en cuenta los campos de Consumer Key (Clave de consumidor). y Consumer Secret. Estos dos valores son el valor client credenciales que usarás para obtener un token de acceso de OAuth.
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps \
-u myname:mypass
Esta llamada muestra una lista de apps por ID de app.
[ "da496fae-2a04-4a5c-b2d0-709278a6f9db", "50e3e831-175b-4a05-8fb6-05a54701af6e" ]
Puedes recuperar el perfil de una app si realizas una llamada GET simple en el ID de la app:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/{app_id} \
-u myname:mypass
Por ejemplo:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/da496fae-2a04-4a5c-b2d0-709278a6f9db \
-u myname:mypass
La llamada a la API muestra el perfil de la app que especificaste. Por ejemplo, un perfil de app para weatherapp tiene la siguiente representación JSON:
{
"accessType" : "read",
"apiProducts" : [ ],
"appFamily" : "default",
"appId" : "da496fae-2a04-4a5c-b2d0-709278a6f9db",
"attributes" : [ ],
"callbackUrl" : "http://weatherapp.com",
"createdAt" : 1380290158713,
"createdBy" : "noreply_admin@apigee.com",
"credentials" : [ {
"apiProducts" : [ {
"apiproduct" : "PremiumWeatherAPI",
"status" : "approved"
} ],
"attributes" : [ ],
"consumerKey" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"consumerSecret" : "hAr4Gn0gA9vAyvI4",
"expiresAt" : -1,
"issuedAt" : 1380290161417,
"scopes" : [ ],
"status" : "approved"
} ],
"developerId" : "5w95xGkpnjzJDBT4",
"lastModifiedAt" : 1380290158713,
"lastModifiedBy" : "noreply_admin@apigee.com",
"name" : "weatherapp",
"scopes" : [ ],
"status" : "approved"
}
Anota los valores de consumerKey y consumerSecret. Usas estas
para obtener un token de acceso presentándolos como credenciales de autenticación básica en
una solicitud HTTP, como se muestra a continuación. El tipo de otorgamiento se presenta como un parámetro de consulta a la solicitud.
(Asegúrate de cambiar el valor de la variable {org_name} para reflejar el nombre de tu organización
en Apigee Edge).
Crea una solicitud para obtener un token de acceso
En la siguiente solicitud, sustituye el valor de tu consumerKey por
client_id Sustituye el valor del consumerSecret asociado por
client_secret
$ curl https://{org_name}-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'
Los Servicios de API verifican la clave y el secreto del consumidor y, luego, generan una respuesta que contiene el token de acceso para esta aplicación:
{
"issued_at" : "1380892555397",
"application_name" : "957aa73f-25c2-4ead-8021-adc01f0d2c6b",
"scope" : "",
"status" : "approved",
"api_product_list" : "[oauth-test]",
"expires_in" : "3599",
"developer.email" : "tesla@weathersample.com",
"organization_id" : "0",
"client_id" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"access_token" : "ylSkZIjbdWybfs4fUQe9BqP0LH5Z",
"organization_name" : "rqa",
"refresh_token_expires_in" : "0",
"refresh_count" : "0"
}
Observa el valor access_token en la respuesta anterior. Este es el token de acceso que
que la app usará para obtener acceso durante el tiempo de ejecución a los recursos protegidos. El token de acceso para esta app es
ylSkZIjbdWybfs4fUQe9BqP0LH5Z
Ahora tienes un token de acceso válido, ylSkZIjbdWybfs4fUQe9BqP0LH5Z, que se puede usar
accedan a APIs protegidas.
Trabaja con la configuración predeterminada de OAuth
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 llamadas oauth. Puedes comenzar a usar el extremo del token en cuanto crees una cuenta. en Apigee Edge.
El extremo de OAuth predeterminado expone el siguiente URI de extremo:
/oauth/client_credential/accesstoken
Publica este URI para los desarrolladores que necesiten obtener tokens de acceso. Los desarrolladores de apps configuran que sus apps llamen a este extremo y presenten la clave de consumidor y los pares secretos para obtener acceso tokens.
El extremo del token de credenciales de cliente predeterminado se expone a través de la red en el siguiente URL:
https://{org_name}-{env_name}.apigee.net/oauth/client_credential/accesstoken
Por ejemplo, si el nombre de su organización es "apimakers", la URL sería la siguiente:
https://apimakers-test.apigee.net/oauth/client_credential/accesstoken
Esta es la URL a la que llaman los desarrolladores para obtener tokens de acceso.
Parámetros de configuración de OAuth de 3 segmentos
Configuraciones de OAuth de tres segmentos (código de autorización, implícito y concesión de contraseña) tipos) requieren que tú, el proveedor de API, autentiques a los usuarios finales de la app. Ya que cada la organización autentica a los usuarios de diferentes maneras, se requiere cierta personalización de políticas o cierto código para integrar OAuth con tu tienda de usuarios. Por ejemplo, todos los usuarios se pueden almacenar de Active Directory, en un LDAP o en algún otro almacén de usuarios. Para poner en marcha OAuth de tres segmentos, es necesario integrar una comprobación de este almacén de usuarios en el flujo general de OAuth.
OAuth 1.0a
Para obtener detalles sobre la política de OAuth 1.0a, consulta Política de OAuth v1.0a.
Obtener ayuda
Para obtener ayuda, consulta Apigee Asistencia al Cliente.