Producto o servicio |
Artículo |
Microsoft Entra ID |
|
Dispositivo IoT |
|
Base de datos de documentos de Azure |
|
ADFS |
|
Identity Server |
|
Aplicación web |
|
API web |
|
Implementar el cierre de sesión adecuado utilizando métodos MSAL cuando se utiliza Microsoft Entra ID
Ejemplo
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.Events.OnRedirectToIdentityProviderForSignOut = async context =>
{
//Your logic here
};
});
Use duraciones finitas para los tokens de SaS generados
Título |
Detalles |
Componente |
Dispositivo IoT |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
Los tokens de SaS generados para la autenticación en Azure IoT Hub deben tener un período finito de expiración. Mantenga las duraciones de los tokens de SaS en un mínimo para limitar el período de tiempo que se pueden reproducir en caso de que los tokens se vean en peligro. |
Use duraciones mínimas de token para los tokens de recursos generados
Título |
Detalles |
Componente |
Azure DocumentDB |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
Reduzca el intervalo de tiempo del token de recurso a un valor mínimo necesario. Los tokens de recursos tienen un intervalo de tiempo válido predeterminado de 1 hora. |
Implemente el cierre de sesión correcto mediante métodos WsFederation cuando use ADFS
Título |
Detalles |
Componente |
ADFS |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
Si la aplicación se basa en un token de STS emitido por ADFS, el controlador de eventos de cierre de sesión debe llamar al método WSFederationAuthenticationModule.FederatedSignOut() para cerrar la sesión del usuario. Además, se debe destruir la sesión actual, y se debe restablecer y anular el valor del token de sesión. |
Ejemplo
[HttpPost, ValidateAntiForgeryToken]
[Authorization]
public ActionResult SignOut(string redirectUrl)
{
if (!this.User.Identity.IsAuthenticated)
{
return this.View("LogOff", null);
}
// Removes the user profile.
this.Session.Clear();
this.Session.Abandon();
HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
{
Expires = DateTime.Now.AddDays(-1D),
Secure = true,
HttpOnly = true
});
// Signs out at the specified security token service (STS) by using the WS-Federation protocol.
Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
if (!string.IsNullOrEmpty(redirectUrl))
{
replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
}
// Signs out of the current session and raises the appropriate events.
var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
authModule.SignOut(false);
// Signs out at the specified security token service (STS) by using the WS-Federation
// protocol.
WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
return new RedirectResult(redirectUrl);
}
Implemente el cierre de sesión correcto cuando use Identity Server
Título |
Detalles |
Componente |
Servidor de Identidad |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
IdentityServer admite la capacidad de federación con proveedores de identidades externos. Cuando un usuario cierra sesión en un proveedor de identidades precedente, según el protocolo que se use, podría ser posible recibir una notificación cuando el usuario cierre la sesión. Esto permite, a su vez, que IdentityServer notifique a sus clientes para que también cierren la sesión del usuario. Consulte la documentación en la sección Referencias para ver los detalles de la implementación. |
Las aplicaciones disponibles a través de HTTPS deben usar cookies seguras
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
EnvironmentType - OnPrem |
Referencias |
httpCookies (Elemento, Esquema de configuración de ASP.NET), Propiedad HttpCookie.Secure |
Pasos |
Normalmente, las cookies solo son accesibles para el dominio a cuyo ámbito se limitaron. Lamentablemente, la definición de "dominio" no incluye el protocolo, así que las cookies que se crean a través de HTTPS son accesibles a través de HTTP. El atributo "secure" indica al explorador que la cookie solo debe estar disponible a través de HTTPS. Asegúrese de que todas las cookies establecidas a través de HTTPS usen el atributo secure. Para aplicar el requisito en el archivo Web.config, establezca el atributo requireSSL en true. Se trata del método preferido porque aplicará el atributo secure para todas las cookies actuales y futuras sin necesidad de que se realice ningún otro cambio en el código. |
Ejemplo
<configuration>
<system.web>
<httpCookies requireSSL="true"/>
</system.web>
</configuration>
La configuración se aplica incluso si se usa HTTP para tener acceso a la aplicación. Si se utiliza HTTP para tener acceso a la aplicación, la configuración la interrumpe porque las cookies están establecidas con el atributo secure y el explorador no las enviará de vuelta a la aplicación.
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Formularios Web Forms, MVC5 |
Atributos |
EnvironmentType - OnPrem |
Referencias |
N/D |
Pasos |
Cuando la aplicación web es el usuario de confianza y el proveedor de identidades es el servidor AD FS, se puede configurar el atributo secure del token FedAuth estableciendo requireSSL en True en la sección system.identityModel.services del archivo Web.config: |
Ejemplo
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
....
</federationConfiguration>
</system.identityModel.services>
Todas las aplicaciones basadas en HTTP deben especificar HTTP solo para la definición de cookies
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
Atributo de cookie segura |
Pasos |
Para mitigar el riesgo de divulgación de información por un ataque de scripting entre sitios (XSS), se incorporó un nuevo atributo (httpOnly) a las cookies, el cual es compatible con todos los exploradores principales. El atributo especifica que una cookie no es accesible a través de un script. Al usar cookies HttpOnly, una aplicación web reduce la posibilidad de que se robe mediante un script la información confidencial contenida en la cookie y se envíe al sitio web de un atacante. |
Ejemplo
Todas las aplicaciones basadas en HTTP que usen cookies deben especificar HttpOnly en la definición de la cookie; para ello, se debe implementar la siguiente configuración en el archivo Web.config:
<system.web>
.
.
<httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Formularios Web Forms |
Atributos |
N/D |
Referencias |
Propiedad FormsAuthentication.RequireSSL |
Pasos |
El valor de la propiedad RequireSSL se establece en el archivo de configuración para una aplicación ASP.NET mediante el atributo requireSSL del elemento de configuración. Puede especificar en el archivo Web.config de la aplicación ASP.NET si se requiere Seguridad de la capa de transporte (TLS), conocido anteriormente como SSL (Capa de sockets seguros), para devolver la cookie de autenticación de formularios al servidor estableciendo el atributo requireSSL. |
Ejemplo
En el ejemplo de código siguiente, se establece el atributo requireSSL en el archivo Web.config.
<authentication mode="Forms">
<forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
MVC5 |
Atributos |
EnvironmentType - OnPrem |
Referencias |
Windows Identity Foundation (WIF) Configuration – Part II (Configuración de Windows Identity Foundation: parte II) |
Pasos |
Para establecer el atributo httpOnly para las cookies FedAuth, el valor del atributo hideFromScript debe establecerse en True. |
Ejemplo
En el siguiente ejemplo se muestra la configuración correcta:
<federatedAuthentication>
<cookieHandler mode="Custom"
hideFromScript="true"
name="FedAuth"
path="/"
requireSsl="true"
persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>
Mitigue el riesgo de ataques de falsificación de solicitud entre sitios (CSRF) en páginas web ASP.NET
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
La falsificación de solicitud entre sitios (CSRF o XSRF) es un tipo de ataque en el que un atacante puede llevar a cabo acciones en el contexto de seguridad de una sesión establecida de un usuario diferente en un sitio web. El objetivo es modificar o eliminar contenido, si el sitio web de destino confía exclusivamente en cookies de sesión para autenticar la solicitud recibida. Un atacante podría aprovechar esta vulnerabilidad y hacer que el explorador de un usuario diferente cargue una dirección URL con un comando procedente de un sitio vulnerable en el que el usuario ya haya iniciado sesión. Hay muchas maneras de hacerlo, como hospedar un sitio web diferente que carga un recurso desde el servidor vulnerable o conseguir que el usuario haga clic en un vínculo. El ataque se puede evitar si el servidor envía un token adicional al cliente, requiere que el cliente lo incluya en todas las solicitudes futuras y comprueba que todas las solicitudes futuras incluyan un token asociado a la sesión actual, como con los métodos AntiForgeryToken o ViewState de ASP.NET. |
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
MVC5, MVC6 |
Atributos |
N/D |
Referencias |
XSRF/CSRF Prevention in ASP.NET MVC and Web Pages (Prevención de XSRF y CSRF en ASP.NET MVC y Web Pages) |
Pasos |
En formularios anti-CSRF y de ASP.NET MVC: use el método del asistente AntiForgeryToken en vistas; incluya un elemento Html.AntiForgeryToken() en el formulario, como en el siguiente ejemplo. |
Ejemplo
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
Ejemplo
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Ejemplo
Al mismo tiempo, Html.AntiForgeryToken() proporciona al visitante una cookie denominada __RequestVerificationToken, con el mismo valor que el valor aleatorio de hidden mostrado arriba. A continuación, para validar un envío de formulario entrante, agregue el filtro [ValidateAntiForgeryToken] al método de acción de destino. Por ejemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorización que comprueba que:
- La solicitud entrante tenga una cookie denominada __RequestVerificationToken;
- La solicitud entrante tenga una entrada
Request.Form
denominada __RequestVerificationToken;
- Estos valores de cookie y
Request.Form
coincidan. Suponiendo que todo sea correcto, la solicitud entra de la forma normal. De lo contrario, aparece un error de autorización con el mensaje "No se especificó un token antifalsificación o el que se especificó no era válido".
Ejemplo
Anti-CSRF y AJAX: el token de formulario puede ser un problema para las solicitudes AJAX, porque estas podrían enviar datos JSON en lugar de datos de formulario HTML. Una solución consiste en enviar los tokens en un encabezado HTTP personalizado. En el código siguiente, se utiliza sintaxis de Razor para generar los tokens, que después se agregan a una solicitud AJAX.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Ejemplo
Cuando procese la solicitud, extraiga los tokens del encabezado de la solicitud. A continuación, llame al método AntiForgery.Validate para validar los tokens. El método Validate produce una excepción si los tokens no son válidos.
void ValidateRequestHeader(HttpRequestMessage request)
{
string cookieToken = "";
string formToken = "";
IEnumerable<string> tokenHeaders;
if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
{
string[] tokens = tokenHeaders.First().Split(':');
if (tokens.Length == 2)
{
cookieToken = tokens[0].Trim();
formToken = tokens[1].Trim();
}
}
AntiForgery.Validate(cookieToken, formToken);
}
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Formularios Web Forms |
Atributos |
N/D |
Referencias |
Cómo aprovechar las ventajas de las características integradas de ASP.NET para rechazar los ataques a través de Internet |
Pasos |
Los ataques CSRF en aplicaciones basadas en formularios Web Forms se pueden mitigar si se establece ViewStateUserKey en una cadena aleatoria que varíe para cada usuario, como el id. de usuario o, mejor aún, el identificador de sesión. Por diversas razones técnicas y sociales, el id. de sesión es mucho más adecuado porque es imprevisible, agota el tiempo de espera y varía para cada usuario. |
Ejemplo
Este es el código que debe tener en todas las páginas:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
:
}
Configure la sesión para la duración de la inactividad
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
Propiedad HttpSessionState.Timeout |
Pasos |
El tiempo de espera de la sesión representa el evento que se produce cuando un usuario no realiza ninguna acción en un sitio web durante un intervalo (definido por el servidor web). El evento, en el servidor, cambia el estado de la sesión del usuario a "inválido" (por ejemplo, "ya no se usa") e indica al servidor web que lo destruya (se eliminan todos los datos que contiene). En el ejemplo de código siguiente, se establece el atributo de sesión de tiempo de espera en 15 minutos en el archivo Web.config. |
Ejemplo
<configuration>
<system.web>
<sessionState mode="InProc" cookieless="true" timeout="15" />
</system.web>
</configuration>
Habilitamiento de la detección de amenazas en Azure SQL
Ejemplo
<forms name=".ASPXAUTH" loginUrl="login.aspx" defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Formularios Web Forms, MVC5 |
Atributos |
EnvironmentType - OnPrem |
Referencias |
asdeqa |
Pasos |
Cuando la aplicación web es Usuario de confianza y ADFS es el STS, la duración de las cookies de autenticación (tokens de FedAuth) se puede establecer mediante la siguiente configuración en web.config: |
Ejemplo
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
<!-- Set requireHttps=true; -->
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
<!--
Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
<serviceCertificate>
<certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
-->
</federationConfiguration>
</system.identityModel.services>
Ejemplo
Además, la duración del token de notificación SAML emitido por ADFS se debe establecer en 15 minutos ejecutando el siguiente comando de PowerShell en el servidor de AD FS:
Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true
Implemente el cierre de sesión correcto desde la aplicación
Título |
Detalles |
Componente |
Aplicación web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
Realice el cierre de sesión correctamente desde la aplicación, cuando el usuario presione el botón de cierre de sesión. Al cerrar la sesión, la aplicación debe destruir la sesión del usuario y también restablecer y anular el valor de la cookie de la sesión, así como restablecer y anular el valor de la cookie de autenticación. Además, cuando hay varias sesiones asociadas a una sola identidad de usuario, se deben finalizar colectivamente en el lado servidor cuando se agote el tiempo de espera o se produzca el cierre de sesión. Por último, asegúrese de que la funcionalidad de cierre de sesión esté disponible en todas las páginas. |
Mitigue el riesgo de ataques de falsificación de solicitud entre sitios (CSRF) en las API web de ASP.NET
Título |
Detalles |
Componente |
API Web |
Fase de SDL |
Construir |
Tecnologías aplicables |
Genérico |
Atributos |
N/D |
Referencias |
N/D |
Pasos |
La falsificación de solicitud entre sitios (CSRF o XSRF) es un tipo de ataque en el que un atacante puede llevar a cabo acciones en el contexto de seguridad de una sesión establecida de un usuario diferente en un sitio web. El objetivo es modificar o eliminar contenido, si el sitio web de destino confía exclusivamente en cookies de sesión para autenticar la solicitud recibida. Un atacante podría aprovechar esta vulnerabilidad y hacer que el explorador de un usuario diferente cargue una dirección URL con un comando procedente de un sitio vulnerable en el que el usuario ya haya iniciado sesión. Hay muchas maneras de hacerlo, como hospedar un sitio web diferente que carga un recurso desde el servidor vulnerable o conseguir que el usuario haga clic en un vínculo. El ataque se puede evitar si el servidor envía un token adicional al cliente, requiere que el cliente lo incluya en todas las solicitudes futuras y comprueba que todas las solicitudes futuras incluyan un token asociado a la sesión actual, como con los métodos AntiForgeryToken o ViewState de ASP.NET. |
Título |
Detalles |
Componente |
API Web |
Fase de SDL |
Construir |
Tecnologías aplicables |
MVC5, MVC6 |
Atributos |
N/D |
Referencias |
Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API (Prevención de ataques de falsificación de solicitud entre sitios [CSRF] en ASP.NET Web API) |
Pasos |
Anti-CSRF y AJAX: el token de formulario puede ser un problema para las solicitudes AJAX, porque estas podrían enviar datos JSON en lugar de datos de formulario HTML. Una solución consiste en enviar los tokens en un encabezado HTTP personalizado. En el código siguiente, se utiliza sintaxis de Razor para generar los tokens, que después se agregan a una solicitud AJAX. |
Ejemplo
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Ejemplo
Cuando procese la solicitud, extraiga los tokens del encabezado de la solicitud. A continuación, llame al método AntiForgery.Validate para validar los tokens. El método Validate produce una excepción si los tokens no son válidos.
void ValidateRequestHeader(HttpRequestMessage request)
{
string cookieToken = "";
string formToken = "";
IEnumerable<string> tokenHeaders;
if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
{
string[] tokens = tokenHeaders.First().Split(':');
if (tokens.Length == 2)
{
cookieToken = tokens[0].Trim();
formToken = tokens[1].Trim();
}
}
AntiForgery.Validate(cookieToken, formToken);
}
Ejemplo
En formularios anti-CSRF y de ASP.NET MVC: use método del asistente AntiForgeryToken en vistas; incluya un elemento Html.AntiForgeryToken() en el formulario, como en el siguiente ejemplo.
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
}
Ejemplo
La salida se parecerá a lo siguiente:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Ejemplo
Al mismo tiempo, Html.AntiForgeryToken() proporciona al visitante una cookie denominada __RequestVerificationToken, con el mismo valor que el valor aleatorio de hidden mostrado arriba. A continuación, para validar un envío de formulario entrante, agregue el filtro [ValidateAntiForgeryToken] al método de acción de destino. Por ejemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorización que comprueba que:
- La solicitud entrante tenga una cookie denominada __RequestVerificationToken;
- La solicitud entrante tenga una entrada
Request.Form
denominada __RequestVerificationToken;
- Estos valores de cookie y
Request.Form
coincidan. Suponiendo que todo sea correcto, la solicitud entra de la forma normal. De lo contrario, aparece un error de autorización con el mensaje "No se especificó un token antifalsificación o el que se especificó no era válido".
Título |
Detalles |
Componente |
API Web |
Fase de SDL |
Construir |
Tecnologías aplicables |
MVC5, MVC6 |
Atributos |
Proveedor de identidades - ADFS, Proveedor de identidades - Id. de Microsoft Entra |
Referencias |
Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2 (Protección de una API web con cuentas individuales e inicio de sesión local en ASP.NET Web API 2.2) |
Pasos |
Si la API web se protege con OAuth 2.0, espera un token de portador en el encabezado de solicitud de autorización y concede acceso a la solicitud solo si el token es válido. A diferencia de la autenticación basada en cookies, los exploradores no adjuntan los tokens de portador a las solicitudes. El cliente solicitante debe adjuntar explícitamente el token de portador al encabezado de solicitud. Por lo tanto, para las API web de ASP.NET protegidas con OAuth 2.0, los tokens de portador se consideran una defensa contra los ataques CSRF. Tenga en cuenta que, si la parte MVC de la aplicación utiliza la autenticación de formularios (es decir, usa cookies), la aplicación web de MVC debe usar tokens antifalsificación. |
Ejemplo
Se ha de informar a la API web de que solo debe confiar en tokens de portador y no en cookies. Se puede realizar mediante la siguiente configuración en el método WebApiConfig.Register
:
config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
El método SuppressDefaultHostAuthentication indica a API Web que ignore toda autenticación que se produzca antes de que la solicitud llegue a la canalización de API Web, ya sea mediante IIS o middleware de OWIN. De este modo, se puede restringir API Web para la autenticación solo con tokens de portador.