01
Qué es y qué problema resuelve
Un access token breve reduce el tiempo durante el que una credencial robada puede usarse. Un refresh token permite obtener nuevos tokens sin repetir el inicio de sesión; por ello requiere protección y revocación propias.
La renovación debe estar a cargo del proveedor de identidad o de un diseño de sesión explícito.
02
Ejemplo paso a paso
Punto de partida Ejemplo de generación y huella para tokens opacos de alta entropía. No constituye un servidor OAuth ni implementa rotación o revocación.
Antes de ejecutar
Ejemplo de consola .NET 10. Integra el fragmento en Program.cs o en sus tipos auxiliares según corresponda; no mezcles declaraciones de tipos antes de instrucciones de nivel superior. No requiere una API ni una base.
using System.Security.Cryptography;
using System.Text;
string token = Convert.ToHexString(RandomNumberGenerator.GetBytes(32));
string huella = Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes(token)));
Console.WriteLine($"Longitud de la huella: {huella.Length}");
// Entregar token por canal seguro; persistir huella y metadatos de sesión.Cómo funciona
- Genera un token opaco con bytes criptográficamente aleatorios.
- Calcula una huella para almacenarla junto con el estado de sesión.
- La renovación completa debe consumir y rotar el token atómicamente.
Resultado esperado: Una huella hexadecimal de 64 caracteres, sin revelar el token.
03
Cuándo usarlo y qué debes evitar
Si gestionas tokens opacos, genera valores criptográficamente aleatorios, almacena una huella y registra familia, expiración y estado. La rotación debe consumir el anterior y crear el siguiente atómicamente.
Dos renovaciones concurrentes y la reutilización de un token consumido requieren una política documentada. No guardes valores originales en logs.
Ampliación opcional · contexto y variantes del tema
CORS, límites y protección de recursos
CORS controla qué orígenes pueden leer respuestas desde un navegador; no evita que otro cliente llame a tu API ni es autenticación. Lista orígenes concretos cuando el navegador necesita acceso. Si usas credenciales, no combines origen comodín con esa política. Permite solo métodos y cabeceras necesarios; revisa preflight y llamadas normales.
Rate limiting restringe una dimensión de consumo. Un límite global evita una parte de la carga; una partición por usuario distribuye presupuesto; límites por IP requieren interpretar proxies de confianza y pueden agrupar usuarios legítimos detrás de una red. El limitador en memoria solo cubre una instancia. Para varias instancias considera un control compartido o de borde y documenta garantías.
Protege tamaño del cuerpo, longitud de filtros, número de resultados y tiempo de consultas. Un 429 indica rechazo por cuota; diseña reintentos con espera y evita un ciclo inmediato que empeore la carga. Ningún limitador sustituye índices, autorización o un presupuesto de trabajo por operación.
Punto de partida portal.example es un dominio ficticio. Sustitúyelo solo al integrar el entorno real. Esta política no incluye cookies ni habilita AllowCredentials.
Antes de ejecutar
Configuración ilustrativa de navegador
builder.Services.AddCors(opciones =>
opciones.AddPolicy("portal", politica => politica
.WithOrigins("https://portal.example")
.WithMethods("GET", "POST")
.WithHeaders("Authorization", "Content-Type")));
// Después de routing y antes de autorización:
app.UseCors("portal");Resultado esperado: El navegador permite los orígenes definidos; un cliente de consola aún necesita autorización.
04 · Práctica guiada · opcional
Practica lo aprendido
Genera un token y su huella sin mostrarlos. Diseña la transición vigente → consumido y la revocación de sesión, incluyendo dos renovaciones simultáneas.
- 01Comprueba la longitud de la huella sin registrar el secreto.
- 02Dibuja estados y define una actualización atómica que solo permita consumir un token vigente una vez.
- 03Identifica qué prueba con almacenamiento necesitarías para verificar concurrencia y revocación.
Ver solución orientativa
La huella hexadecimal tiene 64 caracteres. Generarla no implementa renovación. El servidor debe vincularla con sesión, expiración y estado, y confirmar el consumo de forma atómica; la política distingue reintento legítimo y reutilización sospechosa.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿Un refresh token es solo un JWT de mayor duración?
No. Tiene otra finalidad y necesita controles de renovación y revocación.
02¿Qué parte de una renovación segura muestra el código y qué parte falta implementar?
El código genera un secreto y su huella. Falta gestionar sesión, expiración, consumo atómico, rotación y revocación; medir 64 caracteres no verifica ninguna de esas transiciones.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- La huella tiene 64 caracteres y el token no aparece en logs.
- El diseño distingue vigente, consumido y revocado y prevé un único consumo confirmado en almacenamiento.
Qué debes recordar
- Renovar una sesión requiere estado y controles propios.
- El token original no debe aparecer en logs.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Explicaciones, ejemplos y prácticas propios de Academia de Software. Los fragmentos de integración requieren las dependencias indicadas; el ZIP contiene el núcleo de consola. Las lecturas externas se consultan en su sitio original y conservan sus condiciones. Procedencia y condiciones de uso.