curso de criptografia!!!
Introducción a OAuth 2.0 y OIDC
Implementación de OAuth y OpenID Connect en Aplicaciones Web
¿Qué es la autenticación?
Autorización en Aplicaciones Web: Roles y Permisos
Alternativas a Open Authorization y OpenID Connect
Protección de Endpoints con Autenticación Básica y Bearer Tokens
Flujo de Autenticación con Open Authorization y Open ID
JSON Web Tokens
Firmado y verificación de JSON Web Tokens
Comparación: Sesiones vs. JSON Web Tokens en SPA y REST API
Firmado de JSON Web Tokens con Node.js
Verificación de JSON Web Tokens en Node.js
Quiz: JSON Web Tokens
Open Authorization 2.0
Flujos de OAuth 2.0: Implementación y Seguridad
Flujos de Autorización en OAuth 2.0: Tipos y Funcionamiento
Selección de Flujos en OAuth 2.0: Guía Práctica
Implementación de Authorization Code Flow en Spotify
Implementación de PKCE en API de Twitter paso a paso
Implementación de Implicit Flow con Twitch en React
Implementación de Client Credentials Flow en Discord bots
Implementación de Resource Owner Password Flow con Auth0
Quiz: Open Authorization 2.0
Open ID Connect
Implementación de OpenID Connect para Autenticación Segura
Implementación de flujo Implícito con Conform Post usando Auth0
Flujo Híbrido: Autenticación con ID y Access Tokens
Quiz: Open ID Connect
OAuth y OIDC en producción
Buenas prácticas de JSON Web Tokens (JWT) en aplicaciones web
Implementación de OAuth: Mejores Prácticas y Consideraciones
Autenticación en Next.js usando NextAuth y OAuth con GitHub
Cómo implementar Oauth2 y OpenID Connect en producción
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Flujos de Autorización en OAuth 2.0: Tipos y Funcionamiento
12/25Recursos
¿Cuáles son los flujos en Open Authorization 2.0?
Open Authorization 2.0, conocido como OAuth 2.0, es fundamental para garantizar la seguridad al gestionar los accesos a recursos en aplicaciones modernas. Este sistema emplea diversos flujos, cada uno adaptado a distintas tecnologías y necesidades de implementación. Entender estos flujos es vital para cualquier desarrollador que trabaje con aplicaciones web o móviles que requieran acceso a APIs de terceros.
¿Qué roles participan en los flujos de OAuth 2.0?
Antes de profundizar en los flujos, es esencial identificar los roles involucrados en OAuth 2.0:
- Cliente: Es la aplicación que requiere acceso a los datos del usuario.
- Authorization Server: API que emite el token de acceso.
- Resource Owner: El usuario que concede el acceso.
- Resource Server: API que aloja los recursos protegidos.
Generalmente, el Authorization Server y el Resource Server pueden ser la misma entidad, lo que facilita el proceso de autorización y acceso.
¿Cómo funciona el Authorization Code Flow?
El Authorization Code Flow es el flujo más común y seguro. El proceso es como sigue:
- Usuario conecta a través de una aplicación, por ejemplo, "Conectar con Google."
- Solicitud de Autorización: El cliente envía una solicitud al Authorization Server con el Client ID y otros parámetros.
- Pantalla de Consentimiento: Si el usuario autoriza, se emite un Authorization Grant.
- Intercambio de Código: El cliente usa el Authorization Grant para solicitar un Access Token, utilizando el Client ID y el Client Secret.
- Acceso a Recursos: Con el Access Token, el cliente accede al Resource Server.
¿Qué es el Authorization Code Flow con Proof-Key for Code Exchange?
Este flujo es similar al anterior, pero agrega una capa de seguridad adicional mediante el Code Verifier y Code Challenge. Es ideal para aplicaciones que no pueden almacenar secretos de manera segura, como las aplicaciones de una sola página (SPA):
- Proceso de Hashing: Se aplica un algoritmo al Code Verifier para crear el Code Challenge.
- Verificación: El Authorization Server verifica que el Code Verifier coincida con el Code Challenge, garantizando que el cliente no ha sido interceptado.
¿Por qué no se recomienda el Implicit Flow?
El Implicit Flow es menos seguro que los demás, ya que:
- No hay intercambio de código: El Access Token se envía inmediatamente tras la autorización del usuario.
- Riesgo de seguridad: El token se envía en el fragmento de la URL, aumentando el riesgo si el cliente tiene fallos de seguridad.
¿Cuáles son las características del Client Credentials Flow?
Este flujo no involucra a un usuario. Es útil cuando el cliente es el Resource Owner:
- Autenticación del Cliente: El cliente utiliza el Client ID y Client Secret para obtener un Access Token directamente del Authorization Server.
- Uso del Token: Se utiliza para acceder al Resource Server.
¿Cómo funciona el Resource Owner Password Flow?
Este flujo es adecuado para aplicaciones legacy que no soportan redirecciones:
- Autenticación del Usuario: El usuario ingresa directamente su username y contraseña.
- Acceso Suficiente: Utiliza HTTPS para asegurar que las credenciales no sean interceptadas.
¿Cuál es el flujo adecuado para tu aplicación?
La elección del flujo depende de varios factores como el tipo de aplicación y el nivel de seguridad requerido. Aquí van algunas recomendaciones:
- Authorization Code Flow: Para aplicaciones que pueden manejar secretos de cliente de forma segura, comúnmente en servicios web.
- Proof-Key for Code Exchange Flow: Ideal para aplicaciones que no pueden almacenar secretos, como las SPA.
- Client Credentials Flow: Cuando la aplicación actúa por sí misma sin la interacción directa del usuario.
- Resource Owner Password Flow: Solo para aplicaciones internas o de confianza donde se puede asegurar la seguridad del canal.
Cada flujo tiene sus propias ventajas y desventajas, y es crucial analizar qué flujo es adecuado para las necesidades específicas de la aplicación y la infraestructura de seguridad existente.
Aportes 8
Preguntas 2
Ordenar por:
Un ejemplo practico seria cuando una empresa ofrece beneficios por ejemplo el ingreso a un gimnasio por convenio, entonces el resource owner podriamos ser nosotros, el client prodria ser el gimnasio, el authorization server podrian ser las personas que se encargan del ingreso de personas al gimnasio que estan en recepcion, y a estas personas se les muestra el carnet de la empresa que se podria ver como el token de acceso para que validen el convenio, y el resource server serian las maquinas que se encuentran en el gym
OAuth 2.0 es como un sistema de seguridad en un edificio de oficinas compartido. Aquí va la analogía para entender los roles y flujos:
1. **Cliente (Client):** Imagina que eres un trabajador que necesita acceder a una sala de conferencias en el edificio, pero no tienes una llave directa. En lugar de eso, pides una autorización temporal en la recepción.
2. **Propietario de los recursos (Resource Owner):** El propietario de los recursos es como el jefe de seguridad del edificio, que decide quién puede tener acceso a qué partes del edificio. Este jefe de seguridad puede ser tú mismo (si se trata de tu propia información) o alguien más (si estás accediendo a los datos de otra persona).
3. **Servidor de autorización (Authorization Server):** Este es como la recepción del edificio, donde presentas tu identificación (credenciales) y pides acceso a la sala de conferencias. La recepción verifica tu identidad y, si todo está en orden, te da un pase temporal (token) que te permite entrar.
4. **Servidor de recursos (Resource Server):** Finalmente, está la sala de conferencias en sí, que tiene un guardia en la puerta. Este guardia verifica tu pase temporal. Si es válido, te deja entrar a la sala; si no, te rechaza.
### Flujos de OAuth 2.0
1. **Autorización del código de autorización (Authorization Code Flow):** En este flujo, primero vas a la recepción (Servidor de Autorización) y le pides el pase temporal (token). La recepción verifica tu identidad y te da un pase temporal en forma de un código. Luego, llevas ese código de vuelta a la recepción, que finalmente te da un pase completo que te permite entrar a la sala de conferencias (acceso a recursos).
2. **Flujo de credenciales de recursos (Resource Owner Password Credentials Flow):** Aquí, es como si fueras a la recepción, les dieras tu identificación (nombre de usuario y contraseña) directamente, y obtuvieras un pase temporal para acceder a la sala. Este flujo es más rápido pero también menos seguro porque estás compartiendo tu identificación directamente.
3. **Flujo de credenciales del cliente (Client Credentials Flow):** Este flujo es como si fueras un miembro permanente del edificio (por ejemplo, una empresa en el mismo edificio) y tu empresa ya tiene un acuerdo con la seguridad. Simplemente presentas una identificación especial y obtienes acceso directo, sin necesitar una autorización adicional.
4. **Flujo de token implícito (Implicit Flow):** En este caso, obtienes el pase temporal (token) directamente al pedirlo en la recepción, sin pasar por el paso intermedio de obtener un código. Es más rápido, pero menos seguro, ya que el pase se entrega de inmediato y podría ser interceptado.
En el flujo "Authorization Code Flow with Proof-Key for Code Exchange", el `Code Challenge` y el `Code Challenge Method` se envían al Authorization Server en la primera solicitud de autorización, junto con otros parámetros como el `Client ID` y los `Scopes`. El `Code Challenge` es el resultado del `Code Verifier` aplicado a un algoritmo de hashing, y permite al servidor verificar la autenticidad del cliente en la segunda etapa del flujo.
curso de criptografia, se necesita
Nuevamente, curso de criptografía, venga!!
Hagan el curso de la criptografía por favor
Saludos a todos, alguien puede responderme estas preguntas:
1.- Cuando se usa PKCE, igual la aplicación cliente debería guardar el code\_verifier, caso contrario tendría que solicitar el consentimiento del usuario cada que se accese a la aplicacion?
2.- Si es así, este enfoque no funcionaría muy bien en SPA, porque como se guarda de forma segura un secreto en una SPA (Sin hacer uso de un servidor backend).
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?