Diferencias

Muestra las diferencias entre dos versiones de la página.

--- app:turboresumen [2025/07/14 12:38] – thejuanvisu
+++ app:turboresumen [2025/07/14 14:48] (actual) – [4.1.3 OAuth] thejuanvisu
@@ Línea 694: / Línea 694: @@
 ====== Tema 4: Mecanismos de autenticación, Autorización y control de acceso ======
+{{drawio>app:Tema4DiagSec.png}}
   * **Autenticación**: Muchas de las funcionalidades que expone el servicio requieren que el usuario de la aplicación cliente se autentique.
     * una forma trivial de tratar la autenticación sería que el servicio ofreceiese un punto de acceso para que el usuario se autenticase
@@ Línea 707: / Línea 708: @@
       * Validar que al usuario se le permite la acción
+===== 4.1 Autenticación y Autorización =====
+==== 4.1.1 Autenticación en HTTP ====
+HTTP proporciona cabeceras estándar como Authorization para una petición y WWW-Autehnticate para la respuesta que pueden ser usadas para autenticación y autorización.
+  * **Basic**: Cuando el servicio recibe la petición solo tiene que decodificar la cadena que sigue a Basic para obtener el username y la password.
+    * OJO: estas peticiones se deben mandar en HTTPS.
+    * Si el usuario o la contraseña son incorrectos el servicio responde error 401 incluyendo la cabecera WWW-Authenticate
+    * El problema de este tipo de autenticación es que es ineficiente ya que hay que validar el usuario y contraseña cada vez que se hace una petición y recuperar sus roles de usuario.
+  * **Digest**: Ofrece un esquema más complejo que permite no enviar la contraseña en cada petición, aunque no es muy usado ya que también es bastante ineficiente
+==== 4.1.2 JSON Web Token (JWT) ====
+Define un formato compacto para obtener info JSON de forma segura entre dos partes.
+  * Base64URL: la cabecera y el cuerpo pueden contener caracteres no ASCII
+    * Los algoritmos de firma generan datos binarios
+    * Para que JWT se pueda enviar en protocolos que envían texto ASCII, JWT usa un sistema de codificación que permita codificar los textos binarios en ASCII
+  * Tipos de campos (Claims) en objetos JSON.
+    * Registrados: Están estandarizados pero no son obligatorios
+    * Públicos: Los puede definir cualquiera aunque se pueden  usar proveedores definidos por la IANA para garantizar la compatibilidad
+    * Privados: Los puede definir cualquiera. Los campos se pueden utilizar en contextos locales.
+  * Firma: Un JWT se puede firmar con un algoritmo de criptografía
+    * Con un algoritmo de criptografía simétrica la firma esun MAC, garantizando la integridad y Autenticidad
+    * Con un algoritmo de cirptografía simétrica es una firma digital, lo que garantiza el no repudio
+    * RFC 7515: JSON Web Signature (JSW)
+  * JWTs Cifrados: Si los datos enviados en un JWT son confidenciales, se deben cifrar con RFC 7516 (JSON Web Encription "JWE")
+    * El formato de los tokens cifrados consta de 5 partes separadas por "." y en base64url
+==== 4.1.3 OAuth ====
+Problemas que suelen encontrarse:
+  * Problema 1:
+    * Como obtener el token de acceso para un servicio de otro proveedor
+    * La aplicación necesita 2 tokens de acceso, uno para el backend y otro para el servicio
+    * Para obtener el segundo token no sería seguro que el servicio ofreciese una operación similar a la del backend de la aplicación
+      * El usuario tendría que teclear su usuario y contraseña en un proveedor de servicio externo
+      * La aplicación prodría quedarse con ele identificador y la contraseña del usuario.
+  * Problema 2:
+    * Una empresa dispone de mútiples aplicaciones y servicios corporativos.
+      * Sería necesario implementar un servicio para que las aplicaciones pudieran obtener tokens de acceso para acceder a los servicios que necesitan y una aplicación de gestión de aplicaciones cliente y tokens.
+    * Si no se hace nada especial, cada aplicación cliente tendría que implementar su propio formulario de autenticación.
+OAuth surge para dar solución al problema y en la práctica también resuelve el problema 2. En la actualidad está en su versión 2.0 que no es compatible con la 1.0 ya que usan protocolos distintos.
+  * Con el tiempo surgieron RFCs adicionales que complementan a OAuth 2.0 como PKCE, que se usa en aplicaciones web SPA y en aplicaciones nativas.
+  * Usando las herramientras adminsitrativas de la implementación de OAuth se debe registrar cada aplicación cliente
+    * Datos de entrada
+      * Info básica
+      * URL de redirección
+    * Datos de Salida
+      * client_id: identificador de la app
+      * client_secret: clave secreta de la app
+  * Cliente confidencial:
+    * Aquellos que pueden guardar de forma segura el client_secret
+  * Clientes públicos
+    * Aquellos que no pueden guardar de forma segura el client_secret
+    * Durante el registro no se genera el client_secret.
+=== 4.1.3.1 Flujos ===
+Para soportar distintos escenaros que difieren en el tipo de app cliente o si son o no del mismo proveedor Oauth contempla varios flujos, aunque nos centraremos en el Authorization Code, el más relevante.
+  * response_type: indica el tipo de flujo
+  * redirect_uri: El servidor de autorización, por seguridad, comprueba que el valor del redirect_uri corresponda con una de las url de redirección especificadas durante el registro del client_id
+  * scope: Especifica los permisos que solicita la aplicación cliente
+  * El formulario de autenticación puede permitir Single Sing On (SSO) con una cookie persistente para no tener que volver a autenticar el usuario en el server de autenticacion.
+  * code: Código de autorización que llega en la redirección y que el cliente tendrá que usar posteriormente para solicitar el token, tiempo de vida muy corto inferior a 10 min
+  * El servidor de autorización comprobará que el código de autorización no está caducado y que había sido generado para ese client_id y redirection_uri.
+  * La app guarda el token de acceso en la sesión.
+  * Si el cliente es púlico no se pasa la cabecera Authorization y se incluye el parámetro Client_id en el cuerpo.
+  * Token de Acceso (Access_token):
+    * Ristra de caracteres
+    * Token que usará la APP cliente para acceder al servicio
+    * Expira al poco tiempo
+    * La especificación no indica un formato concreto
+    * Puede ser no autocodificado, una ristra de caracteres no parseables. Puede usar el endpoint /introspect del server de autorización
+    * Puede ser autocodificado, una ristra de caracteres parseables. Puede ser verificado autónomamente.
+      * RFC 9068: Especifica un token en formato JWT
+  * Token de refresco (refresh_token):
+    * La aplicación cliente lo puede usar para solicitar un nuevo token de acceso al servidor de autorización cuando el token de acceso actual expira evitando volver a iniciar el flujo.
+      * Se puede hacer por anticipado o cuando recibe una respuesta de error indicando que el token actual caduco.
+    * Tiempo de vida largo
+    * Se emite solo a clientes confidenciales
+    * Para solicitar un nuevo token de acceso a partir de un token de refresco se usa el endpoint /token.
+  * Verificación de un token de acceso autocodificado
+    * para que el servidor de recursos pueda validar la firma, el token debería estar firmado con un algoritmo de criptografía simétrica.
+      * El server de autorización firma los tokens con clave privada
+      * Los servidores de recursos validan los tokens con clave pública.
+      * Si se usa un algoritmo de cirptografía simétrica, la unica clave tendrá que compartirse entre los servidores de autorización y de recursos.
+  * kid
+    * identifica de forma única la clave pública dentro de un JWK Set
+    * la cabecera de cada token generado por el servidor de autorización incluye el campo kid con el valor que identifica a la clave púlica que permite verificar la firma del token.
+  * El servidor de recursos puede verificar autónomamente los tokens que recibe en su petición.
+    * Recupera claves públicas del servidor de autorizacón GET /jawks y cachea el resultado
+    * Cada vez que recibe una petición
+      * recupera de caché la clave pública correspondiente al kid del token que viene en la petición
+      * Verifica la firma del token
+=== 4.1.3.2 PKCE ===
+El flujo antes descrito está sujeto a dos tipos de vulnerabilidades:
+  * Vulnerabilidad 1 CSRF:
+    * El atacante inicia el flujo
+    * Lo para cuando se devuelve la redirección con el código de autorización
+    * Obtiene un código de autorización válido.
+    * Envía a la víctima el enlace que se le devolvió de la redirección
+    * La victima que asumimos autenticada recibe el correo del atacante
+    * Hace click en el enlace del atacante
+    * La víctima sin saberlo inicial el flujo desde donde lo dejó el atacante.
+    * La aplicación web recibe el código de autorización del atacante y solicita un token de acceso que se almacena en la sesión web
+    * Las acciones que haga a partir de ahora la víctima se verán reflejadas en la cuenta del atacante.
+  * Vulnerabilidad 2:
+    * La víctima inicia el flujo y obtiene el código de autorización
+    * El atacante usando alguna vulnerabilidad consigue obtener el código de autorización de la víctima.
+    * Mientras no expire y no se haya usado dicho código existe una ventana de tiempo en la que el atacante puede obtener el token de acceso a partir del código de autorización de la víctima.
+    * Si el cliente es público el atacante puede pasar directamente al endpoint
+    * No pasa la cabecera Authorization e incluye el parámetro client_id
+    * El atacante puede usar el token de acceso para manejar la aplicación de la víctima.
+Oauth dispone del parámetro state para hacer frente a la vulnerabilidad 1 y la técnica PKCE protege contra ambas vulnerabilidades.
+  * PKCE protege contra la vulnerabilidad 1 por que en la sesión web de la víctima no hay un code_verifier.
+  * PKCE protege contra la vulnerabilidad 2 por que el atacante necesitaría el code_verifier de la víctima.
+==== 4.1.4 OpenID Connect ====
+Es un protocolo de autenticación y autorización consutrido por encima de OAuth, reutilizando los flujos, tokens de acceso y refresco, endpoints Authorization, troken, introspection... Lo que sería todo.
+OIDC añade las siguientes novedades:
+  * Nuevo tipo de token (id_token)
+    * Es un token en formato JWT que contiene info del usuario
+    * En el flujo de codigo de autorización, la respuesta al POST sobre el endpoint TOKEN incluye el id_token
+    * ütil cuando la aplicación del cliente quiere obtener inmediatamente info  sobre el usuario a la vez que recibe el token de acceso.
+  * Estandarización de la información acerca de un usuario
+  * Un flujo adicional
+  * Más endpoints.
+OIDC tiene los siguientes claims y scopes:
+  * Estandariza la ifnormación que se deuvelve sobre un user dentor del id_token, modelándose como claims JWT
+  * Independientemente del flujo utilizado, id_token puede contener claims standar:
+    * iss: identificador de autoridad que expide el token
+    * sub: id del usuario
+    * aud: valor del parámetro client_id
+    * exp: fecha en segundos en la que expira el token
+    * iat: fecha en segundos en la que se generó el token.
+  * La petición de autenticación o autorización en los flujos OAUT incluye el parámetro scaope, OIDC estandariza una serie de valores para el scope que conllevan la aparición de otros claims estándares en el id_token. Siempre debe contener al menos el valor openid.
+OIDC se diferencia de OAuth en que, además de ser un protocolo de autorización, también es un protocolo de autenticación.
+==== 4.1.5 SAML ====
+Security Assertion Markup Languaje es un protocolo de autenticación y autorización estandarizado por OASIS. OIDC es un rediseño conceptual de SAML en base a principios REST y JSON. La mayor parte  de los IdPs proprocionan una implementación de SAML además de OAuth/OIDC.
+  * Contempla varios escenarios de uso llamados perfiles
+  * Suele ir muy ligado al suo de Active directory y LDAP, por lo que suele usarse solo en entornos corporativos.
+  * SAML no es apto para SSO en aplicaciones nativas, aunque existen soluciones comerciales que lo permiten.
+==== 4.1.6 Kerberos y SPNEGO ====
+  * Kerberos es un protocolo de autenticación y autorización bastante complejo basado en criptografía simétrica para establecer conexión entre cliente y servidor. esta pensado para cominicación entre cliente pesado y servicio dentro de la red corporativa de una empresa.
+    * Una vez autenticado el usuario, las aplicaciones que arrancan pueden solicitar tickets (tokens) para los servicios que usan y en los que el usuario esté autorizado sin que el usuario tenga que introducir el nombre y la contraseña en cada aplicación.
+  * SPNEGO: para poder hacer uso de kerberos en aplicaciones web se unsa SPNEGO (Simple and Protected GSSAPI NEGOTIATION MECHANISM), un protocolo para que un cliente y un servicio negocien el uso de un esquema de seguridad para que ambos soporten RFC4178.
+    * Uno de los usos más habiituales de SPNEGO es el esquema negotiate de HTTP Authorization y WWW-Authenticate, que se usa par aautenticar el navegador con una aplicación web, usando kerberos como esquema de autenticación y autorización.
+==== 4.3 Control de acceso ====
+=== 4.3.1 Basado en Roles ===
+  * **Modelo RBAC (Role Based Access Control)**: Se basa en restringir la ejecución de unas operaciones de un servicio a un usuario que tenga uno o varios roles.
+    * El cliente envía una petición en nombre de un usuario e incluye con la petición algún tipo de token
+    * El servicio a recibir la petición tiene que validar el token y a partir de este averiguar los rles de usuario y comprobar si tiene los permisos necesarios para ejecutar la operación solicitada
+=== 4.3.2 Basado en Atributos ===
+Modelo ABAC (Attribute Based Access Control) hace frente a las limitaciones del modelo RBAC.
+  * Se proteje de la ejecución de una operación o acción con una política que permite o deniega en función de los atributos del sujeto que solicita la operación, el recurso sobre el que se realiza la operación y el entorno.
+    * Atributo: Par nombre/valor
+    * Sujeto: quien invoca la operación, un usuario u otro tipo de entidad
+    * Recurso: Objeto sobre el que se realiza la operación, atributos del propio recuros
+    * Entorno: Atributos como el día/hora, ubicación, dispositivo desde el que se accede...
+    * Política: Conjunto de reglas que determinan si se permite la ejecución de una operación en función de los atributos del sujeto, recursos y entorno.
+      * Se define declarativamente.
+    * ABAC busca que las principales políticas de control de acceso no estén cableadas en las aplicaciones y servicios, de forma que si se deciden variar no es necesario actualizar las aplicaciones. Las políticas las pueden editar personas diferentes a los desarrolladores.
+XACML (eXtensible Access Control Markup Languaje) es un estándar de OASIS que define un leguanje XML para la definición de políticas, una arquitectura de control de acceso y el formato de las peticiones /respuestas del PEP al PDP.

Knoppia

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página