Habilitar la recuperación y revocación de tokens de acceso de OAuth 2.0 por ID de usuario final, ID de aplicación o ambos

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

Esta sección describe cómo habilitar la recuperación y la revocación de tokens de acceso de OAuth 2.0 mediante ID de usuario final, ID de aplicación o ambos. La función de ID de usuario final requiere una configuración especial, tal como se describe en este en este tema. Por usuario final se entiende el usuario de la aplicación que llama a la API.

Cuándo habilitar el acceso por ID de usuario final

A veces, es útil almacenar el ID de usuario en un token de acceso. Habilita el acceso al ID del usuario final solo si tienes un buen caso de uso para usarla. Por ejemplo:

  • Una función para tu sitio web o app en la que los usuarios pueden ver qué apps de terceros autorizaron y proporcionar una opción para revocar el acceso a esas apps
  • Una función que permite que un usuario autorizado revoca todos los tokens de acceso asociados con una app de desarrollador específica

Información sobre los tokens de acceso de OAuth

Los IDs de app se agregan automáticamente a un token de acceso de OAuth. Por lo tanto, después de habilitar el token acceso para una organización, como se describe a continuación, puedes revocar tokens de acceso por ID de app.

Para recuperar y revocar tokens de acceso de OAuth 2.0 por ID de usuario final, debe haber un ID de usuario final en los tokens de acceso. El siguiente procedimiento describe cómo agregar un ID de usuario final a un ID token.

De forma predeterminada, cuando Edge genera un token de acceso de OAuth 2.0, el token tiene el formato que se muestra a continuación:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

Ten en cuenta lo siguiente:

  • El campo application_name contiene el UUID de la app asociada con el token. Si habilitas la recuperación y la revocación de tokens de acceso de OAuth 2.0 por ID de app, este es el ID de app que usas.
  • El campo access_token contiene el valor del token de acceso de OAuth 2.0.

No hay ningún campo para el ID del usuario final en el token de acceso predeterminado de OAuth. Para permitir la recuperación y revocación de los tokens de acceso de OAuth 2.0 por ID del usuario final, debes configurar la política de OAuth 2.0 para incluir el ID de usuario en el token, tal como se describe en el procedimiento a continuación. Ten en cuenta que si solo si quieres recuperar y revocar tokens de acceso de OAuth 2.0 por ID de app, no es necesario habilitarlo el acceso por ID de usuario final.

Debes pasar el ID del usuario final al extremo de creación del token. Puedes pasar el ID del usuario final como un parámetro de búsqueda, un parámetro del formulario o en un encabezado (como se explica más adelante en este tema). Después de configurar Edge para que incluya al usuario final ID en el token, se incluye como el campo app_enduser, como se muestra a continuación:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "app_enduser" : "6ZG094fgnjNf02EK",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

Para obtener información sobre cómo realizar las llamadas a la API que realizan estas recuperaciones y revocaciones, consulta los siguientes documentos inteligentes:

Habilita el acceso a los tokens de OAuth 2.0 por ID de usuario y por ID de app

La forma en que habilitas el acceso a los tokens de OAuth 2.0 por ID de usuario y de app depende de cómo implementaste Perímetro:

  • Implementación basada en la nube

    Una implementación de Edge basada en la nube significa que Apigee controla la mayor parte de la configuración. Tú solo son responsables de configurar la política de OAuth 2.0 para agregar el ID de usuario al acceso token. Para obtener más información, consulta el siguiente procedimiento.

  • Edge para la implementación de la nube privada

    En Apigee Edge para la nube privada (local), es completamente responsable de configuración. Para obtener más información, consulta la guía Operaciones y Configuración.

  • Apigee Hybrid

    El acceso a los tokens de OAuth 2.0 por ID de usuario está habilitado de forma predeterminada. Tú solo son responsables de configurar la política de OAuth 2.0 para agregar el ID de usuario al acceso token. Para obtener más información, consulta el paso 5 del procedimiento a continuación.

Habilita el acceso en la nube

Paso 1: Habilita una organización para admitir esta función

Esta función debe estar habilitada para todas las organizaciones en las que quieras proporcionarla.

Comunícate con el equipo de asistencia de Apigee Edge para que actualicen tu organización.

Paso 2: Proporciona permisos de recursos deoauth2 para funciones opsadmin y orgadmin

Solo tus funciones orgadmin y opsadmin deberían tener permisos para realizar estas llamadas de recuperación (get ) y revocación (put) al recurso de oauth2 basado en el ID de usuario final o el ID de la app.

Puedes usar la llamada a la API Obtener permiso para un recurso a fin de ver qué funciones tienen los permisos get y put para el recurso deoauth2.

Si necesitas agregar o quitar permisos, comunícate con el equipo de asistencia de Apigee Edge para para que realicen las actualizaciones.

Paso 3: Copia los tokens de acceso de OAuth 2.0 existentes a tus nodos de Cassandra

Realizado por la asistencia de Apigee: En esta tarea, se copian las copias de OAuth 2.0 existente. los tokens de acceso de las organizaciones afectadas se copiarán y se almacenarán en tus nodos de Cassandra. Este procedimiento se realizará en los nodos de Cassandra para cada uno de sus Pods de Apigee Edge. Esto permitirá que el recuperar y revocar llamadas de API para que se ejecuten contra todos tus tokens de acceso de OAuth 2.0, existentes y recién generado.

Paso 4: Agrega la propiedad oauth_max_search_limit a tu servidor de administración y mensaje encargado del tratamiento de datos

En esta tarea, los archivos keymanagement.properties del servidor de administración y se actualizará el procesador de mensajes para incluir esta propiedad: oauth_max_search_limit = 100. 100 es el valor que recomienda Apigee, pero puedes configurarlo según tus necesidades.

Comunícate con el equipo de asistencia de Apigee Edge para que realicen esta incorporación.

Paso 5: Configura una política de OAuth 2.0 para generar tokens de acceso que incluyan los IDs de usuario final

Configura la política de OAuth 2.0 que se usa para generar tokens de acceso para incluir el ID del usuario final en token. Si incluyes los IDs de usuario final en los tokens de acceso, podrás realizar recuperaciones. y revoca por ID de usuario final.

Para configurar la política de modo que incluya un ID de usuario final en un token de acceso, debes especificar la variable de entrada que contiene el ID de usuario final. Usa la etiqueta <AppEndUser> para especificar la de salida.

La siguiente política de OAuth 2.0, llamada GenerateAccessTokenClient, genera un 2.0. Observa el agregado de la etiqueta <AppEndUser> en negrita:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
  <DisplayName>OAuth 2.0.0 1</DisplayName>
  <ExternalAuthorization>false</ExternalAuthorization>
  <Operation>GenerateAccessToken</Operation>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse enabled="true"/>
  <GrantType>request.queryparam.grant_type</GrantType>
  <AppEndUser>request.header.appuserID</AppEndUser>
  <ExpiresIn>960000</ExpiresIn>
</OAuthV2>

Luego, puedes usar el siguiente comando cURL para generar el token de acceso de OAuth 2.0 y pasar el ID de usuario como appuserID encabezado:

curl -H "appuserID:6ZG094fgnjNf02EK" /
  https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials /
  -X POST /
  -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'

En este ejemplo, el appuserID se pasa como un encabezado de la solicitud. Puedes pasar información como parte de una solicitud de muchas maneras. Por ejemplo, como alternativa puedes hacer lo siguiente:

  • Usa una variable de parámetro de formulario: request.formparam.appuserID
  • Usa una variable de flujo que proporcione el ID de usuario final