WWW-Authenticate

Envía usuario y contraseña codificados en Base64 en cada petición. Base64 no es cifrado — cualquiera que intercepte la cabecera lee la contraseña en claro.

WWW-Authenticate: Basic realm="demo"

• ·Reversible al instante: atob("dXNlcjpwYXNzd29yZA==") → "user:password".
• ·Obliga a usar HTTPS siempre; sin TLS la credencial viaja expuesta.
• ·No hay expiración ni revocación: la credencial vale hasta que cambie la contraseña.
• ·El navegador muestra un diálogo nativo de usuario/contraseña.

Authorization: Basic dXNlcjpwYXNzd29yZA==

Esquema desafío–respuesta: el servidor envía un nonce y el cliente responde con un hash, nunca con la contraseña. Mejora a Basic pero MD5 ya es débil.

WWW-Authenticate: Digest realm="demo", nonce="…", algorithm=MD5, qop="auth"

• ·La contraseña nunca viaja por la red, solo un hash derivado.
• ·El nonce mitiga ataques de repetición (replay).
• ·qop="auth" protege también el método y la URI de la petición.
• ·Sigue dependiendo de MD5/SHA-256; menos práctico que tokens para APIs.

Authorization: Digest username="user", realm="demo", nonce="…", uri="/demo/digest", response="…", qop=auth, nc=00000001, cnonce="…"

El cliente porta un token de acceso (a menudo un JWT) emitido por un servidor de autorización. "El que lo porta, lo usa" — por eso el token debe protegerse como una credencial.

WWW-Authenticate: Bearer
  realm="demo",
  scope="read write",
  error="invalid_token",
  error_description="El token ha expirado o es inválido",
  error_uri="https://…/docs/errors/invalid_token"

• ·realm (opcional) — ámbito de protección; no debe repetirse.
• ·scope (opcional) — lista de scopes requeridos separados por espacio, ej. "read write".
• ·error (opcional) — razón del rechazo: invalid_request · invalid_token · insufficient_scope.
• ·error_description (opcional) — explicación legible del error, solo para desarrolladores.
• ·error_uri (opcional) — URI absoluta con documentación del error.
• ·Si el token es un JWT, su header y payload son legibles (no cifrados) — no guardes secretos dentro.

# El cliente conoce el token endpoint de antemano (documentación, SDK, config)
→ POST https://auth.example.com/token
   grant_type=client_credentials&scope=read
← 200 { "access_token": "eyJ…", "token_type": "Bearer", "expires_in": 3600 }

# Si se conoce el issuer, se infiere la URL del AS metadata:
→ GET https://auth.example.com/.well-known/oauth-authorization-server
← 200 {
    "token_endpoint": "https://auth.example.com/token",
    "authorization_endpoint": "https://auth.example.com/authorize"
  }
# Fallback OIDC si 404:
→ GET https://auth.example.com/.well-known/openid-configuration

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

• ·RFC 6750 no incluye la URL del AS en el reto — el cliente debe conocerla de antemano o inferirla.
• ·Opción A (definida): el token endpoint se configura explícitamente en el cliente (SDK, env var, docs).
• ·Opción B (inferida): si se conoce el issuer, se construye /.well-known/oauth-authorization-server siguiendo RFC 8414.
• ·Para discovery completamente automático desde el reto 401, usar Bearer + Discovery (RFC 9728).

OAuth 2.0 Protected Resource Metadata. El reto 401 ya no solo dice "necesitas un Bearer": apunta a un documento de metadatos que describe DÓNDE y CÓMO obtener un token. El cliente descubre todo automáticamente.

WWW-Authenticate: Bearer resource_metadata="https://…/.well-known/oauth-protected-resource.json"

• ·resource_metadata — único parámetro del reto; URL del documento de metadatos del recurso.
• ·El cliente extrae authorization_servers[0] como issuer identifier del AS.
• ·Habilita clientes genéricos: descubren el flujo completo a partir de un único 401.
• ·Clave para ecosistemas como agentes y MCP, donde el cliente no conoce de antemano al emisor.

← 401 WWW-Authenticate: Bearer resource_metadata="https://…/.well-known/oauth-protected-resource.json"

→ GET https://…/.well-known/oauth-protected-resource.json
← 200 {
    "resource": "https://…/demo/bearer2",
    "authorization_servers": ["https://auth.example.com"],
    "scopes_supported": ["read", "write"]
  }

→ GET https://auth.example.com/.well-known/oauth-authorization-server
← 200 {
    "issuer": "https://auth.example.com",
    "authorization_endpoint": "https://auth.example.com/authorize",
    "token_endpoint": "https://auth.example.com/token",
    "scopes_supported": ["read", "write"],
    "grant_types_supported": ["authorization_code", "client_credentials"]
  }

→ GET https://auth.example.com/.well-known/openid-configuration
← 200 {
    "issuer": "https://auth.example.com",
    "authorization_endpoint": "https://auth.example.com/authorize",
    "token_endpoint": "https://auth.example.com/token",
    "userinfo_endpoint": "https://auth.example.com/userinfo",
    "jwks_uri": "https://auth.example.com/jwks"
  }

→ POST https://auth.example.com/token
← 200 { "access_token": "eyJ…", "token_type": "Bearer", "expires_in": 3600 }

→ GET https://…/demo/bearer2
   Authorization: Bearer eyJ…
← 200 OK

• ·Paso 3a — RFC 8414: busca /.well-known/oauth-authorization-server[/{path}] usando el issuer.
• ·Paso 3b — Si 404, fallback a OpenID Connect Discovery: /.well-known/openid-configuration.
• ·La construcción de la URL sigue la misma regla: well-known insertado entre host y path del issuer.
• ·El documento AS expone authorization_endpoint, token_endpoint, scopes_supported, grant_types…
• ·Con esos endpoints el cliente completa el flujo OAuth y obtiene un token Bearer válido.