Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
El tipo de otorgamiento de contraseña de propietario de recurso (o “contraseña”) se usa, en su mayoría, en los casos en que la app es muy confiable. En esta configuración, el usuario proporciona sus credenciales de servidor de recursos (nombre de usuario/contraseña) a la app cliente, que las envía en una solicitud de token de acceso a Apigee Edge. Un servidor de identidad valida las credenciales y, si son válidas, Edge procede a crear un token de acceso y lo muestra a la app.
Acerca de este tema
En este tema, se ofrece una descripción general del flujo de otorgamiento de contraseñas de propietario de recursos de OAuth 2.0, y se explica cómo implementar este flujo en Apigee Edge.
Ejemplos que podrían resultarte útiles
- Solicitud de token de acceso: Tipo de otorgamiento de contraseña: Se muestra cómo formar una solicitud de token, configurar la política OAuthV2 para el tipo de otorgamiento de contraseña y cómo configurar un extremo para la política en Edge.
- oauth-validate-key-secret: Un proxy de muestra en GitHub que puedes implementar en Edge y, luego, probarlo. Es un ejemplo de extremo a extremo con el tipo de otorgamiento de contraseña. Demuestra una práctica recomendada, que es autenticar las credenciales de la app cliente (clave/secreto) antes de enviar las credenciales del usuario a un proveedor de identidad.
Video
Video: Mira este video sobre cómo implementar el tipo de otorgamiento de contraseña.
Casos prácticos
Este tipo de otorgamiento está destinado a aplicaciones de alta confianza o privilegiadas porque el usuario debe proporcionar sus credenciales del servidor de recursos a la aplicación. Por lo general, la app proporciona una pantalla de acceso en la que el usuario ingresa sus credenciales.
Diagrama de flujo
En el siguiente diagrama de flujo, se ilustra el flujo de tipo de otorgamiento de contraseña de propietario del recurso con la entrega de Apigee Edge como servidor de autorización.
Sugerencia: A fin de ver una versión más grande de este diagrama, haz clic con el botón derecho para abrirlo en una pestaña nueva. También puedes guardarlo y abrirlo en un visor de imágenes.
Pasos del flujo de tipo otorgamiento de contraseñas
Este es un resumen de los pasos necesarios para implementar el tipo de otorgamiento de contraseña donde Apigee Edge sirve como servidor de autorización.
Requisitos: La app cliente debe estar registrada en Apigee Edge para obtener el ID de cliente y las claves del secreto del cliente. Consulta Cómo registrar apps cliente para obtener más detalles.
1. El usuario inicia el flujo y, luego, ingresa las credenciales
Cuando la app necesita acceder a los recursos protegidos del usuario (por ejemplo, cuando el usuario hace clic en un botón de la app), se redirecciona al usuario a un formulario de acceso.
2. La app solicita un token de acceso de Apigee Edge
La app envía una solicitud de token de acceso, incluidas las credenciales del usuario, a un extremo de GenerateAccessToken en Apigee Edge.
A continuación, se muestra una solicitud POST de ejemplo, que incluye los parámetros necesarios para este tipo de otorgamiento:
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
De manera alternativa, ese comando podría realizarse de la siguiente manera, con la opción -u para curl a fin de crear el encabezado de autenticación básica codificado en base64 por ti.
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
(Todos estos comandos deben estar en una línea).
Las credenciales de usuario se encuentran en los parámetros de forma, mientras que las credenciales de cliente están codificadas en el encabezado de autenticación básico HTTP. Para obtener una descripción detallada de esta llamada a la API, incluidos los detalles sobre el encabezado de autenticación básica que se requiere, consulta la sección de otorgamiento de contraseñas de "Solicitud de tokens de acceso y códigos de autorización".
3. Edge valida la app cliente
Antes de enviar el nombre de usuario y la contraseña del usuario a un proveedor de identidad, Edge necesita saber que la app cliente que realiza la solicitud es una app válida y confiable. Una forma de hacerlo es usar la autenticación de la clave de API en la llamada a la API. En algunos casos, es posible que desees validar tanto la clave como el secreto del cliente. Hay un proxy de muestra que ilustra esta técnica generalizada en el repositorio api-platform-samples en GitHub.
4. Edge procesa las credenciales de acceso
Después de validar la app cliente, puedes usar una política de JavaScript o texto destacado de servicio para llamar al servicio de identidad y enviar las credenciales del usuario. Por ejemplo, podría ser un servicio de LDAP o cualquier servicio que quieras usar para validar las credenciales. Para obtener detalles sobre estas políticas, consulta la Política de extracción de variables y la política de JavaScript.
Si el servicio de identidad valida las credenciales y muestra una respuesta 200, Edge seguirá procesando la solicitud. De lo contrario, Edge deja de procesarse y muestra un error en la app cliente.
5. Ejecución de la política de OAuthV2
Si las credenciales son válidas, el siguiente paso de procesamiento es ejecutar una política de OAuthV2 configurada para el tipo de otorgamiento de contraseña. A continuación, se muestra un ejemplo. Los elementos <UserName> y <PassWord> son obligatorios y puedes recuperarlos de las variables de flujo que se guardaron con la política ExtractVariables. Para obtener información de referencia detallada sobre esta política, consulta la política de OAuthV2.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>360000000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>password</GrantType>
</SupportedGrantTypes>
<GrantType>request.queryparam.grant_type</GrantType>
<UserName>login</UserName>
<PassWord>password</PassWord>
<GenerateResponse/>
</OAuthV2>
Si esta política tiene éxito, se genera una respuesta al cliente que contiene un token de acceso. La respuesta está en formato JSON. A continuación, se muestra un ejemplo. Ten en cuenta que access_token es uno de los elementos:
{
"issued_at": "1420258685042",
"scope": "READ",
"application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
"refresh_token_issued_at": "1420258685042",
"status": "approved",
"refresh_token_status": "approved",
"api_product_list": "[PremiumWeatherAPI]",
"expires_in": "1799",
"developer.email": "tesla@weathersample.com",
"organization_id": "0",
"token_type": "BearerToken",
"refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
"client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
"access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
"organization_name": "docs",
"refresh_token_expires_in": "0",
"refresh_count": "0"
}
6. El cliente llama a la API protegida
Ahora, con un código de acceso válido, el cliente puede realizar llamadas a la API protegida. En este caso, las solicitudes se realizan a Apigee Edge (el proxy) y Edge es responsable de validar el token de acceso antes de pasar la llamada a la API al servidor de recursos de destino. Los tokens de acceso se pasan en un encabezado de autorización. Por ejemplo:
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282