OAuth autenticación en API Gateway

Editar en línea

La autorización abierta es un marco de autorización flexible para proteger el acceso de las aplicaciones a los recursos protegidos de las API. webMethods API Gateway puede conectarse al servidor OAuth de su elección para autorizar aplicaciones cliente. webMethods API Gateway También incluye un servidor de autorización integrado que admite OAuth 2.0 para proteger sus API. Este artículo explica cómo utilizar la funcionalidad « OAuth » ( 2.0 ) en webMethods API Gateway.

El marco de autorización OAuth 2.0 permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre del propietario de un recurso, coordinando una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o permitiendo que la aplicación de terceros obtenga acceso en su propio nombre. Para más detalles, véase https://tools.ietf.org/html/rfc6749.

OAuth Añade una nueva capa denominada «Capa de autorización» para permitir el acceso a la información protegida a los clientes. A diferencia del protocolo OAuth 1.0, OAuth 2.0 proporciona un marco de autorización completo (no un protocolo) con propiedades de seguridad bien definidas. Sin embargo, al tratarse de un marco rico y altamente extensible con muchos componentes opcionales, es probable que esta especificación, por sí sola, dé lugar a una amplia gama de implementaciones no interoperables. Además, esta especificación deja algunos componentes necesarios parcial o totalmente sin definir (por ejemplo, el registro de clientes, las capacidades del servidor de autorización, la detección de puntos finales). Sin estos componentes, los clientes deben configurarse de forma manual y específica con respecto a un servidor de autorización y un servidor de recursos concretos para poder interoperar.

OAuth define cuatro funciones.

  • Propietario del recurso (o usuario final). Este es el contenedor de los recursos protegidos a los que accede la aplicación cliente. El propietario del recurso suele ser una persona (normalmente el usuario final), pero también podría ser una aplicación.
  • Servidor de recursos (o webMethods API Gateway ). Este es el servidor que almacena los recursos protegidos a los que la aplicación intenta acceder y es capaz de aceptar y responder a las solicitudes de recursos protegidos utilizando tokens de acceso. webMethods API Gateway actúa como servidor de recursos.
  • Aplicación cliente (o el cliente). Esta es la aplicación que solicita acceso a recursos protegidos en nombre del propietario del recurso y con su autorización.
  • Servidor de autorización. Este es el servidor que actúa como interfaz entre la aplicación cliente y el usuario final, autentica al usuario final y emite tokens de acceso a los clientes tras la autorización correspondiente. webMethods API Gateway Se puede configurar para que actúe como un servidor de autorización OAuth 2.0. Puede configurarlo webMethods API Gateway para utilizarlo con un servidor de autorización de terceros OAuth 2.0, como OKTA y PingFederate.

El servidor de recursos y el servidor de autorización interactúan entre sí para verificar los tokens de acceso. Puede haber varios niveles de estas interacciones (3 patas OAuth, 4 patas OAuth, etc.). webMethods API Gateway Se puede utilizar como servidor de autorización y como servidor de recursos.

Los clientes pueden ser de los siguientes tipos:

  • Confidencial. Un cliente confidencial es una aplicación capaz de mantener la contraseña del cliente confidencial ante el mundo. Esta contraseña de cliente es asignada a la aplicación cliente por el servidor de autorización. Esta contraseña se utiliza para identificar al cliente ante el servidor de autorización, con el fin de evitar fraudes. Un ejemplo de cliente confidencial es una aplicación web, en la que nadie más que el administrador puede acceder al servidor y ver la contraseña del cliente.
  • Público. Un cliente público es una aplicación que no es capaz de mantener la confidencialidad de la contraseña del cliente. Por ejemplo, una aplicación para teléfonos móviles o una aplicación de escritorio que tenga la contraseña del cliente integrada en su interior. Una aplicación de este tipo podría ser pirateada, lo que podría revelar la contraseña. Lo mismo ocurre con una JavaScript aplicación que se ejecuta en el navegador del usuario. El usuario podría utilizar un JavaScript depurador para examinar la aplicación y ver la contraseña del cliente.

API Gateway como servidor de recursos

Cuando webMethods API Gateway actúa como servidor de recursos, aloja los recursos protegidos, acepta y responde a las solicitudes de las aplicaciones cliente que incluyen un token de acceso. La aplicación cliente envía el token de acceso en el campo del encabezado de la solicitud de autorización utilizando el esquema de autenticación Bearer. El servidor de recursos valida el token de acceso localmente o de forma remota si no puede validarlo localmente.

Si el token es válido y la aplicación cliente tiene privilegios para acceder a los recursos protegidos, el servidor de recursos ejecuta la solicitud. Si el token de acceso no es válido, rechaza la solicitud.

API Gateway como servidor de autorización

Cuando webMethods API Gateway actúa como servidor de autorización, recibe solicitudes de autorización de aplicaciones cliente. El servidor de autorización gestiona las interacciones entre la aplicación cliente, el servidor de recursos y el propietario de los recursos para aprobar la solicitud.

Como servidor de autorización webMethods API Gateway, emite tokens a las aplicaciones cliente en nombre del propietario de un recurso para su uso en la autenticación de llamadas API posteriores al servidor de recursos. El servidor de recursos aloja los recursos protegidos y puede aceptar o responder a las solicitudes de recursos protegidos utilizando tokens de acceso. Si la aplicación cliente está autorizada para acceder a los recursos protegidos, el servidor de recursos ejecuta la solicitud. El servidor de autorización conserva la información sobre los tokens de acceso que emite, incluida la información del usuario. Cuando un cliente presenta un token de acceso al servidor de recursos, este envía el token al servidor de autorización para garantizar que sea válido y que el servicio solicitado se encuentre dentro del ámbito para el que se emitió el token de acceso. Un ámbito es la definición de los recursos a los que la aplicación cliente puede acceder en nombre del propietario de los recursos. Si la aplicación cliente no tiene privilegios para acceder a los recursos, el servidor de recursos rechaza la solicitud.

Uso API Gateway con un servidor de autorización externo

Cuando webMethods API Gateway es el servidor de recursos, debe especificar un servidor de autorización. Como alternativa al uso webMethods API Gateway de como servidor de autorización, puede utilizar un servidor de terceros como servidor de autorización. Esto permite webMethods API Gateway validar los tokens de acceso emitidos por servidores de terceros y también permite crear clientes de forma dinámica en el servidor de terceros.

Nota:
  • Antes de configurar webMethods API Gateway para utilizar un servidor de autorización de terceros, asegúrese de que el servidor de autorización cumple con la introspección de tokens RFC 7662, OAuth 2.0.
  • A partir de webMethods API Gateway la versión 10.3, webMethods API Gateway admite múltiples servidores de autorización.

Para utilizar un servidor de autorización externo, debe configurar su servidor de autorización de terceros. Esto incluye, entre otros, lo siguiente:

  • Para introspectar el token, debe tener un URI JWKS o debe crear una cuenta de cliente que webMethods API Gateway utilice para llamar al punto final de introspección del servidor de autorización.

    Anote los valores de client_id y client_secret. Proporciona esta información como parte de la definición del alias del servidor de autorización externo para el webMethods API Gateway servidor de recursos.

    La validación del token JWT del servidor de autorización externo se realiza de las siguientes maneras:

    Tabla 1. Validación del token JWT
    Introspección local Introspección remota
    La validación del token JWT se realiza dentro de la puerta de enlace mediante los siguientes métodos:
    • Uso de JWKS URI.

      La firma del servidor de autorización externo se verifica utilizando el certificado público en el URI JWKS.

      webMethods API Gateway La caché tiene una clave como kid claim y su valor es el certificado correspondiente a la kid claim. La caché se rellena cada vez que se webMethods API Gateway reinicia invocando el URI JWKS.

      En tiempo de ejecución, al validar el token mediante la introspección local, se obtiene el valor kid del JWT entrante y se recupera el certificado correspondiente de la caché, tras lo cual se lleva a cabo la validación de la firma.

    • Utilizando RSA.

      La firma del servidor de autorización externo en el JWT se verifica mediante el almacén de confianza definido en la configuración de introspección local.

    • Uso de HMAC.

      Si el servidor de autorización utiliza el algoritmo HMAC, eso significa que la validación de la firma del JWT se realiza utilizando una clave compartida entre el servidor de autorización y webMethods API Gateway. Debe especificar el secreto compartido HMAC al crear la estrategia de la aplicación. El secreto compartido HMAC de la aplicación se utiliza para validar la firma del servidor de autorización presente en JWT.

    		 La validación del token JWT se realiza con el servidor de autorización. Por lo tanto, el almacenamiento en caché de tokens no es posible en la introspección remota.

    Tiene un punto final de introspección, que se utiliza para validar el token. Además, el ID de cliente y el secreto de cliente se utilizan para proteger el punto final, de modo que los usuarios anónimos no puedan acceder al recurso. Para invocar un punto final, se necesita un usuario; el usuario de la puerta de enlace es el que se puede utilizar para invocar el punto final.

    Anote el URL para el punto final de introspección. Proporciona esta información como parte de la definición del alias del servidor de autorización externo en el webMethods API Gateway servidor de recursos.

  • Cree los ámbitos necesarios.
  • Configure un alias para el servidor de autorización.

Actualmente, de forma webMethods API Gateway predeterminada, se puede utilizar con los siguientes servidores de autorización de terceros, entre otros, que cumplen con la introspección de tokens RFC 7662, OAuth 2.0 :

  • Okta
  • PingFederate

También puede utilizar otros servidores de autorización de terceros, como Google Keycloak, etc.

Autorizaciones para aplicaciones creadas desde el Portal para desarrolladores

Cuando cree aplicaciones a través del Portal para desarrolladores, deberá especificar el servidor de autorización requerido utilizando la configuración de watt.server.oauth.authServer.alias en la sección Administración de webMethods API Gateway.

Si webMethods API Gateway es el servidor de autorización, proporcione local como valor de la configuración watt.server.oauth.authServer.alias. De lo contrario, proporcione el nombre del servidor de autorización correspondiente. Para obtener información sobre la configuración avanzada, consulte Configuración de la configuración avanzada.

OAuth flujo de trabajo de autorización

El flujo de trabajo de autorización de « OAuth » es el siguiente:
  1. El cliente envía una solicitud de autenticación de usuario al servidor de autorización (local o externo) para obtener un token de acceso.
  2. El servidor de autorización valida la solicitud, autentica al cliente y genera un token de acceso para el cliente.
  3. El cliente utiliza este token de acceso para enviar HTTP solicitudes a webMethods API Gateway.

    webMethods API Gateway luego realiza lo siguiente:

    1. Identifica la aplicación utilizando el clientId.
    2. Valida el token localmente o de forma remota si no es posible hacerlo localmente.
    3. Comprueba si el recurso solicitado forma parte de los ámbitos del token.
    4. Comprueba el público.
  4. Después de validar al cliente, la solicitud se dirige al servidor interno.

    Si el token de acceso ha caducado, el servidor de autorización devuelve una respuesta de error específica. La aplicación cliente puede entonces utilizar el token de actualización para solicitar un nuevo token de acceso. El servidor de autorización devuelve un nuevo token de acceso que se puede utilizar para acceder al recurso protegido.

    Nota: Cuando se registra un evento de infracción de la política en caso de tokens Oauth2 caducados, la aplicación asociada pasa a ser Desconocida.
  5. El servidor interno envía la respuesta con el recurso solicitado a webMethods API Gateway.
  6. webMethods API Gateway luego envía el recurso de solicitud protegido al cliente.

Tipos de concesión de autorización admitidos

OAuth 2.0 ofrece varios tipos de subvenciones, en función del flujo de trabajo que requiera su solicitud. El servidor de autorización webMethods API Gateway local admite los siguientes tipos de concesión. Las API se pueden habilitar para más de un tipo de subvención. Esta tabla enumera los tipos de subvenciones y las solicitudes para las que son adecuadas.

Tabla 2. Tipos de otorgamiento
Tipo de concesión Adecuado para
Código de autorización Aplicaciones web normales que se ejecutan en un servidor.
Implícito Aplicaciones de página única.
Credenciales de contraseña del propietario del recurso Aplicaciones en las que se puede confiar plenamente con las credenciales de los usuarios.
Señal para renovación Para proteger aún más las aplicaciones que requieren los tipos de concesión «Código de autorización» o «Implícito».
Credenciales de cliente Aplicaciones que solo implican interacciones entre máquinas.

Código de autorización

El tipo de concesión del código de autorización permite a los proveedores de API abrir sus API a desarrolladores de aplicaciones de terceros desconocidos (pero registrados). Esta concesión permite un flujo en el que las credenciales de usuario nunca se comparten con la aplicación cliente. Los usuarios son redirigidos al servidor de autorización para autenticarse. Solo cuando los usuarios se autentican y conceden los permisos necesarios a la aplicación cliente, esta puede acceder a sus recursos.

¿Cuándo se debe utilizar el tipo de concesión de código de autorización?

Utilice el tipo de concesión de código de autorización en situaciones en las que la API se abre a desarrolladores de aplicaciones de terceros desconocidos y exponer las credenciales del usuario supone un riesgo.

El agente de usuario (navegador web) es un componente necesario de este flujo, ya que muchos de los pasos, como la autenticación del usuario, la concesión de permisos de acceso, el envío de un código de autorización a la aplicación y la verificación de la autenticidad de la aplicación cliente, se realizan redirigiendo el navegador web a diferentes URL. Por lo tanto, se puede implementar en aplicaciones que se ejecutan en un navegador web o que pueden acceder a un navegador web.

Es adecuado para:

  • Aplicaciones web que se ejecutan en un servidor
  • Aplicaciones móviles que pueden acceder a un navegador web

Este diagrama ilustra el flujo para el tipo de concesión del código de autorización

Tipo de otorgamiento de código de autorización

Para los clientes públicos, el tipo de concesión del código de autorización se puede proteger aún más mediante el mecanismo PKCE. Para obtener más información, consulte Proteger las llamadas de token de acceso con PKCE.

Nota: webMethods API Gateway admite la autenticación confidencial del cliente mediante encabezados de autorización. Los clientes confidenciales deben autenticarse utilizando sus credenciales, la combinación de ID de cliente y secreto de cliente. Algunos puntos a tener en cuenta al utilizar el tipo de concesión de código de autorización:
  • Si la propiedad watt.server.oauth.token.endpoint.auth=session (el valor predeterminado) y el cliente confidencial ya tienen una sesión cuando se trata del punto final del token, se concede el acceso al punto final incluso si no hay credenciales en el encabezado.
  • Si la propiedad watt.server.oauth.token.endpoint.auth=credentials o si el cliente aún no tiene una sesión, el cliente confidencial debe proporcionar el client_secret en el encabezado Authorization.
  • webMethods API Gateway No admite el secreto del cliente en el cuerpo de la solicitud para la concesión del código de autorización.

Para obtener más información sobre las propiedades mencionadas, consulte la Guía del administrador del servidor IBMwebMethods Integration.

implicit

El tipo de concesión implícita es similar al flujo del código de autenticación, pero el token de acceso se proporciona al agente de usuario para que lo reenvíe a la aplicación. Esto expone el token al usuario y a otras aplicaciones en el dispositivo del usuario. Además, este tipo de concesión no autentica la identidad de la aplicación y se basa en el URI de redireccionamiento (que se registró con el servicio) para cumplir este propósito.

Además, el tipo de concesión implícita no admite tokens de actualización. Este diagrama ilustra el flujo para el tipo de concesión implícita

Tipo de otorgamiento implícito

El flujo para el tipo de concesión implícita es similar al flujo para el tipo de concesión de código de autorización, excepto que el servidor de autorización envía un token de acceso al agente de usuario en lugar de un código de autorización. A continuación, el agente de usuario pasa el token de acceso a la aplicación cliente.

¿Cuándo se debe utilizar el tipo de concesión implícita?

Debe utilizar el tipo de concesión implícita solo con aplicaciones desarrolladas y publicadas por partes de confianza. Es adecuado para aplicaciones de una sola página que se ejecutan en el navegador web, ya que no pueden ejecutar el flujo requerido por el tipo de concesión de código de autenticación, más seguro y elaborado

Credenciales de contraseña del propietario del recurso

En el flujo para el tipo de concesión de credenciales de contraseña del propietario del recurso, los usuarios introducen su nombre de usuario y contraseña para un recurso directamente en la aplicación cliente. A continuación, la aplicación cliente pasa las credenciales al servidor de autenticación para autenticar al usuario y obtener un token de acceso.

Este diagrama ilustra el flujo para el tipo de concesión de credenciales de contraseña del propietario del recurso.

Tipo de concesión de credenciales de contraseña del propietario del recurso

La aplicación cliente solicita al usuario sus credenciales y las envía al servidor de autorización. En respuesta, el servidor de autorización envía el token de acceso directamente a la aplicación cliente.

¿Cuándo se debe utilizar el tipo de concesión de credenciales con contraseña del propietario del recurso?

El tipo de concesión de credenciales de contraseña del propietario del recurso solo se puede utilizar cuando los usuarios confían en la aplicación cliente con sus credenciales para un recurso. Esto suele ocurrir cuando la aplicación cliente pertenece a la misma entidad que aloja el recurso o servicio al que la aplicación cliente intenta acceder.

Este tipo de subvención solo debe utilizarse si los demás tipos de subvención no son viables.

Credenciales de cliente

Este es el tipo de concesión utilizado para obtener tokens de acceso para la autenticación exclusiva del cliente.

El tipo de concesión de credenciales de cliente es similar al tipo de concesión de credenciales de contraseña del propietario del recurso. La diferencia es que, en lugar de las credenciales del usuario, la aplicación cliente proporciona su propio cliente y secreto. Este tipo de subvención está destinado a flujos en los que no intervienen usuarios.

Este diagrama ilustra el flujo para el tipo de concesión de credenciales de cliente.

Tipo de otorgamiento de credenciales de cliente:

Los pasos son similares al flujo de credenciales de contraseña del propietario del recurso. Los clientes utilizan sus ID de cliente y claves secretas para identificarse. Si la operación se realiza correctamente, el servidor de autorización devuelve tokens de acceso. Evite utilizar tokens de actualización en este flujo, ya que aumenta el riesgo de exponer las credenciales del cliente.

¿Cuándo se debe utilizar el tipo de concesión de credenciales de cliente?

En este tipo de concesión, los usuarios no necesitan autenticarse ni autorizar el acceso a un recurso o servicio concreto. Este tipo de concesión es adecuado para situaciones como las aplicaciones cliente que acceden a sus propios recursos. Por ejemplo: una aplicación cliente que recupera datos de su propia cuenta