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 13:38] – thejuanvisu | app:turboresumen [2025/07/14 14:48] (actual) – [4.1.3 OAuth] thejuanvisu | ||
|---|---|---|---|
| Línea 734: | Línea 734: | ||
| ==== 4.1.3 OAuth ==== | ==== 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 ==== | ==== 4.1.4 OpenID Connect ==== | ||
| Línea 770: | Línea 857: | ||
| * 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. | * 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, | * 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.1752500311.txt.gz · Última modificación: 2025/07/14 13:38 por thejuanvisu
Herramientas de la página
