API Authentication
Auth0 Actors:
es en realidad de delegar acceso AUTH0, no de dar autenticación, mucho OJO.
Quiz:
OAuth 2.0 Interaction patterns
1. Authorization Code Flow (Code Flow)
Uso común: Aplicaciones web o móviles donde el usuario inicia sesión.
🧩 Resumen:
El usuario se autentica en el authorization server.
Se genera un authorization code.
La app (cliente) intercambia ese código por un access token (y a veces un refresh token).
✅ Ventaja: El token no pasa por el navegador ni la URL directamente, lo que mejora la seguridad.
🔄 2. Refresh Token Flow
Uso común: Para mantener la sesión del usuario sin pedirle que inicie sesión de nuevo.
🧩 Resumen:
Cuando el access token caduca, se usa un refresh token para obtener uno nuevo.
Solo funciona si el flujo inicial (como el code flow) entregó un refresh token.
✅ Ventaja: Mejora la experiencia de usuario al evitar re-autenticaciones.
🔐 3. Client Credentials Flow
Uso común: Comunicación app-to-app o backend-to-backend, sin usuario.
🧩 Resumen:
El cliente (app) se identifica usando su client ID y secret.
El servidor entrega un access token directamente.
No hay usuario final involucrado.
✅ Ventaja: Ideal para APIs internas, microservicios o tareas automatizadas.
Quiz:
JSON Web Tokens:
🔐 ¿Qué es un JWT?
Un JSON Web Token (JWT) es un token compacto y auto-contenido usado para transmitir información entre dos partes de forma segura como un access token o ID token.
🧩 1. Formatos
✅ Cómo leer su contenido: Es un string en base64 con tres partes: header, payload y signature.
✅ Cómo validarlo: Usando la firma (normalmente HMAC o RSA), verificás que no haya sido alterado.
🎯 2. Propósito
🔒 ¿Para quién es el token? → Identificado con el claim
aud
(audience).🧠 ¿Cuál es su uso? → Por ejemplo, autenticación, autorización, etc.
🌍 ¿A dónde lo puedo enviar? → Solo a recursos que confíen en el issuer del token.
⚙️ 3. Tipo
⚠️ Palabra sobrecargada, puede referirse al tipo de token (
access
,id
,refresh
) o al tipo de transmisión (Bearer, etc).🚀 ¿Cómo se transmite? → Comúnmente en el header
Authorization: Bearer <token>
.Pero super importante enviarlo bajo canales cifrados, like TLS
Bearer token es como el dinero, si tengo dinero puedo ir a una tienda o donde sea elegir algo y comprarlo con mi cash, en este caso bearer es así, puedo usarlo siempre y cuando esté valido y sea dinero real (metafora), podré usarlo en las auths.
by reference:
Este otro tipo de JWT además del bearer
está POP/HoK
bearer
está POP/HoK
que basicamente son como una tarjeta de credito puedes implementarlo pero debes demostrar que dices ser el usuario que dices ser, pasa tal cual como con las credit card no puedo pagar con una credit card que no es mia y ademas debo financiarle dinero del banco a la tarjeta.
Significa que se deben enviar dos partes de
DPoP
dentro del header Authorization.A JWT IS NOT A PROTOCOL, is a format y no es un type.
Quiz:
Scopes and Claims:
🎯 ¿Qué es un Scope?
Los scopes (alcances) definen qué permisos solicita una aplicación al acceder a una API en nombre de un usuario o cliente.
El server authorization final es el que define si el scope se integra con los issues definidos.
Ejemplo de scopes:
🔓 Esto significa:
read:user
: puede leer la info del usuario.write:posts
: puede crear o modificar posts.
🔐 Se usan principalmente durante el OAuth authorization request:
📌 Los scopes limitan lo que puede hacer el token. Son una especie de "contrato" entre el usuario, la app y el API.
🧾 ¿Qué son los Claims?
Los claims son los datos dentro del JWT. Son las piezas de información que se transmiten en el token firmado.
Hay tres tipos:
Registered claims (estándar):
iss
: quién emitió el token.sub
: sujeto (ID del usuario).exp
: fecha de expiración.aud
: audiencia.aud
(de audience) es un claim registrado en los JWT que indica quién está destinado a recibir o consumir ese token.
Es decir, es el identificador de la API o sistema que debe aceptar y validar ese token.
🧠 ¿Por qué es importante?Porque si un token llega a una API que no está en la audiencia, debería ser rechazado. Esto evita que un token válido para un servicio A sea usado indebidamente en un servicio B (replay attacks).
Public claims:
Ej:
name
,email
,picture
.Info general que puede usar el receptor del token.
Private claims:
Claims definidos por tu sistema, como
role
,tenant_id
,plan
.
Ejemplo de payload de JWT:
Juntando SCOPE CON CLAIM:
Quiz:
API’s And Gateways:
un API Gateway es como el portero de discoteca de tu sistema de APIs:
🎩 ¿Qué hace?
Recibe todas las solicitudes de los clientes antes de que lleguen a tu backend.
Valida, filtra, transforma o enruta esas solicitudes hacia el microservicio o backend correspondiente.
Puede agregar seguridad, como:
Autenticación y autorización (
Bearer token
, OAuth2, JWT, etc.)Validación de tokens (como en el phantom token flow)
Rate limiting, logging, CORS, etc.
Gateway con Auth0 añadido:
pero añadimos el phantom token flow que es un nuevo pattern añadido:
El Phantom Token Flow es un patrón utilizado principalmente en arquitecturas API Gateway + Resource Server, cuando se usan tokens de acceso opacos (opaque tokens) con OAuth 2.0. Es una técnica para no exponer información sensible de los tokens directamente al cliente.
¿Para qué se usa?Evitar que el token tenga claims sensibles como
email
,roles
,permissions
, etc., en el lado del cliente.Centralizar la validación en el API Gateway.
Simplificar la lógica del backend (no necesita decodificar ni validar tokens).
Api and gateways interactions:
🪙 Token Exchange vs Embed vs Share
1. 🌀 Token Exchange (Intercambio)
¿Qué es? Cambiar un token por otro diferente, pero relacionado.
¿Por qué se hace? Para obtener un token más específico, seguro o con menos privilegios.
Ejemplo típico:
Un cliente obtiene un Access Token del Authorization Server.
Ese token llega al API Gateway.
El Gateway lo intercambia (exchange) por un token interno más restringido (ej. con menos scopes, más corto, etc.), que es el que usa para llamar a servicios internos.
🔒 Evita exponer directamente tokens externos a servicios internos.
Se usa en phantom token flow (el token externo es opaco, el interno es JWT).
2. 📦 Token Embed (Incrustado)
¿Qué es? Incluir (embed) el token en otro objeto o contexto.
¿Dónde se ve?
En un JWT, donde los claims están embebidos directamente (aud, exp, sub, etc.).
En tokens usados dentro de headers de HTTP:
Authorization: Bearer <token>
es una forma de "embed" el token en la solicitud.
Ejemplo visual:
Token Share (Compartir)
¿Qué es? Usar el mismo token entre distintos componentes.
Riesgo: Cuanto más compartes un token, más superficie de ataque.
Ejemplo:
Un front recibe un token y lo pasa directamente a muchos microservicios.
Si un microservicio se ve comprometido, el token también lo está.
Por eso se evita y se prefiere hacer un exchange o usar phantom token flow.
Introspecti0n, una req valida con todo normal y se manda:
instrospection with exchange, modificamos el content type:
INstrospection, embebemos el JWT dentro del JSON:
instrospection, para intercambiar el token: