Herramientas de usuario
app:turboresumen
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| app:turboresumen [2025/07/14 12:39] – thejuanvisu | app:turboresumen [2025/07/14 14:48] (actual) – [4.1.3 OAuth] thejuanvisu | ||
|---|---|---|---|
| Línea 708: | Línea 708: | ||
| * Validar que al usuario se le permite la acción | * 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: | ||
| + | * Públicos: Los puede definir cualquiera aunque se pueden | ||
| + | * 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, | ||
| + | * El formato de los tokens cifrados consta de 5 partes separadas por " | ||
| + | |||
| + | ==== 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: | ||
| + | * 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: | ||
| + | * redirect_uri: | ||
| + | * 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, | ||
| + | * Puede ser autocodificado, | ||
| + | * 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, | ||
| + | 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, | ||
| + | * ü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, | ||
| + | |||
| + | |||
| + | ==== 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, | ||
| + | |||
| + | ==== 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/ | ||
| + | * 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. | ||
app/turboresumen.1752496749.txt.gz · Última modificación: 2025/07/14 12:39 por thejuanvisu
Herramientas de la página
