Habilitando CORS en nuestro servidor
Clase 12 de 39 • Curso de Autenticación con OAuth
Contenido del curso
JSON Web Tokens
- 5

JSON Web Tokens
08:34 min - 6

Autenticación tradicional vs JWT
08:08 min - 7

Configuración inicial de los proyectos
08:22 min - 8

Firmando un JWT
15:23 min - 9

Verificando nuestro JWT firmado y buenas practicas con JWT
11:43 min - 10

Server-Side vs Client-Side sessions
05:23 min - 11

Protegiendo nuestros recursos con JWT
04:38 min - 12

Habilitando CORS en nuestro servidor
Viendo ahora - 13

Profundizando el concepto de JWKS
02:24 min
OAuth 2.0
- 14

Cómo elegir el flujo adecuado para OAuth 2.0
02:54 min - 15

¿Qué es OAuth 2.0?
00:15 min - 16

Conociendo el API de Spotify
07:29 min - 17

Creando los clientes de Spotify y servicios iniciales
16:46 min - 18

Implementando Authorization Code Grant
14:54 min - 19

Usando nuestro access token para obtener nuestros recursos
07:12 min - 20

Implementando Implicit Grant
09:11 min - 21

Implementando nuestro servicio de autenticación
08:46 min - 22

Modificando nuestro Layout
09:18 min - 23

Implementando Client Credentials Grant
09:52 min - 24

Implementando Resource Owner Password Grant
01:46 min - 25

Implementando Authorization Code Grant (PKCE)
02:26 min
Open ID Connect
Preocupaciones con JWT y OAuth 2.0
Haciendo uso de Auth0
Consideraciones para producción
Cierre del curso
El Intercambio de Recursos de Origen Cruzado (Cross-Origin Resource Sharing) es un mecanismo que agrega unos encabezados (Headers) adicionales HTTP para permitir que un user agent (generalmente un navegador) obtenga permisos para acceder a los recursos de un servidor en un origin distinto (dominio) del que pertenece.
Por ejemplo una solicitud de origen cruzado seria hacer una petición AJAX desde una aplicación que se encuentra en https://dominio-a.com para cargar el recurso https://api.dominio-b.com/data.json.
Por razones de seguridad, los navegadores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script.
Si necesitamos permitir request desde un dominio diferente al del servidor podemos usar el middleware cors para permitirlo, pero es importante no dejarlo expuesto a todos los dominios.
Habilitar CORS para todos los request
Este no es recomendado en producción.
const express = require("express"); const cors = require("cors"); const app = express(); app.use(cors()); app.get("/products/:id", function(req, res, next) { res.json({ msg: "This is CORS-enabled for all origins!" }); }); app.listen(8000, function() { console.log("CORS-enabled web server listening on port 8000"); });
Habilitar CORS para los request especificos de un cliente
Por el contrario, este sí es recomendado para producción.
const express = require("express"); const cors = require("cors"); const app = express(); const corsOptions = { origin: "http://example.com" }; app.use(cors(corsOptions)); app.get("/products/:id", function(req, res, next) { res.json({ msg: "This is CORS-enabled for only example.com." }); }); app.listen(8000, function() { console.log("CORS-enabled web server listening on port 8000"); });
Debemos tener en cuenta que para aplicaciones server-side es poco probable que necesiten el uso de CORS debido a que las aplicaciones conviven en el mismo dominio. Sin embargo, es buena practica habilitarlo para los llamados externos de nuestra API.
Más información sobre el middleware cors en https://expressjs.com/en/resources/middleware/cors.html