Implementar el tipo de autorización de contraseña

Esta página se aplica a Apigee y Apigee hybrid.

Consulta la documentación de Apigee Edge.

El tipo de concesión de contraseña del propietario del recurso (o "contraseña") se usa principalmente en los casos en los que la aplicación es de confianza. En esta configuración, el usuario proporciona sus credenciales del servidor de recursos (nombre de usuario y contraseña) a la aplicación cliente, que las envía en una solicitud de token de acceso a Apigee. Un servidor de identidades valida las credenciales y, si son válidas, Apigee genera un token de acceso y lo devuelve a la aplicación.

Sobre este tema

En este tema se ofrece una descripción general del flujo de tipo de autorización de contraseña del propietario del recurso de OAuth 2.0 y se explica cómo implementar este flujo en Apigee.

Ejemplos que te pueden resultar útiles

• Usar el tipo de concesión de contraseña: se explica cómo crear una solicitud de token, configurar la política OAuthV2 para el tipo de concesión de contraseña y configurar un endpoint para la política en Apigee.
• oauth-validate-key-secret: un proxy de ejemplo en GitHub que puedes implementar en Apigee y probar. Es un ejemplo completo que incluye el tipo de autorización de contraseña. Muestra una práctica recomendada, que consiste en autenticar las credenciales (clave o secreto) de la aplicación cliente antes de enviar las credenciales del usuario a un proveedor de identidades.

Nota: Este vídeo se grabó con una versión anterior de la interfaz de usuario de Apigee, pero los conceptos siguen siendo válidos.

Vídeo

Vídeo: consulta este vídeo sobre cómo implementar el tipo de autorización de contraseña.

Casos prácticos

Este tipo de concesión está pensado para aplicaciones de alta confianza o privilegiadas, ya que el usuario debe proporcionar sus credenciales del servidor de recursos a la aplicación. Normalmente, la aplicación proporciona una pantalla de inicio de sesión en la que el usuario introduce sus credenciales.

Diagrama de flujo

En el siguiente diagrama de flujo se muestra el flujo del tipo de concesión de contraseña del propietario del recurso con Apigee como servidor de autorización.

Nota: Para ver una versión más grande de este diagrama, haz clic con el botón derecho y ábrelo en una pestaña nueva, o guárdalo y ábrelo en un visor de imágenes.

Pasos del flujo del tipo de autorización de contraseña

A continuación, se resumen los pasos necesarios para implementar el tipo de concesión de contraseña en el que Apigee actúa como servidor de autorización.

Requisito previo: La aplicación cliente debe registrarse en Apigee para obtener el ID de cliente y las claves secretas de cliente. Para obtener más información, consulta el artículo sobre registro de aplicaciones cliente.

1. El usuario inicia el flujo e introduce las credenciales

Cuando la aplicación necesita acceder a los recursos protegidos del usuario (por ejemplo, cuando el usuario hace clic en un botón de la aplicación), se le redirige a un formulario de inicio de sesión.

2. La aplicación solicita un token de acceso a Apigee

La aplicación envía una solicitud de token de acceso, que incluye las credenciales del usuario, a un endpoint GenerateAccessToken en Apigee.

Nota: Para obtener información sobre cómo configurar los endpoints, incluidos los endpoints de OAuth predeterminados, consulta Comprender los endpoints de OAuth.

A continuación, se muestra una solicitud POST de ejemplo que incluye los parámetros obligatorios de este tipo de concesión:

$ 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

También puedes ejecutar ese comando de la siguiente forma, usando la opción -u de curl para crear el encabezado de autenticación básica codificado en base64.

$ 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

Cada uno de esos comandos debe estar en una sola línea.

Las credenciales de usuario se incluyen en los parámetros del formulario, mientras que las credenciales de cliente se codifican en el encabezado de autenticación básica HTTP. Para obtener una descripción detallada de esta llamada a la API, incluidos los detalles sobre el encabezado de autenticación básica necesario, consulta la sección de concesión de contraseñas del artículo Obtener tokens de OAuth 2.0.

3. Apigee valida la aplicación cliente

Antes de enviar el nombre de usuario y la contraseña del usuario a un proveedor de identidades, Edge debe saber que la aplicación cliente que realiza la solicitud es una aplicación válida y de confianza. Una forma de hacerlo es usar la autenticación con clave de API en la llamada a la API. En algunos casos, puede que quieras validar tanto la clave de cliente como el secreto. Hay un proxy de ejemplo que ilustra esta técnica alternativa en el repositorio api-platform-samples de GitHub.

4. Apigee trata las credenciales de inicio de sesión

Una vez que se haya validado la aplicación cliente, puedes usar una política Service Callout o JavaScript para llamar al servicio de identidad y enviar las credenciales del usuario. Por ejemplo, podría ser un servicio LDAP o cualquier servicio que quieras usar para validar las credenciales. Para obtener más información sobre estas políticas, consulte la política de extracción de variables y la política de JavaScript.

Si el servicio de identidad valida las credenciales y devuelve una respuesta 200, Apigee continuará procesando la solicitud. De lo contrario, Apigee detendrá el procesamiento y devolverá un error a la aplicación cliente.

5. La política OAuthV2 se ejecuta

Si las credenciales son válidas, el siguiente paso es ejecutar una política de OAuthV2 configurada para el tipo de concesión de contraseña. Aquí tienes un ejemplo. Los elementos <UserName> y <PassWord> son obligatorios y puedes obtenerlos 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 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 se aplica correctamente, se genera una respuesta para el cliente que contiene un token de acceso. La respuesta está en formato JSON. Aquí tienes 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": "[e-mail]",
    "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 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. Los tokens de acceso se transfieren en un encabezado Authorization. Por ejemplo:

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282