Header Ads Widget

Ticker

6/recent/ticker-posts

OpenID Connect: descripción general del perfil de API de grado financiero (FAPI)





La banca abierta sigue siendo un tema de gran interés en los servicios financieros, alcanzando el estatus de “palabra de moda” en los últimos años. Hemos cubierto el crecimiento del ecosistema en el blog varias veces antes, pero aún no hemos estudiado los estándares emergentes tanto dentro como entre los mercados bancarios abiertos. No es de extrañar que las iniciativas de banca abierta hayan impulsado varios avances notables en los estándares. En esta publicación, veremos un conjunto de estándares que se enfocan en mejorar la seguridad de la API: el perfil de API de grado financiero (FAPI) .

¿Qué es FAPI?

FAPI es un grupo de trabajo de OpenID Foundation , el organismo responsable del desarrollo y mantenimiento de una familia de estándares de protocolo centrados en OpenID Connect . FAPI se inició en 2017 y buscaba brindar mayor seguridad a los nuevos estándares API que se están creando para implementar las regulaciones PSD2 en toda Europa, uno de los impulsores clave en el zumbido en torno a la banca abierta.

El alcance, sin embargo, no se limita a PSD2 y al aspecto regulatorio de la banca abierta. Según FAPI, su objetivo es proporcionar un "mayor nivel de seguridad que el proporcionado por OAuth estándar o OpenID Connect". Los estándares también se refieren con frecuencia al rastreo de pantalla y al propósito de reemplazar este método con "un modelo de API con datos estructurados y un modelo de token, como OAuth".

Para los usuarios actuales de OAuth y OpenID Connect, los beneficios pueden parecer obvios, pero para los no iniciados:

  • Uno de los objetivos principales de OAuth es garantizar que el Usuario final, un ser humano real, no tenga que dar sus credenciales confidenciales cuando comparte datos con otra aplicación.
  • Al ofrecer un modelo de acceso delegado, OAuth se asegura de que la aplicación Cliente, la "Parte de confianza", nunca vea esas credenciales, sino que utilice un token de acceso.
  • OpenID Connect se suma a este modelo al proporcionar pruebas de autenticación de que la aplicación ha delegado acceso a una API en nombre del usuario final y prueba de que el ser humano real realmente se autenticó. Como cubrimos en nuestra introducción a OpenID Connect , no tener pruebas de autenticación puede estar bien para twittear su mejor puntaje en Wordscapes, pero no es tan bueno cuando acepta una instrucción de pago de una aplicación que puede o no estar actuando en nombre. de un usuario final autenticado.

OAuth tiene sus detractores, especialmente en la forma en que el mecanismo de redirección para autenticar al usuario final introduce fricciones. Sin embargo, los argumentos a favor de los beneficios de seguridad son sólidos. Por lo tanto, FAPI usa OAuth como perfil base por una buena razón. La FAPI actualmente incorpora cuatro estándares, todos actualmente especificados como Borradores del Implementador (en el lenguaje de los estándares, un Borrador del Implementador significa “suficientemente estable para implementar, pero no aprobado formalmente”). Estos son:

En términos generales, las Partes 1 y 2 y JARM se preocupan por fortalecer la implementación de OAuth 2.0 y OpenID Connect, mientras que CIBA proporciona un nuevo medio para solicitar la autenticación de un Usuario final. Cada perfil tiene implicaciones tanto para el proveedor de API como para el consumidor, que analizaremos a continuación.

El objeto de este artículo es ofrecer una descripción general de nivel relativamente alto de lo que significan estos estándares para los proveedores y consumidores de API. Planeamos incluir guías técnicas más detalladas y ejemplos de uso en publicaciones futuras.

Los perfiles de solo lectura y lectura-escritura son efectivamente las especificaciones “básicas” para las organizaciones que desean dar fe del nivel de seguridad que se percibe como necesario para operar las API de servicios financieros. El criterio de entrada es OpenID Connect 1.0; Ambos estándares utilizan esto como su componente básico.

Adición de resiliencia: el perfil de solo lectura

El perfil de solo lectura tiene como objetivo el acceso de solo lectura a la cuenta de un usuario final e introduce funciones que se incluyen en los otros perfiles. El objetivo es especificar los comportamientos que adoptarán los actores al interactuar para proporcionar datos basados ​​en cuentas. Éstas incluyen:

  • Imponer niveles sólidos de autenticación para los clientes , incluida la seguridad de la capa de transporte mutua (TLS) y un mecanismo basado en JSON Web Token (JWT) para autenticar al cliente a nivel de aplicación.
  • Hacer cumplir los niveles de autenticación para el usuario final , específicamente en el nivel 2 del marco de garantía de autenticación de entidad especificado por ISO Esto es importante para brindar a la aplicación Cliente la certeza sobre cómo se autentica el Usuario final.
  • Implementar niveles de criptografía lo suficientemente fuertes para proteger a las partes involucradas , como imponer longitudes de clave mínimas de 2048 bits para algoritmos RSA.
  • Reforzar otros comportamientos permitidos dentro de la especificación principal de OAuth 2.0 , como requerir que todas las redirect_uriconfiguraciones estén registradas previamente en el servidor de autorización.
  • Asegurarse de que se utilicen períodos de vida cortos para los tokens de acceso que son tokens de portador , dada la cantidad de extremos diferentes a los que pueden estar expuestos en un escenario de acceso a la cuenta

A un nivel muy práctico, el perfil de solo lectura también exige el uso de JSON en cargas útiles de solicitud / respuesta. Introduce varios encabezados que permiten la identificación y el seguimiento consistentes de eventos, siendo los temas bastante típicos en las API de servicios financieros:

  • x-fapi-interaction-id: Un UUID que proporciona una referencia única que se creará para cada solicitud / respuesta.
  • x-fapi-auth-date: La fecha y la hora en que la aplicación cliente autenticó por última vez al usuario final.
  • x-fapi-customer-ip-address: La dirección IP del usuario final, si está disponible.

El perfil de solo lectura, por lo tanto, proporciona estándares para ajustar los parámetros operativos en un grado que se considere adecuado para compartir el acceso a la cuenta.

Prueba de balas: el perfil de lectura y escritura

El perfil de lectura y escritura agrega restricciones adicionales que se consideran aplicables para crear o actualizar los datos de la cuenta, por ejemplo, al iniciar un pago. Podría decirse que las restricciones adicionales más importantes introducidas por el perfil de lectura-escritura son:

  • Hacer cumplir el uso de un JWT firmado (JWS) para encapsular los parámetros de Solicitud cuando una aplicación Cliente envía un Usuario final al Servidor de autorización para ser autenticado (el requestparámetro). Hablamos de esto en nuestra introducción de OpenID Connect. Esto es importante ya que agrega pruebas criptográficas de la identidad de la aplicación del Cliente, lo que significa que el Servidor de Autorización puede verificarla. Este es un aspecto opcional de OpenID Connect que se vuelve obligatorio con el perfil de lectura y escritura. El estándar también especifica una API REST que se puede utilizar para enviar parámetros de forma segura al servidor de autorización y luego hacer referencia a ellos mediante el request_uriparámetro.
  • Obligar a que se demuestre que las aplicaciones del Cliente son un "poseedor de la clave". Se permiten los mecanismos de autenticación basados ​​en claves (para el Cliente), a través de Mutual TLS para OAuth o un JWS acuñado a partir de una clave privada. Esto mejora la seguridad ya que el delincuente debe buscar el acceso directo a la clave privada para hacerse pasar por un Cliente válido y se aplica tanto en el servidor de autorización como en el punto final del token.
  • Aumentar el nivel de garantía de autenticación del usuario final al Nivel 3 , imponer la autenticación multifactor que, en el contexto de PSD2, significa varias cosas que el usuario sabe, posee o es parte de ellas ("Inherencia"), como un gesto biométrico.
  • Restringir los conjuntos de cifrado que se pueden usar para Mutual TLS para reducir el riesgo de una capa de transporte comprometida.

Los perfiles de solo lectura y lectura y escritura, por lo tanto, brindan protecciones adicionales generales importantes tanto para el consumidor como para el proveedor de API. El perfil JARM busca complementar esto protegiendo una de las áreas más vulnerables de OAuth, a saber, el intercambio de códigos de autorización.

Mejora de OAuth 2.0: códigos de autorización protegidos por JWT

El perfil del modo de respuesta de autorización segura de JWT ( JARM ) hace, en gran medida, lo que dice en la lata; Su objetivo es proteger los parámetros de respuesta de autorización mediante el uso de un JWT firmado y opcionalmente cifrado. En este modo, la aplicación Cliente solicita un código de autorización seguro, y el Servidor de Autorización proporciona la respuesta firmada con una clave privada de su propiedad. La aplicación Cliente tiene acceso al certificado público correspondiente a esta clave para poder verificar la firma (si el JWT está firmado y encriptado, el Cliente requerirá acceso tanto a los certificados públicos de firma como a los de encriptación).

La firma y el cifrado opcional del código de autorización brindan protecciones adicionales para el Cliente contra ataques de estilo de reproducción de código en una implementación de solo OAuth, similar a los beneficios del parámetro Solicitud en el perfil de lectura / escritura. Podría decirse que es el estándar menos omnipresente dentro de la suite, con la autenticación de canal secundario iniciada por el cliente abriendo el camino más nuevo.

Autenticación de desacoplamiento: Autenticación de canal secundario iniciada por el cliente

La autenticación de canal secundario iniciada por el cliente (CIBA) es el último, y posiblemente el más complejo, de los perfiles FAPI. Intenta abordar dos de los principales puntos conflictivos en el ecosistema de banca abierta en este momento, a saber:

  • Para permitir que un usuario se autentique y autorice una operación en un dispositivo diferente al que está usando . Por ejemplo, si un usuario final está utilizando una aplicación de escritorio pero solo puede autenticarse a través de un biométrico almacenado en un dispositivo móvil, que está vinculado al sistema operativo móvil (en lugar de un estándar abierto como Webauthn ).
  • Permitir que múltiples seres humanos reales autoricen el intercambio de datos o el inicio del pago . Esto es importante ya que la mayoría de las implementaciones de banca corporativa por Internet adoptan un enfoque "x-eyes" para autorizar operaciones sensibles, con flujos de trabajo asociados, colas y notificaciones para los participantes involucrados.

Ambas necesidades están en desacuerdo con la mayoría de las implementaciones de Open Banking. La mayoría de los procesos esperan redirigir a un solo usuario para que realice los actos de autenticación y autorización, ya sea dentro del navegador o mediante una URL reclamada a una aplicación de banca móvil. Algunas normas han abordado vagamente algunos aspectos de esto; por ejemplo, los estándares del Reino Unido exponen una propiedad de “Autorización múltiple” en su recurso de Consentimiento. Sin embargo, el flujo de trabajo de autorización en este escenario es una faceta de los estándares de API en lugar del protocolo de seguridad, que parece algo ortogonal y se basa en que el cliente sondea una API para descubrir cambios en el estado de autorización.

CIBA proporciona la flexibilidad para abordar estas necesidades con elegancia. En lugar de esperar una respuesta sincrónica o semisincrónica, CIBA anticipa un flujo de trabajo completamente asincrónico:

  • La aplicación Cliente realiza una solicitud de autenticación al servidor de autorización, utilizando una pista para indicar el usuario que le gustaría autenticar. La pista se proporciona a través del conocimiento conocido por ambas partes: una dirección de correo electrónico, un identificador compartido o pruebas de autenticación ofrecidas previamente, como un token de identificación.
  • Si la solicitud de autenticación es exitosa, el servidor de autorización inicia los flujos de trabajo de backend, ya sea directamente o mediante otros componentes, para pedir a uno o más usuarios finales que se autentiquen y autoricen la solicitud, a través de cualquier medio (móvil, escritorio, etc.) que requiera. su infraestructura de aplicación interna.
  • Cuando todos los Usuarios finales requeridos han completado la autenticación y autorización, el Servidor de autorización llama a la aplicación Cliente en un webhook conocido para indicar que la autorización está completa.
  • La aplicación del Cliente puede visitar el punto final de Token para recuperar un nuevo token que les permita acceder a un recurso protegido.

El flujo de trabajo para la autenticación de canal secundario iniciada por el cliente (CIBA), el último perfil de FAPI.

Hay permutaciones en este flujo. Por ejemplo, la aplicación Cliente puede sondear el servidor de autorización si no se pueden hacer webhooks disponibles. Pero, la especificación puede ofrecer a las Partes que Confían un medio completamente desacoplado para solicitar la autenticación y autorización del usuario. Esto aumenta enormemente la usabilidad y brinda a los Clientes muchas opciones diferentes sobre cómo diseñar su experiencia de usuario sin que la redirección sea un requisito fundamental.

Pensamientos finales

La prevalencia de la FAPI es, por supuesto, tan buena como su adopción. Habrá un desfase entre la disponibilidad de los Borradores de Implementadores y su inclusión en el soporte de soluciones de proveedores y de código abierto. Es de esperar que la adopción continúe aumentando ya que el conjunto de estándares solo puede servir para proporcionar una implementación más segura en los ecosistemas de Open Banking.

Los desarrolladores no pueden ver la seguridad como una noción estática que, una vez tratada, puede simplemente marcarse como "Hecho" y olvidarse. Los ecosistemas de Open Banking seguirán evolucionando, especialmente a medida que pasamos de las API centradas exclusivamente en la banca a los dominios de Open Finance. Como tal, la forma en que definimos y aplicamos los protocolos de seguridad adecuados también debe evolucionar. Esto es especialmente cierto cuando consideramos el papel de la identidad digital y su relación con la pila de OpenID Connect. La unión de la identidad y los ecosistemas de “abrir todo” significa que los perfiles de seguridad como FAPI solo se volverán más críticos.

Publicar un comentario

0 Comentarios