Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 9 de este artículo.
Importante
Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.
Para la versión actual, consulte la versión de .NET 9 de este artículo.
En este artículo se describe cómo proteger un objeto Blazor Web App con OpenID Connect (OIDC) mediante una aplicación de ejemplo en el repositorio de GitHub dotnet/blazor-samples
(.NET 8 o posterior) (cómo descargar).
Para Microsoft Entra ID o Azure AD B2C, puede utilizar AddMicrosoftIdentityWebApp de Microsoft Identity Web (Microsoft.Identity.Web
Paquete NuGet, Documentación API), que añade tanto el OIDC como el Cookie con los valores predeterminados adecuados. La aplicación de ejemplo y las instrucciones de este artículo no usan Microsoft Identity Web. En la guía se muestra cómo configurar el controlador OIDC manualmente para cualquier proveedor de OIDC. Para obtener más información sobre la implementación de Microsoft Identity Web, consulte la sección Proteja un ASP.NET Core Blazor Web App con Microsoft Entra ID.
En esta versión del artículo se describe la implementación de OIDC sin adoptar el patrón de back-end para front-end (BFF) con una aplicación que adopta la representación automática interactiva global (servidor y proyectos de .Client
). El patrón BFF es útil para realizar solicitudes autenticadas a servicios externos. Cambie el selector de versión del artículo a patrón BFF si la especificación de la aplicación llama a la adopción del patrón BFF.
Se adopta la especificación siguiente:
- La Blazor Web App utiliza el modo de renderizado automático con interactividad global.
- Las aplicaciones cliente y el servidor usan los servicios de proveedor de estado de autenticación personalizados para capturar el estado de autenticación del usuario y hacer que fluya entre el servidor y el cliente.
- Esta aplicación es un punto de partida para cualquier flujo de autenticación de OIDC. OIDC se configura manualmente en la aplicación y no se basa en los paquetes Microsoft Entra ID ni Microsoft Identity Web, y la aplicación de ejemplo tampoco requiere el hospedaje de Microsoft Azure. Sin embargo, la aplicación de ejemplo puede usarse con Entra y Microsoft Identity Web, y hospedarse en Azure.
- Actualización automática del token sin interacción.
- Un proyecto de API web independiente muestra una llamada de API web segura para los datos meteorológicos.
Para una experiencia alternativa utilizando Microsoft Authentication Library for .NET, Microsoft Identity Web y Microsoft Entra ID, consulte Proteger un núcleo ASP.NET Blazor Web App con Microsoft Entra ID.
Solución de ejemplo
La aplicación de ejemplo consta de los siguientes proyectos:
-
BlazorWebAppOidc
: proyecto del lado servidor de la Blazor Web App, que contiene un punto de conexión de API mínima de ejemplo para datos meteorológicos. -
BlazorWebAppOidc.Client
: proyecto del lado cliente de la Blazor Web App. -
MinimalApiJwt
: API web de back-end con un endpoint Minimal API para datos meteorológicos.
Acceda al ejemplo a través de la carpeta de versión más reciente del repositorio de ejemplos de Blazor con el vínculo siguiente. El ejemplo se encuentra en la carpeta BlazorWebAppOidc
para .NET 8 o posterior.
Inicie la solución desde el Aspire/Aspire.AppHost
proyecto.
Vea o descargue el código de ejemplo (cómo descargarlo)
Características de la solución de ejemplo:
Actualización automática de tokens no interactivos con la ayuda de un actualizador personalizado cookie (
CookieOidcRefresher.cs
).Los datos meteorológicos se gestionan mediante un punto de conexión de API mínimo (
/weather-forecast
) en el archivo (Program
) del proyecto (Program.cs
). El punto de conexión requiere autorización llamando a RequireAuthorization. Para los controladores que agregues al proyecto, agrega el atributo[Authorize]
al controlador o la acción. Para obtener más información sobre cómo requerir autorización en la aplicación a través de una directiva de autorización y excluir la autorización en un subconjunto de puntos de conexión públicos, consulte la guía de OIDC de Razor Pages.La aplicación llama de forma segura a una API web para los datos meteorológicos:
- Al renderizar el componente
Weather
en el servidor, el componente usa elServerWeatherForecaster
en el servidor para obtener datos meteorológicos de la API web en el proyectoMinimalApiJwt
mediante un DelegatingHandler (TokenHandler
) que adjunta el token de acceso de HttpContext a la solicitud. - Cuando el componente se representa en el cliente, el componente usa la implementación del servicio
ClientWeatherForecaster
, que utiliza un HttpClient preconfigurado (en el archivo del proyecto cliente deProgram
) para realizar la llamada a la API web desde el proyecto del servidorServerWeatherForecaster
.
- Al renderizar el componente
- El proyecto de servidor llama a AddAuthenticationStateSerialization para agregar un proveedor de estado de autenticación del lado del servidor que usa PersistentComponentState para transmitir el estado de autenticación al cliente. El cliente llama AddAuthenticationStateDeserialization para deserializar y usar el estado de autenticación pasado por el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
- La clase
PersistingAuthenticationStateProvider
(PersistingAuthenticationStateProvider.cs
) es un AuthenticationStateProvider del lado servidor que usa PersistentComponentState para hacer fluir el estado de autenticación, que posteriormente es fijo durante la vigencia de la aplicación WebAssembly, al cliente.
Para obtener más información sobre las llamadas API (web) mediante abstracciones de servicio en Blazor Web App, consulta Llamada a una API web desde una aplicación Blazor de ASP.NET Core.
Registros de aplicaciones de identificación de Microsoft Entra
Se recomienda usar registros independientes para aplicaciones y API web, incluso cuando las aplicaciones y las API web están en la misma solución. Las instrucciones siguientes son para la aplicación BlazorWebAppOidc
y MinimalApiJwt
API web de la solución de ejemplo, pero las mismas instrucciones se aplican generalmente a los registros basados en Entra para aplicaciones y API web.
Registre primero la API web (MinimalApiJwt
) para que pueda conceder acceso a la API web al registrar la aplicación. El identificador de inquilino y el identificador de cliente de la API web se usan para configurar la API web en su Program
archivo. Después de registrar la API web, exponga la API web en Registros> de aplicacionesExponga una API con un nombre de ámbito de Weather.Get
. Registre el URI del identificador de aplicación para usarlo en la configuración de la aplicación.
A continuación, registre la aplicación (BlazorWebAppOidc
/BlazorWebApOidc.Client
) con una configuración de plataforma web y un URI de redirección de https://localhost/signin-oidc
(no se requiere un puerto). El identificador de inquilino y el identificador de cliente de la aplicación, junto con la dirección base de la API web, el URI del identificador de aplicación y el nombre del ámbito meteorológico, se usan para configurar la aplicación en su Program
archivo. Conceda permiso de API para acceder a la API web en registros de aplicaciones>permisos de API. Si la especificación de seguridad de la aplicación lo requiere, puede conceder el consentimiento del administrador para que la organización acceda a la API de la web. Los usuarios y grupos autorizados están asignados al registro de la aplicación en Registros de aplicaciones>Aplicaciones empresariales.
En la configuración de registro de aplicaciones de flujos híbridos y concesión implícita de Entra o Azure Portal, no active ninguna casilla para que el punto de conexión de autorización devuelva tokens de acceso o tokens de identificador. El controlador de OpenID Connect solicita automáticamente los tokens adecuados mediante el código devuelto desde el punto de conexión de autorización.
Cree un secreto de cliente en el registro de la aplicación en Entra o Azure Portal (Administrar>certificados y secretos>Nuevo secreto de cliente). Mantenga presionado el valor del secreto de cliente para usar la sección siguiente.
Más adelante en este artículo se proporcionan instrucciones de configuración de Entra adicionales para configuraciones específicas.
Establecimiento del secreto de cliente
Esta sección solo se aplica al proyecto de servidor de Blazor Web App (BlazorWebAppOidc
project).
Advertencia
No almacene secretos de aplicación, cadena de conexión s, credenciales, contraseñas, números de identificación personal (PIN), código C#/.NET privado o claves o tokens privados en el código del lado cliente, lo que siempre es inseguro. En entornos de prueba/ensayo y producción, el código del lado Blazor servidor y las API web deben usar flujos de autenticación seguros que eviten mantener las credenciales dentro del código del proyecto o los archivos de configuración. Fuera de las pruebas de desarrollo local, se recomienda evitar el uso de variables de entorno para almacenar datos confidenciales, ya que las variables de entorno no son el enfoque más seguro. Para las pruebas de desarrollo local, se recomienda la herramienta Secret Manager para proteger los datos confidenciales. Para obtener más información, consulte Mantener de forma segura los datos confidenciales y las credenciales.
Para las pruebas de desarrollo local, use la herramienta Secret Manager para almacenar el secreto del cliente del proyecto de servidor bajo la clave de configuración Blazor.
El Blazor proyecto de servidor no se ha inicializado para la herramienta Administrador de secretos. Use un shell de comandos, como el shell de comandos de PowerShell para desarrolladores en Visual Studio, para ejecutar el comando siguiente. Antes de ejecutar el comando, cambie el directorio con el cd
comando al directorio del proyecto de servidor. El comando establece un identificador de secretos de usuario (<UserSecretsId>
en el archivo de proyecto de la aplicación de servidor):
dotnet user-secrets init
Ejecute el siguiente comando para establecer el secreto de cliente. El marcador de posición {SECRET}
es el secreto de cliente obtenido del registro de la aplicación:
dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"
Si usa Visual Studio, puede confirmar que el secreto está establecido haciendo clic con el botón derecho en el proyecto de servidor en Explorador de soluciones y seleccionando Administrar secretos de usuario.
MinimalApiJwt
proyecto
El proyecto MinimalApiJwt
es una API web de back-end para varios proyectos de front-end. El proyecto configura un punto de conexión de API mínima para datos meteorológicos.
El archivo MinimalApiJwt.http
se puede usar para probar la solicitud de datos meteorológicos. Ten en cuenta que el proyecto MinimalApiJwt
debe ejecutarse para probar el punto de conexión y el punto de conexión está codificado de forma dura en el archivo. Para obtener más información, consulta Usar archivos .http en Visual Studio 2022.
El proyecto incluye paquetes y configuración para generar documentos openAPI y la interfaz de usuario de Swagger en el entorno de desarrollo. Para obtener más información, consulte Uso de los documentos openAPI generados.
El proyecto crea un punto de conexión de API mínimo para los datos meteorológicos:
app.MapGet("/weather-forecast", () =>
{
var forecast = Enumerable.Range(1, 5).Select(index =>
new WeatherForecast
(
DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
Random.Shared.Next(-20, 55),
summaries[Random.Shared.Next(summaries.Length)]
))
.ToArray();
return forecast;
}).RequireAuthorization();
Configure el proyecto en JwtBearerOptions de la llamada AddJwtBearer en el archivo del proyecto Program
.
Authority establece la autoridad para realizar llamadas OIDC. Se recomienda usar un registro de aplicación independiente para el MinimalApiJwt
proyecto. La autoridad coincide con el emisor (iss
) del JWT devuelto por el proveedor de identidades.
jwtOptions.Authority = "{AUTHORITY}";
El formato de la autoridad depende del tipo de arrendatario usado. En los ejemplos siguientes para Microsoft Entra ID se usa un ID de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
.
ejemplo de autoridad del inquilino de ME-ID
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
Ejemplo de autoridad de arrendatario de Azure AD B2C:
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
Audience establece la audiencia para cualquier token de OIDC recibido.
jwtOptions.Audience = "{APP ID URI}";
Nota:
Cuando utilice Microsoft Entra ID, haga coincidir el valor con la ruta de la URI de ID de aplicación configurada al añadir el ámbito Weather.Get
en Exponer una API en o Entra Azure Portal. No incluya el nombre del ámbito, "Weather.Get
", en el valor .
El formato del tipo de público depende del tipo de arrendatario utilizado. En los ejemplos siguientes de Id. de Entra de Microsoft se usa un identificador de inquilino de contoso
y un identificador de cliente de 11112222-bbbb-3333-cccc-4444dddd5555
.
Ejemplo de URI de ID de aplicación de arrendatario ME-ID
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Ejemplo de URI de id. de aplicación de inquilino de AAD B2C:
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Blazor Web App proyecto de servidor (BlazorWebAppOidc
)
El proyecto BlazorWebAppOidc
es el proyecto del lado servidor de la Blazor Web App.
A DelegatingHandler (TokenHandler
) gestiona la asignación del token de acceso de usuario a las solicitudes salientes. El controlador de tokens solo se ejecuta durante la representación estática del lado servidor (SSR estático), por lo que el uso HttpContext es seguro en este escenario. Para obtener más información, consulte IHttpContextAccessor/HttpContext en aplicaciones ASP.NET Core Blazor y escenarios de seguridad adicionales y del lado servidor en ASP.NET CoreBlazor Web App.
TokenHandler.cs
:
public class TokenHandler(IHttpContextAccessor httpContextAccessor) :
DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
if (httpContextAccessor.HttpContext is null)
{
throw new Exception("HttpContext not available");
}
var accessToken = await httpContextAccessor.HttpContext
.GetTokenAsync("access_token");
request.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", accessToken);
return await base.SendAsync(request, cancellationToken);
}
}
En el archivo de proyecto Program
, el controlador de tokens (TokenHandler
) se registra como servicio y se especifica como controlador de mensajes con AddHttpMessageHandler para realizar solicitudes seguras a la API web backend MinimalApiJwt
mediante un cliente HTTP nombrado () "ExternalApi
".
builder.Services.AddScoped<TokenHandler>();
builder.Services.AddHttpClient("ExternalApi",
client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ??
throw new Exception("Missing base address!")))
.AddHttpMessageHandler<TokenHandler>();
En el archivo del proyecto, configure el URI de la API externa: appsettings.json
"ExternalApiUri": "{BASE ADDRESS}"
Ejemplo:
"ExternalApiUri": "https://localhost:7277"
La siguiente configuración OpenIdConnectOptions se encuentra en el archivo del proyecto Program
en la llamada a AddOpenIdConnect:
PushedAuthorizationBehavior: controla la compatibilidad con solicitudes de autorización push (PAR). De forma predeterminada, la configuración es usar PAR si el documento de detección del proveedor de identidades (normalmente se encuentra en .well-known/openid-configuration
) anuncia la compatibilidad con PAR. Si desea requerir compatibilidad con PAR para la aplicación, puede asignar un valor de PushedAuthorizationBehavior.Require
. PAR no es compatible con Microsoft Entra y no hay ningún plan para que Entra lo admita en el futuro.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme: establece el esquema de autenticación correspondiente al middleware responsable de conservar la identidad del usuario después de una autenticación correcta. El controlador OIDC debe usar un esquema de inicio de sesión que sea capaz de conservar las credenciales de usuario entre las solicitudes. La siguiente línea se presenta simplemente con fines de demostración. Si se omite, DefaultSignInScheme se usa como valor de reserva.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Ámbitos para openid
y profile
(Scope) (opcional): los ámbitos openid
y profile
también se configuran de forma predeterminada porque son necesarios para que el controlador OIDC funcione, pero es posible que deban volver a agregarse si los ámbitos se incluyen en la configuración de Authentication:Schemes:MicrosoftOidc:Scope
. Para obtener instrucciones generales de configuración, consulta Configuración en ASP.NET Core y Configuración de Blazor de ASP.NET Core.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
SaveTokens: define si los tokens de acceso y actualización deben almacenarse en AuthenticationProperties después de una autorización correcta. Esta propiedad se establece en true
, por lo que el token de actualización se almacena para la actualización de tokens no interactiva.
oidcOptions.SaveTokens = true;
Ámbito para el acceso sin conexión (Scope): el ámbito offline_access
es necesario para el token de actualización.
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
Authority y ClientId: establece la autoridad y el id. de cliente para las llamadas de OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
En el ejemplo siguiente se usa un identificador de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
y un identificador de cliente de 00001111-aaaa-2222-bbbb-3333cccc4444
:
oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
En el caso de las aplicaciones multitenant, se debe usar la autoridad "común". También puedes usar la autoridad "común" para las aplicaciones de un único inquilino, pero se requiere un IssuerValidator personalizado, como se muestra más adelante en esta sección.
oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
ResponseType: configura el controlador OIDC para que solo realice el flujo de código de autorización. Las concesiones implícitas y los flujos híbridos no son necesarios en este modo. El controlador OIDC solicita automáticamente los tokens adecuados mediante el código que devuelve el punto de conexión de autorización.
oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
MapInboundClaims y configuración de NameClaimType y RoleClaimType: muchos servidores OIDC usan "name
" y "role
" en lugar de los valores predeterminados de SOAP/WS-Fed en ClaimTypes. Cuando MapInboundClaims se establece en false
, el controlador no realiza asignaciones de notificaciones y la aplicación usa directamente los nombres de notificación del JWT. En el ejemplo siguiente, se establece el tipo de notificación de rol en "roles
", que es adecuado para Microsoft Entra ID (ME-ID). Para obtener más información, consulte la documentación del proveedor de identidades.
Nota:
MapInboundClaims debe establecerse en false
para la mayoría de los proveedores de OIDC, lo que impide renombrar declaraciones.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuración de rutas: las rutas deben coincidir con las del URI de redirección (ruta de callback de inicio de sesión) y con las de redirección después de cerrar sesión (ruta de callback de cierre de sesión) configuradas al registrar la aplicación con el proveedor OIDC. En Azure Portal, las rutas se configuran en la hoja Autenticación del registro de la aplicación. Las rutas de inicio de sesión y cierre de sesión deben registrarse como URI de redirección. Los valores predeterminados son /signin-oidc
y /signout-callback-oidc
.
CallbackPath: La ruta de solicitud dentro de la ruta base de la aplicación donde se devuelve el agente de usuario.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signin-oidc
Nota:
No se requiere un puerto para las direcciones localhost
cuando se usa Microsoft Entra ID. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
SignedOutCallbackPath (clave de configuración: "SignedOutCallbackPath
"): La ruta de solicitud dentro de la ruta base de la aplicación interceptada por el controlador OIDC donde el agente de usuario es devuelto por primera vez después de cerrar sesión desde el proveedor de identidad. La aplicación de ejemplo no establece un valor para la ruta de acceso porque se usa el valor predeterminado de "/signout-callback-oidc
". Después de interceptar la solicitud, el controlador de OIDC redirige al SignedOutRedirectUri o RedirectUri, si se especifica.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signout-callback-oidc
Nota:
Cuando utilice Microsoft Entra ID, establezca la ruta en las entradas Redirect URI de la configuración de la plataforma web en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto. Si no se agrega el URI de la ruta de retorno de llamada de salida al registro de la aplicación en Entra, Entra se niega a redirigir al usuario de vuelta a la aplicación y simplemente le pide que cierre la ventana de su navegador.
RemoteSignOutPath: las solicitudes recibidas en esta ruta hacen que el controlador invoque el cierre de sesión mediante el esquema de cierre de sesión.
En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost/signout-oidc
Nota:
Cuando utilice Microsoft Entra ID, configure la URL de cierre de sesión del canal frontal en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
oidcOptions.CallbackPath = new PathString("{PATH}");
oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
Ejemplos (valores predeterminados):
oidcOptions.CallbackPath = new PathString("/signin-oidc");
oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
(Microsoft Azure solo con el punto de conexión "común") TokenValidationParameters.IssuerValidator: Muchos proveedores de OIDC funcionan con el Validador de Emisor predeterminado, pero es necesario tener en cuenta el Emisor parametrizado con el ID de inquilino ({TENANT ID}
) devuelto por https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
. Para obtener más información, consulta SecurityTokenInvalidIssuerException con OpenID Connect y el punto de conexión "común" de Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
#1731).
Solo para las aplicaciones que usan Microsoft Entra ID o Azure AD B2C con el punto de conexión "común":
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Blazor Web App proyecto cliente (BlazorWebAppOidc.Client
)
El proyecto BlazorWebAppOidc.Client
es el proyecto del lado cliente de Blazor Web App.
El cliente llama AddAuthenticationStateDeserialization para deserializar y usar el estado de autenticación pasado por el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
La clase PersistentAuthenticationStateProvider
(PersistentAuthenticationStateProvider.cs
) es un AuthenticationStateProvider del lado cliente que determina el estado de autenticación del usuario buscando datos guardados en la página cuando se representa en el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
Si el usuario necesita iniciar sesión o cerrar sesión, se requiere una recarga de página completa.
La aplicación de ejemplo solo proporciona un nombre de usuario y un correo electrónico con fines de demostración.
Para Microsoft Entra ID o Azure AD B2C, puede utilizar AddMicrosoftIdentityWebApp de Microsoft Identity Web (Microsoft.Identity.Web
Paquete NuGet, Documentación API), que añade tanto el OIDC como el Cookie con los valores predeterminados adecuados. La aplicación de ejemplo y las instrucciones de este artículo no usan Microsoft Identity Web. En la guía se muestra cómo configurar el controlador OIDC manualmente para cualquier proveedor de OIDC. Para obtener más información sobre la implementación de Microsoft Identity Web, consulte la sección Proteja un ASP.NET Core Blazor Web App con Microsoft Entra ID.
En esta versión del artículo se describe la implementación de OIDC sin adoptar el Backend for Frontend (BFF) pattern con una aplicación que adopta la representación de servidor interactiva global (un único proyecto). El patrón BFF es útil para realizar solicitudes autenticadas a servicios externos. Cambie el selector de versión del artículo a BFF patrón si la especificación de la aplicación requiere la adopción del patrón BFF con renderizado interactivo automático global.
Se adopta la especificación siguiente:
- La Blazor Web App usa el modo de representación del servidor con interactividad global.
- Esta aplicación es un punto de partida para cualquier flujo de autenticación de OIDC. OIDC se configura manualmente en la aplicación y no se basa en los paquetes Microsoft Entra ID ni Microsoft Identity Web, y la aplicación de ejemplo tampoco requiere el hospedaje de Microsoft Azure. Sin embargo, la aplicación de ejemplo puede usarse con Entra y Microsoft Identity Web, y hospedarse en Azure.
- Actualización automática del token sin interacción.
- Un proyecto de API web independiente muestra una llamada de API web segura para los datos meteorológicos.
Para una experiencia alternativa utilizando Microsoft Authentication Library for .NET, Microsoft Identity Web y Microsoft Entra ID, consulte Proteger un núcleo ASP.NET Blazor Web App con Microsoft Entra ID.
Solución de ejemplo
La aplicación de ejemplo consta de los siguientes proyectos:
-
BlazorWebAppOidcServer
: Blazor Web App proyecto del lado servidor (representación global del servidor interactivo). -
MinimalApiJwt
: API web de back-end con un endpoint Minimal API para datos meteorológicos.
Acceda al ejemplo a través de la carpeta de versión más reciente del repositorio de ejemplos de Blazor con el vínculo siguiente. El ejemplo se encuentra en la carpeta BlazorWebAppOidcServer
para .NET 8 o posterior.
Vea o descargue el código de ejemplo (cómo descargarlo)
Registros de aplicaciones de identificación de Microsoft Entra
Se recomienda usar registros independientes para aplicaciones y API web, incluso cuando las aplicaciones y las API web están en la misma solución. Las instrucciones siguientes son para la aplicación BlazorWebAppOidcServer
y MinimalApiJwt
API web de la solución de ejemplo, pero las mismas instrucciones se aplican generalmente a los registros basados en Entra para aplicaciones y API web.
Registre primero la API web (MinimalApiJwt
) para que pueda conceder acceso a la API web al registrar la aplicación. El identificador de inquilino y el identificador de cliente de la API web se usan para configurar la API web en su Program
archivo. Después de registrar la API web, exponga la API web en Registros> de aplicacionesExponga una API con un nombre de ámbito de Weather.Get
. Registre el URI del identificador de aplicación para usarlo en la configuración de la aplicación.
A continuación, registre la aplicación (BlazorWebAppOidcServer
) con una configuración de plataforma web y un URI de redirección de https://localhost/signin-oidc
(no se requiere un puerto). El identificador de inquilino y el identificador de cliente de la aplicación, junto con la dirección base de la API web, el URI del identificador de aplicación y el nombre del ámbito meteorológico, se usan para configurar la aplicación en su Program
archivo. Conceda permiso de API para acceder a la API web en registros de aplicaciones>permisos de API. Si la especificación de seguridad de la aplicación lo requiere, puede conceder el consentimiento del administrador para que la organización acceda a la API de la web. Los usuarios y grupos autorizados están asignados al registro de la aplicación en Registros de aplicaciones>Aplicaciones empresariales.
En la configuración de registro de aplicaciones de flujos híbridos y concesión implícita de Entra o Azure Portal, no active ninguna casilla para que el punto de conexión de autorización devuelva tokens de acceso o tokens de identificador. El controlador de OpenID Connect solicita automáticamente los tokens adecuados mediante el código devuelto desde el punto de conexión de autorización.
Cree un secreto de cliente en el registro de la aplicación en Entra o Azure Portal (Administrar>certificados y secretos>Nuevo secreto de cliente). Mantenga presionado el valor del secreto de cliente para usar la sección siguiente.
Más adelante en este artículo se proporcionan instrucciones de configuración de Entra adicionales para configuraciones específicas.
Establecimiento del secreto de cliente
Esta sección solo se aplica al proyecto de servidor de Blazor Web App (BlazorWebAppOidcServer
project).
Advertencia
No almacene secretos de aplicación, cadena de conexión s, credenciales, contraseñas, números de identificación personal (PIN), código C#/.NET privado o claves o tokens privados en el código del lado cliente, lo que siempre es inseguro. En entornos de prueba/ensayo y producción, el código del lado Blazor servidor y las API web deben usar flujos de autenticación seguros que eviten mantener las credenciales dentro del código del proyecto o los archivos de configuración. Fuera de las pruebas de desarrollo local, se recomienda evitar el uso de variables de entorno para almacenar datos confidenciales, ya que las variables de entorno no son el enfoque más seguro. Para las pruebas de desarrollo local, se recomienda la herramienta Secret Manager para proteger los datos confidenciales. Para obtener más información, consulte Mantener de forma segura los datos confidenciales y las credenciales.
Para las pruebas de desarrollo local, use la herramienta Secret Manager para almacenar el secreto del cliente del proyecto de servidor bajo la clave de configuración Blazor.
El Blazor proyecto de servidor no se ha inicializado para la herramienta Administrador de secretos. Use un shell de comandos, como el shell de comandos de PowerShell para desarrolladores en Visual Studio, para ejecutar el comando siguiente. Antes de ejecutar el comando, cambie el directorio con el cd
comando al directorio del proyecto de servidor. El comando establece un identificador de secretos de usuario (<UserSecretsId>
en el archivo de proyecto de la aplicación):
dotnet user-secrets init
Ejecute el siguiente comando para establecer el secreto de cliente. El marcador de posición {SECRET}
es el secreto de cliente obtenido del registro de la aplicación:
dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"
Si usa Visual Studio, puede confirmar que el secreto se establece haciendo clic con el botón derecho en el proyecto en Explorador de soluciones y seleccionando Administrar secretos de usuario.
MinimalApiJwt
proyecto
El proyecto MinimalApiJwt
es una API web de back-end para varios proyectos de front-end. El proyecto configura un punto de conexión de API mínima para datos meteorológicos.
El archivo MinimalApiJwt.http
se puede usar para probar la solicitud de datos meteorológicos. Ten en cuenta que el proyecto MinimalApiJwt
debe ejecutarse para probar el punto de conexión y el punto de conexión está codificado de forma dura en el archivo. Para obtener más información, consulta Usar archivos .http en Visual Studio 2022.
El proyecto incluye paquetes y configuración para generar documentos openAPI y la interfaz de usuario de Swagger en el entorno de desarrollo. Para obtener más información, consulte Uso de los documentos openAPI generados.
El proyecto crea un punto de conexión de API mínimo para los datos meteorológicos:
app.MapGet("/weather-forecast", () =>
{
var forecast = Enumerable.Range(1, 5).Select(index =>
new WeatherForecast
(
DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
Random.Shared.Next(-20, 55),
summaries[Random.Shared.Next(summaries.Length)]
))
.ToArray();
return forecast;
}).RequireAuthorization();
Configure el proyecto en JwtBearerOptions de la llamada AddJwtBearer en el archivo del proyecto Program
.
Authority establece la autoridad para realizar llamadas OIDC. Se recomienda usar un registro de aplicación independiente para el MinimalApiJwt
proyecto. La autoridad coincide con el emisor (iss
) del JWT devuelto por el proveedor de identidades.
jwtOptions.Authority = "{AUTHORITY}";
El formato de la autoridad depende del tipo de arrendatario usado. En los ejemplos siguientes para Microsoft Entra ID se usa un ID de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
.
ejemplo de autoridad del inquilino de ME-ID
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
Ejemplo de autoridad de arrendatario de Azure AD B2C:
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
Audience establece la audiencia para cualquier token de OIDC recibido.
jwtOptions.Audience = "{APP ID URI}";
Nota:
Cuando utilice Microsoft Entra ID, haga coincidir el valor con la ruta de la URI de ID de aplicación configurada al añadir el ámbito Weather.Get
en Exponer una API en o Entra Azure Portal. No incluya el nombre del ámbito, "Weather.Get
", en el valor .
El formato del tipo de público depende del tipo de arrendatario utilizado. En los ejemplos siguientes de Id. de Entra de Microsoft se usa un identificador de inquilino de contoso
y un identificador de cliente de 11112222-bbbb-3333-cccc-4444dddd5555
.
Ejemplo de URI de ID de aplicación de arrendatario ME-ID
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Ejemplo de URI de id. de aplicación de inquilino de AAD B2C:
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
BlazorWebAppOidcServer
proyecto
La actualización automática no interactiva de tokens se gestiona mediante un actualizador personalizado cookie (CookieOidcRefresher.cs
).
A DelegatingHandler (TokenHandler
) gestiona la asignación del token de acceso de usuario a las solicitudes salientes. El controlador de tokens solo se ejecuta durante la representación estática del lado servidor (SSR estático), por lo que el uso HttpContext es seguro en este escenario. Para obtener más información, consulte IHttpContextAccessor/HttpContext en aplicaciones ASP.NET Core Blazor y escenarios de seguridad adicionales y del lado servidor en ASP.NET CoreBlazor Web App.
TokenHandler.cs
:
public class TokenHandler(IHttpContextAccessor httpContextAccessor) :
DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
if (httpContextAccessor.HttpContext is null)
{
throw new Exception("HttpContext not available");
}
var accessToken = await httpContextAccessor.HttpContext
.GetTokenAsync("access_token");
request.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", accessToken);
return await base.SendAsync(request, cancellationToken);
}
}
En el archivo de proyecto Program
, el controlador de tokens (TokenHandler
) se registra como servicio y se especifica como controlador de mensajes con AddHttpMessageHandler para realizar solicitudes seguras a la API web backend MinimalApiJwt
mediante un cliente HTTP nombrado () "ExternalApi
".
builder.Services.AddScoped<TokenHandler>();
builder.Services.AddHttpClient("ExternalApi",
client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ??
throw new Exception("Missing base address!")))
.AddHttpMessageHandler<TokenHandler>();
El componente Weather
usa el atributo [Authorize]
para evitar el acceso no autorizado. Para obtener más información sobre cómo requerir autorización en la aplicación a través de una directiva de autorización y excluir la autorización en un subconjunto de puntos de conexión públicos, consulte la guía de OIDC de Razor Pages.
El ExternalApi
cliente HTTP se usa para realizar una solicitud de datos meteorológicos a la API web segura. En el OnInitializedAsync
evento de ciclo de vida de Weather.razor
:
using var request = new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
var client = ClientFactory.CreateClient("ExternalApi");
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
forecasts = await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
throw new IOException("No weather forecast!");
En el archivo del proyecto, configure el URI de la API externa: appsettings.json
"ExternalApiUri": "{BASE ADDRESS}"
Ejemplo:
"ExternalApiUri": "https://localhost:7277"
La siguiente configuración OpenIdConnectOptions se encuentra en el archivo del proyecto Program
en la llamada a AddOpenIdConnect:
PushedAuthorizationBehavior: controla la compatibilidad con solicitudes de autorización push (PAR). De forma predeterminada, la configuración es usar PAR si el documento de detección del proveedor de identidades (normalmente se encuentra en .well-known/openid-configuration
) anuncia la compatibilidad con PAR. Si desea requerir compatibilidad con PAR para la aplicación, puede asignar un valor de PushedAuthorizationBehavior.Require
. PAR no es compatible con Microsoft Entra y no hay ningún plan para que Entra lo admita en el futuro.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme: establece el esquema de autenticación correspondiente al middleware responsable de conservar la identidad del usuario después de una autenticación correcta. El controlador OIDC debe usar un esquema de inicio de sesión que sea capaz de conservar las credenciales de usuario entre las solicitudes. La siguiente línea se presenta simplemente con fines de demostración. Si se omite, DefaultSignInScheme se usa como valor de reserva.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Ámbitos para openid
y profile
(Scope) (opcional): los ámbitos openid
y profile
también se configuran de forma predeterminada porque son necesarios para que el controlador OIDC funcione, pero es posible que deban volver a agregarse si los ámbitos se incluyen en la configuración de Authentication:Schemes:MicrosoftOidc:Scope
. Para obtener instrucciones generales de configuración, consulta Configuración en ASP.NET Core y Configuración de Blazor de ASP.NET Core.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
Configura el Weather.Get
ámbito para acceder a la API web externa destinada a obtener datos meteorológicos. El ejemplo siguiente se basa en el uso de Entra ID en un dominio de inquilino de ME-ID. En el siguiente ejemplo, el marcador de posición {APP ID URI}
se encuentra en Entra o en el portal de Azure donde se expone la API web. Para cualquier otro proveedor de identidades, use el ámbito adecuado.
oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");
El formato del alcance depende del tipo de inquilino en uso. En los ejemplos siguientes, el dominio de inquilino es contoso.onmicrosoft.com
y el identificador de cliente es 11112222-bbbb-3333-cccc-4444dddd5555
.
Ejemplo de URI de ID de aplicación de arrendatario ME-ID
oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Ejemplo de URI de id. de aplicación de inquilino de AAD B2C:
oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
SaveTokens: define si los tokens de acceso y actualización deben almacenarse en AuthenticationProperties después de una autorización correcta. Esta propiedad se establece en true
, por lo que el token de actualización se almacena para la actualización de tokens no interactiva.
oidcOptions.SaveTokens = true;
Ámbito para el acceso sin conexión (Scope): el ámbito offline_access
es necesario para el token de actualización.
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
Authority y ClientId: establece la autoridad y el id. de cliente para las llamadas de OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
En el ejemplo siguiente se usa un identificador de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
y un identificador de cliente de 00001111-aaaa-2222-bbbb-3333cccc4444
:
oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
En el caso de las aplicaciones multitenant, se debe usar la autoridad "común". También puedes usar la autoridad "común" para las aplicaciones de un único inquilino, pero se requiere un IssuerValidator personalizado, como se muestra más adelante en esta sección.
oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
ResponseType: configura el controlador OIDC para que solo realice el flujo de código de autorización. Las concesiones implícitas y los flujos híbridos no son necesarios en este modo. El controlador OIDC solicita automáticamente los tokens adecuados mediante el código que devuelve el punto de conexión de autorización.
oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
MapInboundClaims y configuración de NameClaimType y RoleClaimType: muchos servidores OIDC usan "name
" y "role
" en lugar de los valores predeterminados de SOAP/WS-Fed en ClaimTypes. Cuando MapInboundClaims se establece en false
, el controlador no realiza asignaciones de notificaciones y la aplicación usa directamente los nombres de notificación del JWT. En el ejemplo siguiente, se establece el tipo de notificación de rol en "roles
", que es adecuado para Microsoft Entra ID (ME-ID). Para obtener más información, consulte la documentación del proveedor de identidades.
Nota:
MapInboundClaims debe establecerse en false
para la mayoría de los proveedores de OIDC, lo que impide renombrar declaraciones.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuración de rutas: las rutas deben coincidir con las del URI de redirección (ruta de callback de inicio de sesión) y con las de redirección después de cerrar sesión (ruta de callback de cierre de sesión) configuradas al registrar la aplicación con el proveedor OIDC. En Azure Portal, las rutas se configuran en la hoja Autenticación del registro de la aplicación. Las rutas de inicio de sesión y cierre de sesión deben registrarse como URI de redirección. Los valores predeterminados son /signin-oidc
y /signout-callback-oidc
.
CallbackPath: La ruta de solicitud dentro de la ruta base de la aplicación donde se devuelve el agente de usuario.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signin-oidc
Nota:
No se requiere un puerto para las direcciones localhost
cuando se usa Microsoft Entra ID. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
SignedOutCallbackPath (clave de configuración: "SignedOutCallbackPath
"): La ruta de solicitud dentro de la ruta base de la aplicación interceptada por el controlador OIDC donde el agente de usuario es devuelto por primera vez después de cerrar sesión desde el proveedor de identidad. La aplicación de ejemplo no establece un valor para la ruta de acceso porque se usa el valor predeterminado de "/signout-callback-oidc
". Después de interceptar la solicitud, el controlador de OIDC redirige al SignedOutRedirectUri o RedirectUri, si se especifica.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signout-callback-oidc
Nota:
Cuando utilice Microsoft Entra ID, establezca la ruta en las entradas Redirect URI de la configuración de la plataforma web en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto. Si no se agrega el URI de la ruta de retorno de llamada de salida al registro de la aplicación en Entra, Entra se niega a redirigir al usuario de vuelta a la aplicación y simplemente le pide que cierre la ventana de su navegador.
RemoteSignOutPath: las solicitudes recibidas en esta ruta hacen que el controlador invoque el cierre de sesión mediante el esquema de cierre de sesión.
En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost/signout-oidc
Nota:
Cuando utilice Microsoft Entra ID, configure la URL de cierre de sesión del canal frontal en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
oidcOptions.CallbackPath = new PathString("{PATH}");
oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
Ejemplos (valores predeterminados):
oidcOptions.CallbackPath = new PathString("/signin-oidc");
oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
(Microsoft Azure solo con el punto de conexión "común") TokenValidationParameters.IssuerValidator: Muchos proveedores de OIDC funcionan con el Validador de Emisor predeterminado, pero es necesario tener en cuenta el Emisor parametrizado con el ID de inquilino ({TENANT ID}
) devuelto por https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
. Para obtener más información, consulta SecurityTokenInvalidIssuerException con OpenID Connect y el punto de conexión "común" de Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
#1731).
Solo para las aplicaciones que usan Microsoft Entra ID o Azure AD B2C con el punto de conexión "común":
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Para Microsoft Entra ID o Azure AD B2C, puede utilizar AddMicrosoftIdentityWebApp de Microsoft Identity Web (Microsoft.Identity.Web
Paquete NuGet, Documentación API), que añade tanto el OIDC como el Cookie con los valores predeterminados adecuados. La aplicación de ejemplo y las instrucciones de este artículo no usan Microsoft Identity Web. En la guía se muestra cómo configurar el controlador OIDC manualmente para cualquier proveedor de OIDC. Para obtener más información sobre la implementación de Microsoft Identity Web, consulte la sección Proteja un ASP.NET Core Blazor Web App con Microsoft Entra ID.
En esta versión del artículo se describe la implementación de OIDC con el patrón BFF (Backend for Frontend). Si la especificación de la aplicación no requiere la adopción del patrón BFF, cambie el selector de versión del artículo a Patrón no BFF (Representación Automática Interactiva) o Patrón no BFF (Servidor Interactivo) (Representación de Servidor Interactivo).
Prerrequisitos
.NET Aspire requiere Visual Studio versión 17.10 o versión posterior.
Consulte también la sección Requisitos previos de Inicio rápido: Creación de la primera aplicación .NET Aspire.
Solución de ejemplo
La aplicación de ejemplo consta de los siguientes proyectos:
-
.NET Aspire:
-
Aspire.AppHost
: se usa para administrar los problemas de orquestación de alto nivel de la aplicación. -
Aspire.ServiceDefaults
: contiene configuraciones de aplicaciones .NET Aspire predeterminadas que se pueden ampliar y personalizar según sea necesario.
-
-
MinimalApiJwt
: API web de back-end, que contiene un punto de conexión de API mínima de ejemplo para los datos meteorológicos. -
BlazorWebAppOidc
: Proyecto del lado del servidor de la clase Blazor Web App. El proyecto usa YARP para redirigir mediante proxy las solicitudes a un punto de conexión de previsión meteorológica en el proyecto de API web de back-end (MinimalApiJwt
) conaccess_token
almacenado en la cookie de autenticación. -
BlazorWebAppOidc.Client
: proyecto del lado cliente de la Blazor Web App.
Acceda al ejemplo a través de la carpeta de versión más reciente del repositorio de ejemplos de Blazor con el vínculo siguiente. El ejemplo se encuentra en la carpeta BlazorWebAppOidcBff
para .NET 8 o posterior.
Vea o descargue el código de ejemplo (cómo descargarlo)
La Blazor Web App utiliza el modo de renderizado automático con interactividad global.
El proyecto de servidor llama a AddAuthenticationStateSerialization para agregar un proveedor de estado de autenticación del lado del servidor que usa PersistentComponentState para transmitir el estado de autenticación al cliente. El cliente llama AddAuthenticationStateDeserialization para deserializar y usar el estado de autenticación pasado por el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
La clase PersistingAuthenticationStateProvider
(PersistingAuthenticationStateProvider.cs
) es un AuthenticationStateProvider del lado servidor que usa PersistentComponentState para hacer fluir el estado de autenticación, que posteriormente es fijo durante la vigencia de la aplicación WebAssembly, al cliente.
Esta aplicación es un punto de partida para cualquier flujo de autenticación de OIDC. OIDC se configura manualmente en la aplicación y no se basa en los paquetes Microsoft Entra ID ni Microsoft Identity Web, y la aplicación de ejemplo tampoco requiere el hospedaje de Microsoft Azure. Sin embargo, la aplicación de ejemplo puede usarse con Entra y Microsoft Identity Web, y hospedarse en Azure.
Actualización automática de tokens no interactivos con la ayuda de un actualizador personalizado cookie (CookieOidcRefresher.cs
).
El patrón Backend for Frontend (BFF) se utiliza utilizando .NET Aspire para la detección de servicios y YARP para proxiar solicitudes a un endpoint meteorológico en la aplicación backend.
La API web de back-end (MinimalApiJwt
) usa la autenticación de portador JWT para validar los tokens JWT guardados por Blazor Web App en el inicio de sesión cookie.
Aspire mejora la experiencia de creación de aplicaciones nativas de nube .NET. Proporciona un conjunto coherente y fundamentado de herramientas y patrones para compilar y ejecutar aplicaciones distribuidas.
YARP es una biblioteca que se usa para crear un servidor proxy inverso.
MapForwarder
en el Program
archivo del proyecto de servidor agrega reenvío directo de solicitudes HTTP que coinciden con el patrón especificado a un destino específico mediante la configuración predeterminada para la solicitud saliente, las transformaciones personalizadas y el cliente HTTP predeterminado:
- Al representar el componente
Weather
en el servidor, el componente usa la claseServerWeatherForecaster
para redirigir mediante proxy la solicitud de datos meteorológicos con el token de acceso del usuario. IHttpContextAccessor.HttpContext determina si un HttpContext está disponible para su uso por el métodoGetWeatherForecastAsync
. Para más información, vea Componentes Razor de ASP.NET Core. - Cuando el componente se representa en el cliente, usa la implementación del servicio
ClientWeatherForecaster
, que usa un HttpClient preconfigurado (en el archivoProgram
del proyecto de cliente) para realizar una llamada API web al proyecto de servidor. Un punto de conexión de API mínimo (/weather-forecast
) definido en el archivoProgram
del proyecto de servidor transforma la solicitud con el token de acceso del usuario para obtener los datos meteorológicos.
Para obtener más información sobre .NET Aspire, consulta Disponibilidad general de .NET Aspire: simplificación del desarrollo nativo de nube de .NET (mayo de 2024).
Para obtener más información sobre las llamadas API (web) mediante abstracciones de servicio en Blazor Web App, consulta Llamada a una API web desde una aplicación Blazor de ASP.NET Core.
Registros de aplicaciones de identificación de Microsoft Entra
Se recomienda usar registros independientes para aplicaciones y API web, incluso cuando las aplicaciones y las API web están en la misma solución. Las instrucciones siguientes son para la aplicación BlazorWebAppOidc
y MinimalApiJwt
API web de la solución de ejemplo, pero las mismas instrucciones se aplican generalmente a los registros basados en Entra para aplicaciones y API web.
Registre primero la API web (MinimalApiJwt
) para que pueda conceder acceso a la API web al registrar la aplicación. El identificador de inquilino y el identificador de cliente de la API web se usan para configurar la API web en su Program
archivo. Después de registrar la API web, exponga la API web en Registros> de aplicacionesExponga una API con un nombre de ámbito de Weather.Get
. Registre el URI del identificador de aplicación para usarlo en la configuración de la aplicación.
A continuación, registre la aplicación (BlazorWebAppOidc
/BlazorWebApOidc.Client
) con una configuración de plataforma web y un URI de redirección de https://localhost/signin-oidc
(no se requiere un puerto). El identificador de inquilino y el identificador de cliente de la aplicación, junto con la dirección base de la API web, el URI del identificador de aplicación y el nombre del ámbito meteorológico, se usan para configurar la aplicación en su Program
archivo. Conceda permiso de API para acceder a la API web en registros de aplicaciones>permisos de API. Si la especificación de seguridad de la aplicación lo requiere, puede conceder el consentimiento del administrador para que la organización acceda a la API de la web. Los usuarios y grupos autorizados están asignados al registro de la aplicación en Registros de aplicaciones>Aplicaciones empresariales.
En la configuración de registro de aplicaciones de flujos híbridos y concesión implícita de Entra o Azure Portal, no active ninguna casilla para que el punto de conexión de autorización devuelva tokens de acceso o tokens de identificador. El controlador de OpenID Connect solicita automáticamente los tokens adecuados mediante el código devuelto desde el punto de conexión de autorización.
Cree un secreto de cliente en el registro de la aplicación en Entra o Azure Portal (Administrar>certificados y secretos>Nuevo secreto de cliente). Mantenga presionado el valor del secreto de cliente para usar la sección siguiente.
Más adelante en este artículo se proporcionan instrucciones de configuración de Entra adicionales para configuraciones específicas.
Establecimiento del secreto de cliente
Esta sección solo se aplica al proyecto de servidor de Blazor Web App (BlazorWebAppOidc
project).
Advertencia
No almacene secretos de aplicación, cadena de conexión s, credenciales, contraseñas, números de identificación personal (PIN), código C#/.NET privado o claves o tokens privados en el código del lado cliente, lo que siempre es inseguro. En entornos de prueba/ensayo y producción, el código del lado Blazor servidor y las API web deben usar flujos de autenticación seguros que eviten mantener las credenciales dentro del código del proyecto o los archivos de configuración. Fuera de las pruebas de desarrollo local, se recomienda evitar el uso de variables de entorno para almacenar datos confidenciales, ya que las variables de entorno no son el enfoque más seguro. Para las pruebas de desarrollo local, se recomienda la herramienta Secret Manager para proteger los datos confidenciales. Para obtener más información, consulte Mantener de forma segura los datos confidenciales y las credenciales.
Para las pruebas de desarrollo local, use la herramienta Secret Manager para almacenar el secreto del cliente del proyecto de servidor bajo la clave de configuración Blazor.
El Blazor proyecto de servidor no se ha inicializado para la herramienta Administrador de secretos. Use un shell de comandos, como el shell de comandos de PowerShell para desarrolladores en Visual Studio, para ejecutar el comando siguiente. Antes de ejecutar el comando, cambie el directorio con el cd
comando al directorio del proyecto de servidor. El comando establece un identificador de secretos de usuario (<UserSecretsId>
en el archivo de proyecto de la aplicación de servidor):
dotnet user-secrets init
Ejecute el siguiente comando para establecer el secreto de cliente. El marcador de posición {SECRET}
es el secreto de cliente obtenido del registro de la aplicación:
dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"
Si usa Visual Studio, puede confirmar que el secreto está establecido haciendo clic con el botón derecho en el proyecto de servidor en Explorador de soluciones y seleccionando Administrar secretos de usuario.
Proyectos .NET Aspire
Para obtener más información sobre el uso de .NET Aspire y detalles sobre los proyectos .AppHost
y .ServiceDefaults
de la aplicación de ejemplo, consulta la documentación de .NET Aspire.
Confirma que cumples los requisitos previos para .NET Aspire. Para obtener más información, consulta la sección Requisitos previos de Inicio rápido: Compilación de la primera aplicación .NET Aspire.
La aplicación de muestra solo configura un perfil de inicio HTTP no seguro (http
) para usarlo durante las pruebas de desarrollo. Para obtener más información, incluido un ejemplo de perfiles de configuración de inicio inseguros y seguros, consulte Permitir el transporte no seguro en .NET Aspire (.NET Aspire documentación).
MinimalApiJwt
proyecto
El proyecto MinimalApiJwt
es una API web de back-end para varios proyectos de front-end. El proyecto configura un punto de conexión de API mínima para datos meteorológicos. Las solicitudes del proyecto del lado del servidor Blazor Web App (BlazorWebAppOidc
) se redirigen mediante proxy al proyecto MinimalApiJwt
.
El archivo MinimalApiJwt.http
se puede usar para probar la solicitud de datos meteorológicos. Ten en cuenta que el proyecto MinimalApiJwt
debe ejecutarse para probar el punto de conexión y el punto de conexión está codificado de forma dura en el archivo. Para obtener más información, consulta Usar archivos .http en Visual Studio 2022.
El proyecto incluye paquetes y configuración para generar documentos openAPI y la interfaz de usuario de Swagger en el entorno de desarrollo. Para obtener más información, consulte Uso de los documentos openAPI generados.
Un punto de conexión de datos de previsión meteorológica seguro se encuentra en el archivo del Program
proyecto:
app.MapGet("/weather-forecast", () =>
{
var forecast = Enumerable.Range(1, 5).Select(index =>
new WeatherForecast
(
DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
Random.Shared.Next(-20, 55),
summaries[Random.Shared.Next(summaries.Length)]
))
.ToArray();
return forecast;
}).RequireAuthorization();
El método de extensión RequireAuthorization requiere autorización para la definición de ruta. Para los controladores que agregues al proyecto, agrega el atributo [Authorize]
al controlador o la acción.
Configure el proyecto en JwtBearerOptions de la llamada AddJwtBearer en el archivo del proyecto Program
.
Authority establece la autoridad para realizar llamadas OIDC. Se recomienda usar un registro de aplicación independiente para el MinimalApiJwt
proyecto. La autoridad coincide con el emisor (iss
) del JWT devuelto por el proveedor de identidades.
jwtOptions.Authority = "{AUTHORITY}";
El formato de la autoridad depende del tipo de arrendatario usado. En los ejemplos siguientes para Microsoft Entra ID se usa un ID de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
.
ejemplo de autoridad del inquilino de ME-ID
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
Ejemplo de autoridad de arrendatario de Azure AD B2C:
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
Audience establece la audiencia para cualquier token de OIDC recibido.
jwtOptions.Audience = "{APP ID URI}";
Nota:
Cuando utilice Microsoft Entra ID, haga coincidir el valor con la ruta de la URI de ID de aplicación configurada al añadir el ámbito Weather.Get
en Exponer una API en o Entra Azure Portal. No incluya el nombre del ámbito, "Weather.Get
", en el valor .
El formato del tipo de público depende del tipo de arrendatario utilizado. En los ejemplos siguientes de Id. de Entra de Microsoft se usa un identificador de inquilino de contoso
y un identificador de cliente de 11112222-bbbb-3333-cccc-4444dddd5555
.
Ejemplo de URI de ID de aplicación de arrendatario ME-ID
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Ejemplo de URI de id. de aplicación de inquilino de AAD B2C:
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Proyecto Blazor Web App del lado de servidor (BlazorWebAppOidc
)
En esta sección se explica cómo configurar el proyecto del lado Blazor servidor.
La siguiente OpenIdConnectOptions configuración se encuentra en el archivo del proyecto Program
durante la llamada a AddOpenIdConnect.
PushedAuthorizationBehavior: controla la compatibilidad con solicitudes de autorización push (PAR). De forma predeterminada, la configuración es usar PAR si el documento de detección del proveedor de identidades (normalmente se encuentra en .well-known/openid-configuration
) anuncia la compatibilidad con PAR. Si desea requerir compatibilidad con PAR para la aplicación, puede asignar un valor de PushedAuthorizationBehavior.Require
. PAR no es compatible con Microsoft Entra y no hay ningún plan para que Entra lo admita en el futuro.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme: establece el esquema de autenticación correspondiente al middleware responsable de conservar la identidad del usuario después de una autenticación correcta. El controlador OIDC debe usar un esquema de inicio de sesión que sea capaz de conservar las credenciales de usuario entre las solicitudes. La siguiente línea se presenta simplemente con fines de demostración. Si se omite, DefaultSignInScheme se usa como valor de reserva.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Ámbitos para openid
y profile
(Scope) (opcional): los ámbitos openid
y profile
también se configuran de forma predeterminada porque son necesarios para que el controlador OIDC funcione, pero es posible que deban volver a agregarse si los ámbitos se incluyen en la configuración de Authentication:Schemes:MicrosoftOidc:Scope
. Para obtener instrucciones generales de configuración, consulta Configuración en ASP.NET Core y Configuración de Blazor de ASP.NET Core.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
SaveTokens: define si los tokens de acceso y actualización deben almacenarse en AuthenticationProperties después de una autorización correcta. El valor se establece en true
para autenticar las solicitudes de datos meteorológicos del proyecto de API web de back-end (MinimalApiJwt
).
oidcOptions.SaveTokens = true;
Ámbito para el acceso sin conexión (Scope): el ámbito offline_access
es necesario para el token de actualización.
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
Ámbitos para obtener datos meteorológicos de la API web (Scope): configure el Weather.Get
ámbito para acceder a la API web externa para los datos meteorológicos. En el siguiente ejemplo, el marcador de posición {APP ID URI}
se encuentra en Entra o en el portal de Azure donde se expone la API web. Para cualquier otro proveedor de identidades, use el ámbito adecuado.
oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");
El formato del alcance depende del tipo de inquilino en uso. En los ejemplos siguientes, el dominio de inquilino es contoso.onmicrosoft.com
y el identificador de cliente es 11112222-bbbb-3333-cccc-4444dddd5555
.
Ejemplo de URI de ID de aplicación de arrendatario ME-ID
oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Ejemplo de URI de id. de aplicación de inquilino de AAD B2C:
oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Authority y ClientId: establece la autoridad y el id. de cliente para las llamadas de OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
En el ejemplo siguiente se usa un identificador de inquilino de aaaabbbb-0000-cccc-1111-dddd2222eeee
y un identificador de cliente de 00001111-aaaa-2222-bbbb-3333cccc4444
:
oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
En el caso de las aplicaciones multitenant, se debe usar la autoridad "común". También puedes usar la autoridad "común" para las aplicaciones de un único inquilino, pero se requiere un IssuerValidator personalizado, como se muestra más adelante en esta sección.
oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
ResponseType: configura el controlador OIDC para que solo realice el flujo de código de autorización. Las concesiones implícitas y los flujos híbridos no son necesarios en este modo. El controlador OIDC solicita automáticamente los tokens adecuados mediante el código que devuelve el punto de conexión de autorización.
oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
MapInboundClaims y configuración de NameClaimType y RoleClaimType: muchos servidores OIDC usan "name
" y "role
" en lugar de los valores predeterminados de SOAP/WS-Fed en ClaimTypes. Cuando MapInboundClaims se establece en false
, el controlador no realiza el mapeo de reclamaciones y la aplicación usa directamente los nombres de reclamaciones del JWT. En el ejemplo siguiente, se establece el tipo de notificación de rol en "roles
", que es adecuado para Microsoft Entra ID (ME-ID). Para obtener más información, consulte la documentación del proveedor de identidades.
Nota:
MapInboundClaims debe establecerse en false
para la mayoría de los proveedores de OIDC, lo que impide renombrar declaraciones.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuración de rutas: las rutas deben coincidir con las del URI de redirección (ruta de callback de inicio de sesión) y con las de redirección después de cerrar sesión (ruta de callback de cierre de sesión) configuradas al registrar la aplicación con el proveedor OIDC. En Azure Portal, las rutas se configuran en la hoja Autenticación del registro de la aplicación. Las rutas de inicio de sesión y cierre de sesión deben registrarse como URI de redirección. Los valores predeterminados son /signin-oidc
y /signout-callback-oidc
.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signin-oidc
Nota:
No se requiere un puerto para las direcciones localhost
cuando se usa Microsoft Entra ID. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
SignedOutCallbackPath (clave de configuración: "SignedOutCallbackPath
"): La ruta de solicitud dentro de la ruta base de la aplicación interceptada por el controlador OIDC donde el agente de usuario es devuelto por primera vez después de cerrar sesión desde el proveedor de identidad. La aplicación de ejemplo no establece un valor para la ruta de acceso porque se usa el valor predeterminado de "/signout-callback-oidc
". Después de interceptar la solicitud, el controlador de OIDC redirige al SignedOutRedirectUri o RedirectUri, si se especifica.
Configure la ruta de devolución de llamada de cierre de sesión en el registro del proveedor OIDC de la aplicación. En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost:{PORT}/signout-callback-oidc
Nota:
Cuando utilice Microsoft Entra ID, establezca la ruta en las entradas Redirect URI de la configuración de la plataforma web en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto. Si no se agrega el URI de la ruta de retorno de llamada de salida al registro de la aplicación en Entra, Entra se niega a redirigir al usuario de vuelta a la aplicación y simplemente le pide que cierre la ventana de su navegador.
RemoteSignOutPath: las solicitudes recibidas en esta ruta hacen que el controlador invoque el cierre de sesión mediante el esquema de cierre de sesión.
En el ejemplo siguiente, el marcador de posición {PORT}
es el puerto de la aplicación:
https://localhost/signout-oidc
Nota:
Cuando utilice Microsoft Entra ID, configure la URL de cierre de sesión del canal frontal en el portal Entra o Azure. No se requiere un puerto cuando se usa Entra para las direcciones localhost
. La mayoría de los demás proveedores de OIDC requieren el puerto correcto.
oidcOptions.CallbackPath = new PathString("{PATH}");
oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
Ejemplos (valores predeterminados):
oidcOptions.CallbackPath = new PathString("/signin-oidc");
oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
(Microsoft Azure solo con el punto de conexión "común") TokenValidationParameters.IssuerValidator: Muchos proveedores de OIDC funcionan con el Validador de Emisor predeterminado, pero es necesario tener en cuenta el Emisor parametrizado con el ID de inquilino ({TENANT ID}
) devuelto por https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
. Para obtener más información, consulta SecurityTokenInvalidIssuerException con OpenID Connect y el punto de conexión "común" de Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
#1731).
Solo para las aplicaciones que usan Microsoft Entra ID o Azure AD B2C con el punto de conexión "común":
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Proyecto Blazor Web App del lado del cliente (BlazorWebAppOidc.Client
)
El proyecto BlazorWebAppOidc.Client
es el proyecto del lado cliente de Blazor Web App.
El cliente llama AddAuthenticationStateDeserialization para deserializar y usar el estado de autenticación pasado por el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
La clase PersistentAuthenticationStateProvider
(PersistentAuthenticationStateProvider.cs
) es un AuthenticationStateProvider del lado cliente que determina el estado de autenticación del usuario buscando datos guardados en la página cuando se representa en el servidor. El estado de autenticación es fijo durante la vigencia de la aplicación WebAssembly.
Si el usuario necesita iniciar sesión o cerrar sesión, se requiere una recarga de página completa.
La aplicación de ejemplo solo proporciona un nombre de usuario y un correo electrónico con fines de demostración.
Serializar solo las reclamaciones de nombre y rol
Esta sección solo se aplica al patrón no BFF (Automático interactivo) y al patrón BFF (Automático interactivo) y a sus aplicaciones de ejemplo.
En el archivo Program
, todas las reclamaciones se serializan estableciendo SerializeAllClaims en true
. Si solo desea que el nombre y las reclamaciones de rol se serialicen para CSR, quite la opción o establézcala en false
.
Proporcione la configuración con el proveedor de configuración JSON (configuración de la aplicación)
Los proyectos de solución de ejemplo configuran la autenticación de portador de OIDC y JWT en sus Program
archivos correspondientes para que se puedan descubrir las opciones de configuración mediante el autocompletado de C#. Las aplicaciones profesionales suelen usar un proveedor de configuración para configurar las opciones de OIDC, como el proveedor de configuración JSON predeterminado. El proveedor de configuración JSON carga la configuración a partir de archivos appsettings.json
/appsettings.{ENVIRONMENT}.json
de la aplicación, donde el marcador de posición {ENVIRONMENT}
es el entorno en tiempo de ejecución de la aplicación. Siga las instrucciones de esta sección para usar los archivos de configuración de la aplicación para la configuración.
En el archivo de configuración de la aplicación (appsettings.json
) del BlazorWebAppOidc
proyecto o BlazorWebAppOidcServer
, agregue la siguiente configuración JSON:
"Authentication": {
"Schemes": {
"MicrosoftOidc": {
"Authority": "https://login.microsoftonline.com/{TENANT ID (BLAZOR APP)}/v2.0/",
"ClientId": "{CLIENT ID (BLAZOR APP)}",
"CallbackPath": "/signin-oidc",
"SignedOutCallbackPath": "/signout-callback-oidc",
"RemoteSignOutPath": "/signout-oidc",
"SignedOutRedirectUri": "/",
"Scope": [
"openid",
"profile",
"offline_access",
"{APP ID URI (WEB API)}/Weather.Get"
]
}
}
},
Actualice los marcadores de posición de la configuración anterior para que coincidan con los valores que usa la aplicación en el Program
archivo:
-
{TENANT ID (BLAZOR APP)}
: el identificador de inquilino de la Blazor aplicación. -
{CLIENT ID (BLAZOR APP)}
: identificador de cliente de la Blazor aplicación. -
{APP ID URI (WEB API)}
: el URI del identificador de aplicación de la API web.
La autoridad "común" (https://login.microsoftonline.com/common/v2.0/
) debe usarse para las aplicaciones multiinquilino. Para usar la entidad "común" para aplicaciones de un solo inquilino, consulte la sección Uso de la entidad "común" para aplicaciones de un solo inquilino .
Actualice los demás valores de la configuración anterior para que coincidan con los valores personalizados o no predeterminados usados en el Program
archivo.
El generador de autenticación recoge automáticamente la configuración.
Quite las siguientes líneas del Program
archivo:
- oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
- oidcOptions.Scope.Add("...");
- oidcOptions.CallbackPath = new PathString("...");
- oidcOptions.SignedOutCallbackPath = new PathString("...");
- oidcOptions.RemoteSignOutPath = new PathString("...");
- oidcOptions.Authority = "...";
- oidcOptions.ClientId = "...";
En el ConfigureCookieOidc
método de CookieOidcServiceCollectionExtensions.cs
, quite la siguiente línea:
- oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
En el proyecto MinimalApiJwt
, agregue la siguiente configuración de la aplicación al archivo appsettings.json
.
"Authentication": {
"Schemes": {
"Bearer": {
"Authority": "https://sts.windows.net/{TENANT ID (WEB API)}/",
"ValidAudiences": [ "{APP ID URI (WEB API)}" ]
}
}
},
Actualice los marcadores de posición de la configuración anterior para que coincidan con los valores que usa la aplicación en el Program
archivo:
-
{TENANT ID (WEB API)}
: identificador de inquilino de la API web. -
{APP ID URI (WEB API)}
: el URI del identificador de aplicación de la API web.
Los formatos de autoridad adoptan los siguientes patrones:
- ME-ID tipo de inquilino:
https://sts.windows.net/{TENANT ID}/
- Tipo de inquilino B2C:
https://login.microsoftonline.com/{TENANT ID}/v2.0/
Los formatos de audiencia adoptan los siguientes patrones ({CLIENT ID}
es el identificador de cliente de la API web; {DIRECTORY NAME}
es el nombre del directorio, por ejemplo, contoso
):
- ME-ID tipo de inquilino:
api://{CLIENT ID}
- Tipo de inquilino B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
El generador de autenticación de portador JWT recoge automáticamente la configuración.
Quite las siguientes líneas del Program
archivo:
- jwtOptions.Authority = "...";
- jwtOptions.Audience = "...";
Para obtener más información sobre la configuración, consulte los siguientes recursos:
Uso de la "Autoridad común" para aplicaciones de un solo arrendatario
Puede usar la entidad "común" para las aplicaciones de inquilino único, pero debe seguir estos pasos para implementar un validador de emisor personalizado.
Agregue el Microsoft.IdentityModel.Validators
paquete NuGet al BlazorWebAppOidc
, BlazorWebAppOidcServer
o BlazorWebAppOidcBff
proyecto.
Nota:
Para obtener instrucciones sobre cómo agregar paquetes a aplicaciones .NET, consulta los artículos de Instalación y administración de paquetes en Flujo de trabajo de consumo de paquetes (documentación de NuGet). Confirme las versiones correctas del paquete en NuGet.org.
En la parte superior del archivo Program
, asegúrese de que el espacio de nombres Microsoft.IdentityModel.Validators esté disponible:
using Microsoft.IdentityModel.Validators;
Use el código siguiente en el Program
archivo donde se configuran las opciones de OIDC:
var microsoftIssuerValidator =
AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator =
microsoftIssuerValidator.Validate;
Para obtener más información, consulta SecurityTokenInvalidIssuerException con OpenID Connect y el punto de conexión "común" de Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
#1731).
Redireccionamiento a la página principal al cerrar sesión
El componente LogInOrOut
(Layout/LogInOrOut.razor
) establece un campo oculto para la dirección URL de retorno (ReturnUrl
) en la dirección URL actual (currentURL
). Cuando el usuario cierra la sesión de la aplicación, el proveedor de identidades devuelve al usuario a la página desde la que ha cerrado la sesión. Si el usuario cierra sesión desde una página segura, se devuelve a la misma página segura y se devuelve a través del proceso de autenticación. Este flujo de autenticación es razonable cuando los usuarios necesitan cambiar las cuentas con regularidad.
Como alternativa, use el siguiente componente LogInOrOut
, que no proporciona una dirección URL de retorno al cerrar sesión.
Layout/LogInOrOut.razor
:
<div class="nav-item px-3">
<AuthorizeView>
<Authorized>
<form action="authentication/logout" method="post">
<AntiforgeryToken />
<button type="submit" class="nav-link">
<span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
</span> Logout
</button>
</form>
</Authorized>
<NotAuthorized>
<a class="nav-link" href="authentication/login">
<span class="bi bi-person-badge-nav-menu" aria-hidden="true"></span>
Login
</a>
</NotAuthorized>
</AuthorizeView>
</div>
Actualización de tokens
La implementación del refrescador personalizado de cookie (CookieOidcRefresher.cs
) actualiza automáticamente los derechos del usuario cuando caducan. La implementación actual espera recibir un token de identificador del punto de conexión del token a cambio del token de actualización. Las notificaciones en este token de ID se usan para sobrescribir las notificaciones del usuario.
La implementación de ejemplo no incluye código para solicitar notificaciones del Punto de conexión de UserInfo cuando se actualiza el token. Para obtener más información, consulte BlazorWebAppOidc AddOpenIdConnect with GetClaimsFromUserInfoEndpoint = true doesn't propogate [sic] role claims to client
(dotnet/aspnetcore
#58826).
Nota:
Algunos proveedores de identidades solo devuelven un token de acceso cuando se utiliza un token de actualización. El CookieOidcRefresher
se puede actualizar con lógica adicional para seguir usando el conjunto anterior de notificaciones almacenadas en el cookie de autenticación, o usar el token de acceso para solicitar notificaciones desde el punto de conexión UserInfo.
Valor nonce criptográfico
Un valor nonce es un valor de cadena que asocia la sesión de un cliente con un token de identificador para mitigar los ataques de reproducción.
Si recibe un error del valor nonce durante el desarrollo y las pruebas de autenticación, use una nueva sesión del explorador InPrivate o incógnito para cada ejecución de prueba, independientemente de lo pequeño que sea el cambio realizado en la aplicación o el usuario de prueba porque los datos de las cookie obsoletos pueden provocar un error del valor nonce. Para obtener más información, consulta la sección Cookies y datos del sitio.
No se requiere ni se usa un valor nonce cuando se intercambia un token de actualización para un nuevo token de acceso. En la aplicación de ejemplo, CookieOidcRefresher
(CookieOidcRefresher.cs
) establece deliberadamente OpenIdConnectProtocolValidator.RequireNonce en false
.
Roles de aplicación para aplicaciones no registradas con Microsoft Entra (ME-ID)
Esta sección se refiere a las aplicaciones que no utilizan Microsoft Entra ID (ME-ID) como proveedor de identidad. Para las aplicaciones registradas con ME-ID, consulta la sección Roles de aplicación para aplicaciones registradas con Microsoft Entra (ME-ID).
Configura el tipo de declaración de rol (TokenValidationParameters.RoleClaimType) en OpenIdConnectOptions de Program.cs
:
oidcOptions.TokenValidationParameters.RoleClaimType = "{ROLE CLAIM TYPE}";
Para muchos proveedores de identidad OIDC, el tipo de reivindicación de rol es role
. Consulte la documentación de su proveedor de identidades para obtener el valor correcto.
Reemplaza la clase UserInfo
del proyecto BlazorWebAppOidc.Client
por la siguiente:
UserInfo.cs
:
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;
namespace BlazorWebAppOidc.Client;
// Add properties to this class and update the server and client
// AuthenticationStateProviders to expose more information about
// the authenticated user to the client.
public sealed class UserInfo
{
public required string UserId { get; init; }
public required string Name { get; init; }
public required string[] Roles { get; init; }
public const string UserIdClaimType = "sub";
public const string NameClaimType = "name";
private const string RoleClaimType = "role";
public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
new()
{
UserId = GetRequiredClaim(principal, UserIdClaimType),
Name = GetRequiredClaim(principal, NameClaimType),
Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
.ToArray(),
};
public ClaimsPrincipal ToClaimsPrincipal() =>
new(new ClaimsIdentity(
Roles.Select(role => new Claim(RoleClaimType, role))
.Concat([
new Claim(UserIdClaimType, UserId),
new Claim(NameClaimType, Name),
]),
authenticationType: nameof(UserInfo),
nameType: NameClaimType,
roleType: RoleClaimType));
private static string GetRequiredClaim(ClaimsPrincipal principal,
string claimType) =>
principal.FindFirst(claimType)?.Value ??
throw new InvalidOperationException(
$"Could not find required '{claimType}' claim.");
}
En este momento, los componentes Razor pueden adoptar la autorización basada en roles y directivas. Los roles de aplicación aparecen en las reclamaciones role
, una reclamación por rol.
Roles de aplicación para aplicaciones registradas con Microsoft Entra (ME-ID)
Usa la guía de esta sección para implementar roles de aplicación, grupos de seguridad de ME-ID y roles de cuenta predefinida de administrador de ME-ID para aplicaciones que usan Microsoft Entra ID (ME-ID).
El enfoque descrito en esta sección configura ME-ID para enviar grupos y roles en el encabezado cookie de autenticación. Cuando los usuarios solo son miembros de unos pocos grupos de seguridad y roles, el siguiente enfoque debe funcionar para la mayoría de las plataformas de hospedaje sin tener un problema en el que los encabezados son demasiado largos, por ejemplo, con el hospedaje de IIS que tiene un límite de longitud de encabezado predeterminado de 16 KB (MaxRequestBytes
). Si la longitud del encabezado es un problema debido a la pertenencia a grupos o roles elevados, se recomienda no seguir las instrucciones de esta sección en favor de implementar Microsoft Graph para obtener los grupos y roles de un usuario de ME-ID por separado, un enfoque que no infla el tamaño de la autenticación cookie. Para obtener más información, consulta Solicitud incorrecta- Solicitud demasiado larga - Servidor IIS (dotnet/aspnetcore
#57545).
Configura el tipo de declaración de rol (TokenValidationParameters.RoleClaimType) en OpenIdConnectOptions de Program.cs
, Establece el valor en roles
:
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Aunque no puede asignar roles a groups sin una cuenta ME-ID Premium, puede asignar roles a los usuarios y recibir notificaciones de roles para los usuarios con una cuenta estándar de Azure. Las instrucciones de esta sección no requieren una cuenta ME-ID Premium.
Al trabajar con el directorio predeterminado, sigue las instrucciones de Incorporación de roles de aplicación a una aplicación y recibirlos en el token (documentación de ME-ID) para configurar y asignar los roles. Si no estás trabajando con el directorio predeterminado, edita el manifiesto de la aplicación en Azure Portal para establecer manualmente los roles de la aplicación en la entrada appRoles
del archivo de manifiesto. Para obtener más información, consulta Configurar la reclamación de rol (documentación de ME-ID).
Los grupos de seguridad de Azure de un usuario llegan en groups
reclamaciones, y las asignaciones de rol de administrador incorporado de ME-ID de un usuario llegan en reclamaciones de identificadores conocidos (wids
). Los valores de ambos tipos de reclamo son GUIDs. Cuando la aplicación las recibe, estas reclamaciones se pueden usar para establecer la autorización de roles y directivas en Razor los componentes.
En el manifiesto de la aplicación en el portal de Azure, establece el atributo groupMembershipClaims
en All
. Un valor de All
da como resultado que ME-ID envíe todos los grupos de seguridad o de distribución (notificaciones groups
) y los roles (notificaciones wids
) del usuario que ha iniciado sesión. Para establecer el atributo groupMembershipClaims
:
- Abre el registro de la aplicación en Azure Portal.
- Selecciona Administrar>Manifiesto en la barra lateral.
- Busca el atributo
groupMembershipClaims
. - Establece el valor en
All
("groupMembershipClaims": "All"
). - Selecciona el botón Guardar.
Reemplaza la clase UserInfo
del proyecto BlazorWebAppOidc.Client
por la siguiente:
UserInfo.cs
:
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;
namespace BlazorWebAppOidc.Client;
// Add properties to this class and update the server and client
// AuthenticationStateProviders to expose more information about
// the authenticated user to the client.
public sealed class UserInfo
{
public required string UserId { get; init; }
public required string Name { get; init; }
public required string[] Roles { get; init; }
public required string[] Groups { get; init; }
public required string[] Wids { get; init; }
public const string UserIdClaimType = "sub";
public const string NameClaimType = "name";
private const string RoleClaimType = "roles";
private const string GroupsClaimType = "groups";
private const string WidsClaimType = "wids";
public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
new()
{
UserId = GetRequiredClaim(principal, UserIdClaimType),
Name = GetRequiredClaim(principal, NameClaimType),
Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
.ToArray(),
Groups = principal.FindAll(GroupsClaimType).Select(c => c.Value)
.ToArray(),
Wids = principal.FindAll(WidsClaimType).Select(c => c.Value)
.ToArray(),
};
public ClaimsPrincipal ToClaimsPrincipal() =>
new(new ClaimsIdentity(
Roles.Select(role => new Claim(RoleClaimType, role))
.Concat(Groups.Select(role => new Claim(GroupsClaimType, role)))
.Concat(Wids.Select(role => new Claim(WidsClaimType, role)))
.Concat([
new Claim(UserIdClaimType, UserId),
new Claim(NameClaimType, Name),
]),
authenticationType: nameof(UserInfo),
nameType: NameClaimType,
roleType: RoleClaimType));
private static string GetRequiredClaim(ClaimsPrincipal principal,
string claimType) =>
principal.FindFirst(claimType)?.Value ??
throw new InvalidOperationException(
$"Could not find required '{claimType}' claim.");
}
En este momento, los componentes Razor pueden adoptar la autorización basada en roles y directivas:
- Los roles de aplicación aparecen en las reclamaciones
roles
, una reclamación por rol. - Los grupos de seguridad aparecen en notificaciones
groups
, una notificación por grupo. Los GUID del grupo de seguridad aparecen en Azure Portal al crear un grupo de seguridad y se muestran al seleccionar Identity>Información general>Grupos>Vista. - Los roles de administrador integrados de ME-ID aparecen en reclamaciones
wids
, una reclamación por rol. La reclamaciónwids
con un valor deb79fbf4d-3ef9-4689-8143-76b194e85509
siempre se envía mediante ME-ID para las cuentas no invitadas del inquilino y no se refiere a un rol de administrador. GUID de la función de administrador (ID de plantilla de funciones) aparecen en el portal Azure al seleccionar Funciones & administradores, seguido de la elipsis (…) >Descripción para la función indicada. Los identificadores de plantilla de roles también aparecen en roles integrados de Microsoft Entra (documentación de Microsoft Entra).
Solución de problemas
Registro
La aplicación de servidor es una aplicación estándar ASP.NET Core. Consulta la guía de registro de ASP.NET Core para habilitar un nivel de registro inferior en la aplicación de servidor.
Para habilitar el registro de depuración o de trazas para la Blazor WebAssembly autenticación, consulte la sección Registro de autenticación del lado cliente de ASP.NET Blazor logging con el selector de versiones del artículo configurado en ASP.NET Core en .NET 7 o posterior.
Errores comunes
El depurador se interrumpe en una excepción durante el cierre de sesión con Microsoft Entra ID externo
La siguiente excepción detiene el depurador de Visual Studio durante el cierre de sesión con Microsoft Entra ID externo:
Uncaught TypeError TypeError: Failed to execute 'postMessage' on 'Window': The provided value cannot be converted to a sequence.
La excepción es lanzada desde el código JavaScript de Entra, por lo que no es un problema con ASP.NET Core. La excepción no afecta a la funcionalidad de la aplicación en producción, por lo que la excepción se puede omitir durante las pruebas de desarrollo local.
Error de configuración de la aplicación o del proveedor de Identity (IP)
Los errores más comunes se deben a una configuración incorrecta. Estos son algunos ejemplos:
- En función de los requisitos del escenario, una autoridad, instancia, identificador de inquilino, dominio de inquilino, identificador de cliente o URI de redireccionamiento faltante o incorrecto impide que una aplicación autentique clientes.
- Los ámbitos de solicitud incorrectos impiden a los clientes acceder a los puntos de conexión de la API web del servidor.
- Faltan permisos de la API de servidor o estos son incorrectos, lo cual impide a los clientes acceder a los puntos de conexión de API web.
- Ejecutar la aplicación en un puerto diferente al configurado en el URI de redirección del registro de aplicación de la IP. Ten en cuenta que no se requiere ningún puerto para Microsoft Entra ID y una aplicación que se ejecute en una dirección de pruebas de desarrollo
localhost
, pero la configuración del puerto de la aplicación y el puerto en el que se ejecuta la aplicación deben coincidir para las direcciones que no seanlocalhost
.
La cobertura de configuración de este artículo muestra ejemplos de la configuración correcta. Revisa cuidadosamente la configuración en busca de errores en la aplicación y la configuración de IP.
Si la configuración parece correcta:
Analiza los registros de la aplicación.
Examina el tráfico de red entre la aplicación cliente y la dirección IP o la aplicación de servidor con las herramientas de desarrollo del navegador. A menudo, la aplicación de servidor o la dirección IP devuelve al cliente un mensaje de error exacto o un mensaje con una pista sobre la causa del problema. En los siguientes artículos encontrarás instrucciones sobre las herramientas de desarrollo:
- Google Chrome (documentación de Google)
- Microsoft Edge
- Mozilla Firefox (documentación de Mozilla)
El equipo de documentación responde a los comentarios y los errores en los artículos (abre una incidencia en la sección de comentarios de esta página), pero no puede proporcionar soporte técnico para el producto. Existen varios foros de soporte técnico públicos que ayudan a solucionar los problemas de una aplicación. Se recomienda lo siguiente:
Microsoft no posee ni controla ninguno de los foros anteriores.
Respecto a los informes de errores del marco que no son de seguridad ni confidenciales, o que no se pueden reproducir, abra una incidencia con la unidad de producto ASP.NET Core. No abras una incidencia con la unidad de producto hasta que hayas investigado exhaustivamente su causa y no puedas resolverlo por tu cuenta o con la ayuda de la comunidad en un foro de soporte técnico público. La unidad de producto no puede solucionar problemas de aplicaciones individuales cuyo funcionamiento se haya interrumpido debido a errores de configuración o casos de uso sencillos que involucren servicios de terceros. Si un informe es confidencial o delicado por naturaleza o describe un posible error de seguridad en el producto que los ciberdelincuentes puedan aprovechar, consulta Informes de problemas de seguridad y errores (repositorio de GitHub
dotnet/aspnetcore
).Cliente no autorizado para ME-ID
Información: Error de autorización de Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]. No se cumplen estos requisitos: DenyAnonymousAuthorizationRequirement: se requiere un usuario autenticado.
Error de devolución de llamada de inicio de sesión de ME-ID:
- Error:
unauthorized_client
- Descripción:
AADB2C90058: The provided application is not configured to allow public clients.
Para resolver el error:
- En Azure Portal, accede al manifiesto de la aplicación.
- Establece el atributo
allowPublicClient
ennull
otrue
.
- Error:
Cookies y datos de sitios
Las cookies y los datos de sitios pueden persistir durante las actualizaciones de la aplicación e interferir con las pruebas y la solución de problemas. Borra los elementos siguientes al realizar cambios en el código de la aplicación, cambios en la cuenta de usuario con el proveedor o cuando el proveedor modifique la configuración de la aplicación:
- Cookies de inicio de sesión de usuario
- Cookies de aplicación
- Datos de sitios almacenados y en caché
El enfoque siguiente sirve para evitar que las cookies persistentes y los datos de sitios interfieran con las pruebas y la solución de problemas:
- Configuración de un explorador
- Usa un explorador para las pruebas, y configúralo para que elimine todas las cookies y los datos del sitio cada vez que se cierre.
- Asegúrate de que el explorador se cierra manualmente o mediante el IDE siempre que se produzca cualquier cambio en la aplicación, el usuario de prueba o la configuración del proveedor.
- Usa un comando personalizado para abrir un explorador en el modo incógnito o privado en Visual Studio:
- Abra el cuadro de diálogo Examinar con mediante el botón Ejecutar de Visual Studio.
- Selecciona el botón Agregar.
- Proporciona la ruta de acceso al explorador en el campo Programa. Las siguientes rutas de acceso del archivo ejecutable son ubicaciones de instalación típicas para Windows 10. Si el explorador está instalado en una ubicación diferente o no usa Windows 10, proporciona la ruta de acceso al archivo ejecutable del explorador.
- Microsoft Edge:
C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
- Google Chrome:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
- Mozilla Firefox:
C:\Program Files\Mozilla Firefox\firefox.exe
- Microsoft Edge:
- En el campo Argumentos, proporciona la opción de línea de comandos que utiliza el explorador para abrirse en el modo incógnito o privado. Algunos exploradores requieren la dirección URL de la aplicación.
- Microsoft Edge: Use
-inprivate
. - Google Chrome: usa
--incognito --new-window {URL}
, donde el marcador de posición{URL}
es la dirección URL que se va a abrir (por ejemplo,https://localhost:5001
). - Mozilla Firefox: usa
-private -url {URL}
, donde el marcador de posición{URL}
es la dirección URL que se va a abrir (por ejemplo,https://localhost:5001
).
- Microsoft Edge: Use
- Proporcione un nombre en el campo Nombre descriptivo. Por ejemplo:
Firefox Auth Testing
. - Selecciona el botón Aceptar.
- Para evitar tener que seleccionar el perfil de explorador para cada iteración de pruebas con una aplicación, establece el perfil como predeterminado con el botón Establecer como predeterminado.
- Asegúrate de que el explorador se cierra mediante el IDE siempre que se produzca cualquier cambio en la aplicación, el usuario de prueba o la configuración del proveedor.
Actualizaciones de aplicaciones
Una aplicación en funcionamiento deja de ejecutarse inmediatamente después de actualizar el SDK de .NET Core en la máquina de desarrollo o de cambiar las versiones del paquete en la aplicación. En algunos casos, los paquetes incoherentes pueden interrumpir una aplicación al realizar actualizaciones importantes. La mayoría de estos problemas puede corregirse siguiendo estas instrucciones:
- Borra las memorias caché del paquete NuGet del sistema local ejecutando
dotnet nuget locals all --clear
desde un shell de comandos. - Elimina las carpetas
bin
yobj
del proyecto. - Restaure el proyecto y vuelva a compilarlo.
- Elimina todos los archivos de la carpeta de implementación del servidor antes de volver a implementar la aplicación.
Nota:
No se pueden usar versiones de paquetes que no sean compatibles con la plataforma de destino de la aplicación. Para obtener información sobre un paquete, use la galería de NuGet.
Iniciar la solución desde el proyecto correcto
Blazor Web Apps:
- Para uno de los ejemplos de patrones back-end para front-end (BFF), inicie la solución desde el proyecto
Aspire/Aspire.AppHost
. - Para uno de los ejemplos de patrones que no son BFF, inicie la solución desde el proyecto de servidor.
Blazor Server:
Inicie la solución desde el proyecto de servidor.
Inspeccione al usuario
El siguiente componente UserClaims
se puede usar directamente en las aplicaciones, o bien servir como base para una mayor personalización.
UserClaims.razor
:
@page "/user-claims"
@using System.Security.Claims
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize]
<PageTitle>User Claims</PageTitle>
<h1>User Claims</h1>
@if (claims.Any())
{
<ul>
@foreach (var claim in claims)
{
<li><b>@claim.Type:</b> @claim.Value</li>
}
</ul>
}
@code {
private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();
[CascadingParameter]
private Task<AuthenticationState>? AuthState { get; set; }
protected override async Task OnInitializedAsync()
{
if (AuthState == null)
{
return;
}
var authState = await AuthState;
claims = authState.User.Claims;
}
}
Recursos adicionales
- Repositorio de GitHub
AzureAD/microsoft-identity-web
: Orientación útil sobre la implementación de Microsoft Web para Microsoft Entra ID y Azure Active Directory B2C para aplicaciones ASP.NET Core, que incluye vínculos a aplicaciones de ejemplo y documentación relacionada de Azure. Actualmente, la documentación de Azure no aborda explícitamente los objetos Blazor Web App, pero la configuración de un objeto Blazor Web App para ME-ID y el hospedaje de Azure es igual que para cualquier aplicación web de ASP.NET Core. -
Servicio
AuthenticationStateProvider
- Administración del estado de la autenticación en Blazor Web Apps
-
Actualizar el token durante la solicitud HTTP en el Servidor Interactivo Blazor con OIDC (
dotnet/aspnetcore
#55213) - Protección de datos en Blazor Web Apps con representación automática interactiva
-
Cómo acceder a
AuthenticationStateProvider
desde unDelegatingHandler