¿Cuáles son las diferencias entre clientes públicos y confidenciales?

Al usar Logto para crear una aplicación, notarás que hay varios tipos de aplicaciones diferentes para elegir, incluidas las Aplicaciones de Una Sola Página (SPA), las Aplicaciones Nativas y las Aplicaciones Web Tradicionales. Intuitivamente, por el nombre, queda claro que una aplicación nativa se ejecuta en sistemas operativos que se encuentran comúnmente en dispositivos como teléfonos. Sin embargo, ¿qué son exactamente una SPA y una aplicación web tradicional? ¿Por qué necesitamos distinguir entre estos diferentes tipos de aplicaciones? Este artículo revelará las respuestas a estas preguntas.

Antes de comenzar, necesitamos proporcionar una breve introducción a algunos conceptos.

¿Qué es OAuth?#

OAuth es un estándar abierto para la delegación de acceso, que generalmente se utiliza como una forma para que los usuarios de internet otorguen a sitios web o aplicaciones acceso a su información en otros sitios web sin proporcionar sus contraseñas.

En la última década, se ha convertido gradualmente en el proceso de autorización estándar y ha sido ampliamente aceptado por la mayoría de las compañías como Google, Meta, Microsoft, etc. La versión actualmente utilizada es OAuth 2.0.

En el contexto de OAuth, la aplicación que mencionamos anteriormente se refiere como Cliente. Ellos pueden hacer solicitudes para recursos protegidos, siempre que hayan obtenido la autorización del propietario del recurso (generalmente los usuarios finales).

Clientes públicos y clientes confidenciales#

OAuth define dos tipos de clientes, según su capacidad para mantener la confidencialidad de las credenciales del cliente.

Cliente confidencial#

Un cliente que es capaz de mantener la confidencialidad de sus credenciales (por ejemplo, un cliente implementado en un servidor seguro con acceso restringido a las credenciales del cliente) o uno que es capaz de autenticación segura del cliente a través de otros medios.

Cliente público#

Un cliente que no puede mantener la confidencialidad de sus credenciales (por ejemplo, un cliente que se ejecuta en el dispositivo del propietario del recurso, como una aplicación nativa o una aplicación web basada) y tampoco puede autenticarse de manera segura como cliente a través de otros medios.

SPA, aplicación nativa y aplicación web tradicional#

Con los conocimientos de fondo mencionados, echemos un vistazo a lo que significan una SPA, Aplicación Nativa y aplicación web tradicional en el contexto de Logto, así como si se consideran clientes públicos o clientes confidenciales.

SPA#

El código del lado del cliente de una SPA se descarga de un servidor web y se ejecuta en el agente de usuario (como un navegador web) del propietario del recurso en su dispositivo. Los datos del protocolo y las credenciales son fácilmente accesibles (y a menudo visibles) para el propietario del recurso.

Aplicación nativa#

Una aplicación nativa se instala y ejecuta en el dispositivo del propietario del recurso. Los datos del protocolo y las credenciales son accesibles para el propietario del recurso. Se asume generalmente que cualquier credencial de autenticación del cliente contenida dentro de la aplicación puede ser extraída.

Aplicación web tradicional#

Una aplicación web tradicional es un cliente que se ejecuta en un servidor web. El propietario del recurso accede al cliente a través de una interfaz de usuario HTML presentada en el agente de usuario en su dispositivo. Las credenciales del cliente, así como cualquier token de acceso emitido al cliente, se almacenan en el servidor web y no están expuestas ni accesibles para el propietario del recurso.

Entonces, podemos ver claramente que SPA y aplicación nativa son clientes públicos, mientras que la aplicación web tradicional es un cliente confidencial.

Puedes encontrar que al crear una SPA o una aplicación nativa en Logto, no hay Secreto de la Aplicación, mientras que una aplicación web tradicional tiene tanto un ID de Aplicación como un Secreto de la Aplicación. Esto se debe a que el secreto de un cliente público no puede garantizarse que sea seguro.

¿Cómo funciona un cliente en el flujo de autorización de OAuth?#

Al desarrollar aplicaciones OAuth, el primer paso es registrar el cliente con el proveedor de servicios OAuth. El registro del cliente implica proporcionar detalles sobre la aplicación, como su nombre y URI de Redireccionamiento. Luego, el proveedor de servicios OAuth genera un ID de cliente y un secreto de cliente, que se consideran las credenciales de la aplicación.

El ID de cliente se considera información pública y se comparte con el usuario durante el proceso de OAuth. Generalmente se incluye en la URL de autorización y es visible para los usuarios finales.

Por otro lado, el secreto de cliente sirve como la contraseña de la aplicación y debe mantenerse en secreto. Se utiliza en el proceso de OAuth para intercambiar el código de autorización (asumiendo que es un flujo de código de autorización) para obtener el token de acceso. La existencia de secretos de cliente asegura que solo las aplicaciones registradas puedan completar el intercambio de tokens de acceso.

Introducción de la Clave de Prueba para el Intercambio de Códigos (PKCE)#

Como se mencionó anteriormente, los secretos de cliente de los clientes públicos no pueden garantizarse que sean seguros, y los atacantes pueden obtener credenciales de cliente e hacerse pasar por clientes para acceder a recursos protegidos, lo cual es inaceptable en cualquier situación.

PKCE (Clave de Prueba para el Intercambio de Códigos) resuelve este problema generando temporalmente un verificador de código al principio de cada flujo de autorización, que se almacena localmente y se usa para generar un desafío de código que se envía al servidor de autorización. El verificador de código se envía nuevamente al servidor de autorización al intercambiar el token de acceso. El servidor de autorización verifica que el verificador de código y el desafío de código coincidan, lo que asegura que el cliente público no haya sido suplantado.

El verificador de código en PKCE en realidad funciona como un secreto de cliente dinámico. Su seguridad se garantiza por la irreversibilidad del algoritmo de hash.

Resumen#

En este artículo, discutimos los conceptos de clientes confidenciales y clientes públicos en OAuth. Aprendimos que los clientes confidenciales tienen la capacidad de mantener secretos y almacenar de forma segura información sensible, mientras que los clientes públicos carecen de esta capacidad. Examinamos ejemplos de los dos tipos de clientes, incluidas las aplicaciones web tradicionales, SPA y aplicaciones nativas, en el contexto de las prácticas de productos de Logto.

También discutimos el proceso de registro de clientes en OAuth y los roles de ID de cliente y secreto de cliente.

Además, encontramos que los clientes públicos enfrentan limitaciones al almacenar de forma segura secretos de cliente. Para superar esta limitación, presentamos PKCE (Clave de Prueba para el Intercambio de Códigos), una extensión de OAuth que permite a los clientes públicos intercambiar de forma segura códigos de autorización sin la necesidad de un secreto de cliente.

Nuestro producto, Logto, es una solución integral de CIAM que sigue las mejores prácticas de los protocolos OAuth y OIDC para garantizar la seguridad en cada etapa, incluida la adopción del uso de PKCE para proteger la seguridad de los clientes públicos.