FAPI 2.0 o OAuth básico: ¿qué perfil de seguridad nombra realmente la solicitud de API del banco?
Compare la afirmación del protocolo, la propiedad de seguridad y la evidencia de conformidad antes de determinar el alcance de una solicitud de API bancaria que diga solo OAuth o FAPI 2.0.
Señales que conviene observar
- La parte de confianza menciona el perfil exacto de FAPI u OAuth y la función de implementación en lugar de decir solo compatible con OAuth.
- El servidor de autorización y el cliente acuerdan PAR, PKCE y el método de token restringido por el remitente.
- Un resultado de conformidad o una prueba a nivel de punto final está vinculado al entorno y al propietario de la versión.
“Cumple con OAuth” y “Se requiere FAPI 2.0” no son dos etiquetas intercambiables para la misma API bancaria. OAuth 2.0 proporciona un marco de autorización; el perfil de seguridad FAPI 2.0 selecciona y refuerza los mecanismos relacionados con OAuth para API de alto valor, incluidas solicitudes de autorización push autenticadas, PKCE y tokens de acceso restringido por remitente. El proyecto debe nombrar el perfil exacto y la evidencia, no solo demostrar que un punto final de token responde.
Esta distinción es importante para un ingeniero de ventas de identidades de API financiera que revisa los grupos autorizados de banca abierta, desarrollador bancario y de identidad Telegram. Una respuesta con un día de retraso puede perder un espacio de certificación o una versión de integración. Una cotización comercial basada en la palabra “OAuth” también puede omitir los cambios de servidor de autorización, cliente y servidor de recursos que espera la parte que confía.
Aquí hay un intercambio compuesto ilustrativo, no una solicitud bancaria ni el resultado de una prueba:
“El inicio de sesión en Sandbox funciona con OAuth. El socio dice que la producción debe ser FAPI 2.0. ¿Simplemente cambiamos los alcances?”
El intercambio omite la función de API, el servidor de autorización, el tipo de cliente, la versión del perfil, el flujo actual, la autenticación del cliente, el método de vinculación de tokens, el conjunto de conformidad, la prueba fallida y el propietario de producción.
La comparación es marco versus perfil restringido, no marca antigua versus nueva.
RFC 6749 define funciones de OAuth 2.0 y concesiones de autorización. Intencionalmente deja muchas opciones a las implementaciones. Decir “usamos OAuth” puede describir un flujo de código de autorización legítimo sin identificar las propiedades de seguridad requeridas por un ecosistema de alto valor.
El Perfil de seguridad FAPI 2.0 de OpenID Foundation se basa en OAuth y estándares relacionados. Su introducción dice que cubre a los clientes que obtienen tokens restringidos por remitente y los utilizan con servidores de recursos, y que fue diseñado para interfaces de programación de aplicaciones (API) de alto valor. Un banco o un ecosistema de banca abierta pueden agregar reglas adicionales; “FAPI 2.0” todavía necesita un documento, una versión y un perfil local exactos.
| Pregunta de evidencia | La reclamación básica de OAuth puede establecer | El perfil de seguridad FAPI 2.0 espera |
|---|---|---|
| Solicitud de autorización | Un flujo de autorización de OAuth compatible | Flujo de código de autorización con solicitudes de autorización enviadas (PAR) autenticadas por el cliente |
| Defensa de interceptación de código | Elección de OAuth dependiente de la implementación | Clave de prueba para intercambio de códigos (PKCE) con el método de desafío S256 |
| Robo de tokens de acceso | Se puede utilizar el manejo de tokens al portador | Tokens restringidos por el remitente que utilizan TLS mutuo o prueba de posesión (DPoP) |
| Autenticación de cliente | Depende del cliente y la implementación. | Clientes confidenciales y opciones de autenticación especificadas |
| Evidencia | Una prueba de integración o endpoint exitosa | Comportamiento específico del perfil más la evidencia de conformidad requerida por el ecosistema |
| La tabla no dice que OAuth de referencia sea “inseguro”. Dice que una afirmación genérica sobre OAuth no puede demostrar un perfil más limitado. |
La evidencia del perfil también es específica del rol. Una prueba de cliente no puede establecer el comportamiento completo del servidor de autorización, y un seguimiento del servidor de autorización no puede probar que el servidor de recursos rechaza un token robado que carece de la clave o el certificado requerido. Registre el cliente, el servidor de autorización y el servidor de recursos por separado, incluso cuando un proveedor opere más de una función.
Siga una solicitud de autorización a través de cuatro puntos de control
La prueba de brecha útil más corta sigue una sola solicitud en lugar de comparar listas de características de productos.
Punto de control 1: envío de la solicitud
El servidor de autorización FAPI 2.0 debe admitir Solicitudes de autorización enviadas según RFC 9126 autenticado por el cliente y rechazar las solicitudes de autorización enviadas sin PAR. El cliente envía los parámetros de autorización a través del canal trasero autenticado y luego utiliza el request_uri devuelto en el punto final de autorización.
Punto de control 2: código de autorización
El perfil requiere PKCE con S256. También establece una duración máxima del código de autorización de 60 segundos. Una redirección de zona de pruebas que devuelve un código no muestra que se haya aplicado ninguna de las reglas.
Punto de control 3: cliente y token de acceso
El servidor de autorización emite solo tokens de acceso restringidos por el remitente y utiliza seguridad de capa de transporte mutua según RFC 8705 o DPoP bajo RFC 9449. La autenticación del cliente y la vinculación de tokens son cuestiones diferentes: por ejemplo, el perfil enumera TLS mutuo o private_key_jwt para la autenticación del cliente, mientras que la restricción del remitente del token usa TLS o DPoP mutuo.
Punto de control 4: solicitud de recursos y pruebas
El servidor de recursos debe validar el token y su restricción de remitente mediante el método elegido. Luego, el equipo necesita el objeto de evidencia que el socio acepta: un resultado del conjunto de conformidad, rastreo de punto final, registro de certificación o prueba específica del ecosistema. No llame certificación a una prueba de humo local.
El flujo de trabajo de alternativa a la clave de acceso (English) aborda la recuperación de autenticación, no la autorización de API. El artículo sobre evidencia de incorporación de SOC 2 muestra cómo mantener una solicitud de seguridad vinculada al registro exacto aceptado.
Defina el alcance de la migración según el primer punto de control que falle
Si PAR está ausente, el proyecto puede requerir metadatos del servidor de autorización, punto final PAR, autenticación del cliente y cambios en la solicitud del cliente. Si PKCE está presente pero los tokens de acceso son solo portadores, el trabajo principal puede ser el ciclo de vida de la clave o del certificado y la validación del servidor de recursos. Si todo el comportamiento en tiempo de ejecución pasa pero el socio rechaza la evidencia, el proyecto puede ser un paquete de prueba y conformidad en lugar de un rediseño del protocolo.
TOP Prospect puede combinar fragmentos incompletos de grupos Telegram a los que el usuario se conecta deliberadamente y está autorizado a acceder, preservar el texto original, la fuente y la hora, eliminar duplicados obvios y clasificar a un candidato para revisión humana. No puede inspeccionar puntos finales, conservar claves de clientes, ejecutar el conjunto de conformidad de un banco, certificar FAPI o elegir el perfil del ecosistema. La página de precios describe el límite de descubrimiento. La guía de desarrollo comercial de pagos cubre la demanda comercial en lugar de la evidencia del protocolo.
Regrese al intercambio de sandbox. “Cambiar los alcances” es plausible sólo después de que los puntos de control de solicitud, código, token y servidor de recursos ya cumplan con el perfil de producción nombrado. Si uno falla, analice ese objeto y su propietario. La comparación útil no es OAuth versus FAPI como productos rivales; es la evidencia del punto final actual versus las propiedades de seguridad que la parte que confía realmente requiere.
Preguntas frecuentes
¿FAPI 2.0 es un reemplazo de OAuth 2.0?
No. Se basa en OAuth 2.0 y estándares relacionados, al tiempo que reduce las opciones y agrega requisitos para API de alto valor.
¿Un token de acceso de OAuth demuestra la conformidad con FAPI 2.0?
No. No prueba PAR, PKCE con S256, tokens restringidos por remitente, verificación de emisor u otro comportamiento de perfil.
¿FAPI 2.0 debe utilizar TLS mutuo en lugar de DPoP?
No. El perfil permite restricciones del remitente con TLS o DPoP mutuo, sujeto a sus requisitos detallados.
¿Qué hace que la solicitud esté lista para una propuesta de implementación?
Nombra los roles, la versión del perfil, el método de restricción del remitente, la evidencia, el entorno, la prueba fallida y el propietario de la versión.
Preguntas frecuentes
¿FAPI 2.0 es un reemplazo de OAuth 2.0?
No. El perfil de seguridad FAPI 2.0 se basa en OAuth 2.0 y estándares relacionados, lo que reduce las opciones y agrega requisitos para escenarios de API de alto valor.
¿Un token de acceso de OAuth demuestra la conformidad con FAPI 2.0?
No. Una respuesta de token exitosa no prueba las solicitudes de autorización enviadas autenticadas por el cliente, PKCE con S256, tokens restringidos por el remitente, verificación del emisor o el resto del perfil seleccionado.
¿FAPI 2.0 debe utilizar TLS mutuo en lugar de DPoP?
No. El perfil de seguridad permite tokens de acceso restringidos por el remitente mediante TLS mutuo según RFC 8705 o demostración de prueba de posesión según RFC 9449, sujeto a los requisitos específicos de su servidor y cliente.
¿Qué hace que la solicitud esté lista para una propuesta de implementación?
Nombre la función de la API, el servidor de autorización, el tipo de cliente, el perfil y la versión exactos, el método de restricción del remitente, la evidencia de conformidad requerida, el entorno, la prueba fallida y el responsable del lanzamiento.
Fuentes y lecturas adicionales
Cómo se descubre una Signal que merece atención
La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.
