Comparteix a través de

Información general sobre la autenticación de ASP.NET Core

  • Article

Por Mike Rousos

La autenticación es el proceso de determinar la identity de un usuario. Por su parte, la autorización consiste en determinar si un usuario tiene acceso a un recurso. En ASP.NET Core, la autenticación se controla mediante el servicio de autenticación, IAuthenticationService, que el middleware de autenticación emplea para conseguirlo. El servicio de autenticación usa controladores de autenticación registrados para completar las acciones relacionadas con la autenticación. Estos son algunos ejemplos de acciones relacionadas con la autenticación:

  • Autenticación de un usuario
  • Respuesta si un usuario no autenticado intenta acceder a un recurso restringido

Los controladores de autenticación registrados y sus opciones de configuración se denominan "esquemas".

Para especificar esquemas de autenticación, es necesario registrar servicios de autenticación en Program.cs:

  • Mediante una llamada a un método de extensión específico del esquema tras una llamada a AddAuthentication, por ejemplo, AddJwtBearer o AddCookie. Estos métodos de extensión usan AuthenticationBuilder.AddScheme para registrar esquemas con la configuración adecuada.
  • Con menos frecuencia, llamando a AuthenticationBuilder.AddScheme directamente.

Por ejemplo, el código siguiente registra los servicios de autenticación y los controladores para los esquemas de autenticación de portador de JWT y de cookie:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

El parámetro JwtBearerDefaults.AuthenticationScheme de AddAuthentication es el nombre del esquema que se usará de forma predeterminada si no se solicita un esquema específico.

Si se usan varios esquemas, las directivas de autorización (o los atributos de autorización) pueden especificar el esquema (o esquemas) de autenticación del que dependen para autenticar al usuario. En el ejemplo anterior, se podría especificar el nombre del esquema de autenticación de cookie (CookieAuthenticationDefaults.AuthenticationScheme de forma predeterminada, aunque se podría proporcionar otro nombre al llamar a AddCookie).

En algunos casos, la llamada a AddAuthentication se realiza automáticamente mediante otros métodos de extensión. Por ejemplo, al usar ASP.NET Core Identity, se llama a AddAuthentication internamente.

Para agregar el middleware de autenticación en Program.cs, se llama a UseAuthentication. La llamada a UseAuthentication registra el middleware que usa los esquemas de autenticación previamente registrados. Llame a UseAuthentication antes de registrar cualquier middleware que dependa de que los usuarios se autentiquen.

Conceptos de autenticación

La autenticación es responsable de proporcionar el elemento ClaimsPrincipal para la autorización sobre el que tomar decisiones relativas a los permisos. Hay varios enfoques de esquema de autenticación para seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto:

Cuando solo hay un único esquema de autenticación registrado, se convierte en el esquema predeterminado. Si se registran varios esquemas y no se especifica el esquema predeterminado, se debe especificar un esquema en el atributo authorize; de lo contrario, se produce el siguiente error:

InvalidOperationException: No se ha especificado authenticationScheme y no se ha encontrado DefaultAuthenticateScheme. Los esquemas predeterminados se pueden establecer mediante AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

DefaultScheme

Cuando solo hay un único esquema de autenticación registrado, el esquema de autenticación único:

Para deshabilitar automáticamente el uso del esquema de autenticación único como DefaultScheme, llame a AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

Esquema de autenticación

El esquema de autenticación puede seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto. Para obtener más información, vea Autorizar con un esquema específico en ASP.NET Core.

Un esquema de autenticación es un nombre que corresponde a:

  • Un controlador de autenticación.
  • Opciones para configurar esa instancia específica del controlador.

Los esquemas son útiles como mecanismo para hacer referencia a los comportamientos de autenticación, desafío y prohibición del controlador asociado. Por ejemplo, una directiva de autorización puede usar nombres de esquemas para especificar qué esquema (o esquemas) de autenticación conviene usar para autenticar al usuario. Al configurar la autenticación, es habitual especificar un esquema de autenticación predeterminado. A menos que un recurso solicite un esquema específico, se usará el predeterminado. También es posible:

  • Especificar distintos esquemas predeterminados que se usarán para las acciones de autenticación, desafío y prohibición.
  • Combinar varios esquemas en uno mediante esquemas de directiva.

Controlador de autenticación

Un controlador de autenticación:

Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:

  • Construyen objetos AuthenticationTicket que representan la identity del usuario si la autenticación se realiza correctamente.
  • Devuelven "sin resultados" o "error" si la autenticación no es correcta.
  • Tienen métodos para las acciones de desafío y prohibición para los casos en los que los usuarios intenten acceder a los recursos:
    • No están autorizados a tener acceso (prohibición).
    • Cuando no están autenticados (desafío).

RemoteAuthenticationHandler<TOptions> frente a AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> es la clase para la autenticación que requiere un paso de autenticación remota. Una vez finalizado el paso de autenticación remota, el controlador vuelve a llamar al CallbackPath establecido por el controlador. El controlador finaliza el paso de autenticación con la información que se pasa a la ruta de devolución de llamada HandleRemoteAuthenticateAsync. OAuth 2.0 y OIDC usan este patrón. JWT y cookies no lo usan, ya que pueden usar directamente el encabezado de portador y cookie para autenticarse. El proveedor hospedado de forma remota en este caso:

  • Es el proveedor de autenticación.
  • Algunos ejemplos son Facebook, Twitter, Google, Microsoft y cualquier otro proveedor de OIDC que controle la autenticación de los usuarios mediante el mecanismo de controladores.

Authenticate

La acción de autenticación de un esquema de autenticación es la responsable de construir la identity del usuario basándose en el contexto de la solicitud. Devuelve AuthenticateResult, que indica si la autenticación se realizó correctamente y, en caso afirmativo, la identity del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:

  • Un esquema de autenticación de cookie que crea la identity del usuario a partir de las cookies.
  • Un esquema portador JWT que deserializa y valida un token de portador JWT para construir la identity del usuario.

Desafío

La autorización invoca un desafío de autenticación si un usuario no autenticado solicita un punto de conexión que requiere autenticación. Se emite un desafío de autenticación si, por ejemplo, un usuario anónimo solicita un recurso restringido o sigue un vínculo de inicio de sesión. La autorización invoca un desafío con los esquemas de autenticación especificados o con el valor predeterminado, si no se especifica ningún esquema. Vea ChallengeAsync. Ejemplos de desafío de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página de inicio de sesión.
  • Un esquema portador JWT que devuelve un resultado 401 con un encabezado www-authenticate: bearer.

Una acción de desafío debe permitir que el usuario sepa qué mecanismo de autenticación hay que emplear para tener acceso al recurso solicitado.

Prohibición

La autorización llama a una acción de prohibición del esquema de autenticación cuando un usuario autenticado intenta tener acceso a un recurso para el que no tiene permiso de acceso. Vea ForbidAsync. Ejemplos de prohibición de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página que indica que se ha prohibido el acceso.
  • Un esquema portador JWT que devuelve un resultado 403.
  • Un esquema de autenticación personalizado que redirige a una página en la que el usuario puede solicitar acceso al recurso.

Una acción de prohibición puede permitir que los usuarios sepan que:

  • Están autenticados.
  • No se les permite el acceso al recurso solicitado.

Consulte los vínculos siguientes para conocer las diferencias entre desafío y prohibición:

Proveedores de autenticación por inquilino

ASP.NET Core no tiene una solución integrada para la autenticación de varios inquilinos. Aunque es posible que los clientes escriban uno con las características integradas, se recomienda a los clientes Orchard Core, el Marco de ABP o Finbuckle.MultiTenant para la autenticación de varios inquilinos.

Orchard Core es:

  • Un marco de aplicaciones de varios inquilinos y modular de código abierto creado con ASP.NET Core.
  • Un sistema de administración de contenido (CMS) basado en el marco de la aplicación.

Visite Orchard Core para ver un ejemplo de proveedores de autenticación por inquilino.

El Marco de ABP admite varios patrones arquitectónicos, como modularidad, microservicios, diseño controlado por dominios y de varios inquilinos. Consulte el origen del Marco de ABP en GitHub.

Finbuckle.MultiTenant:

  • Código Abierto
  • Proporciona resolución de inquilinos
  • Ligero
  • Proporciona aislamiento de datos
  • Configuración del comportamiento de la aplicación de forma única para cada inquilino

Recursos adicionales

Por Mike Rousos

La autenticación es el proceso de determinar la identity de un usuario. Por su parte, la autorización consiste en determinar si un usuario tiene acceso a un recurso. En ASP.NET Core, la autenticación se controla mediante el servicio de autenticación, IAuthenticationService, que el middleware de autenticación emplea para conseguirlo. El servicio de autenticación usa controladores de autenticación registrados para completar las acciones relacionadas con la autenticación. Estos son algunos ejemplos de acciones relacionadas con la autenticación:

  • Autenticación de un usuario
  • Respuesta si un usuario no autenticado intenta acceder a un recurso restringido

Los controladores de autenticación registrados y sus opciones de configuración se denominan "esquemas".

Para especificar esquemas de autenticación, es necesario registrar servicios de autenticación en Program.cs:

  • Mediante una llamada a un método de extensión específico del esquema tras una llamada a AddAuthentication, por ejemplo, AddJwtBearer o AddCookie. Estos métodos de extensión usan AuthenticationBuilder.AddScheme para registrar esquemas con la configuración adecuada.
  • Con menos frecuencia, llamando a AuthenticationBuilder.AddScheme directamente.

Por ejemplo, el código siguiente registra los servicios de autenticación y los controladores para los esquemas de autenticación de portador de JWT y de cookie:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

El parámetro JwtBearerDefaults.AuthenticationScheme de AddAuthentication es el nombre del esquema que se usará de forma predeterminada si no se solicita un esquema específico.

Si se usan varios esquemas, las directivas de autorización (o los atributos de autorización) pueden especificar el esquema (o esquemas) de autenticación del que dependen para autenticar al usuario. En el ejemplo anterior, se podría especificar el nombre del esquema de autenticación de cookie (CookieAuthenticationDefaults.AuthenticationScheme de forma predeterminada, aunque se podría proporcionar otro nombre al llamar a AddCookie).

En algunos casos, la llamada a AddAuthentication se realiza automáticamente mediante otros métodos de extensión. Por ejemplo, al usar ASP.NET Core Identity, se llama a AddAuthentication internamente.

Para agregar el middleware de autenticación en Program.cs, se llama a UseAuthentication. La llamada a UseAuthentication registra el middleware que usa los esquemas de autenticación previamente registrados. Llame a UseAuthentication antes de registrar cualquier middleware que dependa de que los usuarios se autentiquen.

Conceptos de autenticación

La autenticación es responsable de proporcionar el elemento ClaimsPrincipal para la autorización sobre el que tomar decisiones relativas a los permisos. Hay varios enfoques de esquema de autenticación para seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto:

No hay sondeos automáticos de esquemas. Si no se especifica el esquema predeterminado, el esquema se debe especificar en el atributo authorize; de lo contrario, se producirá el error siguiente:

InvalidOperationException: No se ha especificado authenticationScheme y no se ha encontrado DefaultAuthenticateScheme. Los esquemas predeterminados se pueden establecer mediante AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

Esquema de autenticación

El esquema de autenticación puede seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto. Para obtener más información, vea Autorizar con un esquema específico en ASP.NET Core.

Un esquema de autenticación es un nombre que corresponde a:

  • Un controlador de autenticación.
  • Opciones para configurar esa instancia específica del controlador.

Los esquemas son útiles como mecanismo para hacer referencia a los comportamientos de autenticación, desafío y prohibición del controlador asociado. Por ejemplo, una directiva de autorización puede usar nombres de esquemas para especificar qué esquema (o esquemas) de autenticación conviene usar para autenticar al usuario. Al configurar la autenticación, es habitual especificar un esquema de autenticación predeterminado. A menos que un recurso solicite un esquema específico, se usará el predeterminado. También es posible:

  • Especificar distintos esquemas predeterminados que se usarán para las acciones de autenticación, desafío y prohibición.
  • Combinar varios esquemas en uno mediante esquemas de directiva.

Controlador de autenticación

Un controlador de autenticación:

Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:

  • Construyen objetos AuthenticationTicket que representan la identity del usuario si la autenticación se realiza correctamente.
  • Devuelven "sin resultados" o "error" si la autenticación no es correcta.
  • Tienen métodos para las acciones de desafío y prohibición para los casos en los que los usuarios intenten acceder a los recursos:
    • No están autorizados a tener acceso (prohibición).
    • Cuando no están autenticados (desafío).

RemoteAuthenticationHandler<TOptions> frente a AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> es la clase para la autenticación que requiere un paso de autenticación remota. Una vez finalizado el paso de autenticación remota, el controlador vuelve a llamar al CallbackPath establecido por el controlador. El controlador finaliza el paso de autenticación con la información que se pasa a la ruta de devolución de llamada HandleRemoteAuthenticateAsync. OAuth 2.0 y OIDC usan este patrón. JWT y cookies no lo usan, ya que pueden usar directamente el encabezado de portador y cookie para autenticarse. El proveedor hospedado de forma remota en este caso:

  • Es el proveedor de autenticación.
  • Algunos ejemplos son Facebook, Twitter, Google, Microsoft y cualquier otro proveedor de OIDC que controle la autenticación de los usuarios mediante el mecanismo de controladores.

Authenticate

La acción de autenticación de un esquema de autenticación es la responsable de construir la identity del usuario basándose en el contexto de la solicitud. Devuelve AuthenticateResult, que indica si la autenticación se realizó correctamente y, en caso afirmativo, la identity del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:

  • Un esquema de autenticación de cookie que crea la identity del usuario a partir de las cookies.
  • Un esquema portador JWT que deserializa y valida un token de portador JWT para construir la identity del usuario.

Desafío

La autorización invoca un desafío de autenticación si un usuario no autenticado solicita un punto de conexión que requiere autenticación. Se emite un desafío de autenticación si, por ejemplo, un usuario anónimo solicita un recurso restringido o sigue un vínculo de inicio de sesión. La autorización invoca un desafío con los esquemas de autenticación especificados o con el valor predeterminado, si no se especifica ningún esquema. Vea ChallengeAsync. Ejemplos de desafío de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página de inicio de sesión.
  • Un esquema portador JWT que devuelve un resultado 401 con un encabezado www-authenticate: bearer.

Una acción de desafío debe permitir que el usuario sepa qué mecanismo de autenticación hay que emplear para tener acceso al recurso solicitado.

Prohibición

La autorización llama a una acción de prohibición del esquema de autenticación cuando un usuario autenticado intenta tener acceso a un recurso para el que no tiene permiso de acceso. Vea ForbidAsync. Ejemplos de prohibición de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página que indica que se ha prohibido el acceso.
  • Un esquema portador JWT que devuelve un resultado 403.
  • Un esquema de autenticación personalizado que redirige a una página en la que el usuario puede solicitar acceso al recurso.

Una acción de prohibición puede permitir que los usuarios sepan que:

  • Están autenticados.
  • No se les permite el acceso al recurso solicitado.

Consulte los vínculos siguientes para conocer las diferencias entre desafío y prohibición:

Proveedores de autenticación por inquilino

ASP.NET Core no tiene una solución integrada para la autenticación de varios inquilinos. Aunque es posible que los clientes escriban uno con las características integradas, se recomienda a los clientes Orchard Core o el Marco de ABP para la autenticación de varios inquilinos.

Orchard Core es:

  • Un marco de aplicaciones de varios inquilinos y modular de código abierto creado con ASP.NET Core.
  • Un sistema de administración de contenido (CMS) basado en el marco de la aplicación.

Visite Orchard Core para ver un ejemplo de proveedores de autenticación por inquilino.

El Marco de ABP admite varios patrones arquitectónicos, como modularidad, microservicios, diseño controlado por dominios y de varios inquilinos. Consulte el origen del Marco de ABP en GitHub.

Recursos adicionales

Por Mike Rousos

La autenticación es el proceso de determinar la identity de un usuario. Por su parte, la autorización consiste en determinar si un usuario tiene acceso a un recurso. En ASP.NET Core, la autenticación se controla mediante el servicio de autenticación, IAuthenticationService, que el middleware de autenticación emplea para conseguirlo. El servicio de autenticación usa controladores de autenticación registrados para completar las acciones relacionadas con la autenticación. Estos son algunos ejemplos de acciones relacionadas con la autenticación:

  • Autenticación de un usuario
  • Respuesta si un usuario no autenticado intenta acceder a un recurso restringido

Los controladores de autenticación registrados y sus opciones de configuración se denominan "esquemas".

Para especificar esquemas de autenticación, es necesario registrar servicios de autenticación en Startup.ConfigureServices:

  • Mediante una llamada a un método de extensión específico del esquema tras una llamada a AddAuthentication (por ejemplo, AddJwtBearer o AddCookie). Estos métodos de extensión usan AuthenticationBuilder.AddScheme para registrar esquemas con la configuración adecuada.
  • Con menos frecuencia, llamando a AuthenticationBuilder.AddScheme directamente.

Por ejemplo, el código siguiente registra los servicios de autenticación y los controladores para los esquemas de autenticación de portador de JWT y de cookie:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => Configuration.Bind("CookieSettings", options));

El parámetro JwtBearerDefaults.AuthenticationScheme de AddAuthentication es el nombre del esquema que se usará de forma predeterminada si no se solicita un esquema específico.

Si se usan varios esquemas, las directivas de autorización (o los atributos de autorización) pueden especificar el esquema (o esquemas) de autenticación del que dependen para autenticar al usuario. En el ejemplo anterior, se podría especificar el nombre del esquema de autenticación de cookie (CookieAuthenticationDefaults.AuthenticationScheme de forma predeterminada, aunque se podría proporcionar otro nombre al llamar a AddCookie).

En algunos casos, la llamada a AddAuthentication se realiza automáticamente mediante otros métodos de extensión. Por ejemplo, al usar ASP.NET Core Identity, se llama a AddAuthentication internamente.

Para agregar el middleware de autenticación en Startup.Configure, se llama a UseAuthentication. La llamada a UseAuthentication registra el middleware que usa los esquemas de autenticación previamente registrados. Llame a UseAuthentication antes de registrar cualquier middleware que dependa de que los usuarios se autentiquen. Al usar el enrutamiento de punto de conexión, la llamada a UseAuthentication debe ir:

  • Después de UseRouting, para que la información de ruta esté disponible para las decisiones de autenticación.
  • Antes de UseEndpoints, para que los usuarios se autentiquen como paso previo para tener acceso a los puntos de conexión.

Conceptos de autenticación

La autenticación es responsable de proporcionar el elemento ClaimsPrincipal para la autorización sobre el que tomar decisiones relativas a los permisos. Hay varios enfoques de esquema de autenticación para seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto:

No hay sondeos automáticos de esquemas. Si no se especifica el esquema predeterminado, el esquema se debe especificar en el atributo authorize; de lo contrario, se producirá el error siguiente:

InvalidOperationException: No se ha especificado authenticationScheme y no se ha encontrado DefaultAuthenticateScheme. Los esquemas predeterminados se pueden establecer mediante AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

Esquema de autenticación

El esquema de autenticación puede seleccionar el controlador de autenticación responsable de la generación del conjunto de notificaciones correcto. Para obtener más información, vea Autorizar con un esquema específico en ASP.NET Core.

Un esquema de autenticación es un nombre que corresponde a:

  • Un controlador de autenticación.
  • Opciones para configurar esa instancia específica del controlador.

Los esquemas son útiles como mecanismo para hacer referencia a los comportamientos de autenticación, desafío y prohibición del controlador asociado. Por ejemplo, una directiva de autorización puede usar nombres de esquemas para especificar qué esquema (o esquemas) de autenticación conviene usar para autenticar al usuario. Al configurar la autenticación, es habitual especificar un esquema de autenticación predeterminado. A menos que un recurso solicite un esquema específico, se usará el predeterminado. También es posible:

  • Especificar distintos esquemas predeterminados que se usarán para las acciones de autenticación, desafío y prohibición.
  • Combinar varios esquemas en uno mediante esquemas de directiva.

Controlador de autenticación

Un controlador de autenticación:

Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:

  • Construyen objetos AuthenticationTicket que representan la identity del usuario si la autenticación se realiza correctamente.
  • Devuelven "sin resultados" o "error" si la autenticación no es correcta.
  • Tienen métodos para las acciones de desafío y prohibición para los casos en los que los usuarios intenten acceder a los recursos:
    • No están autorizados a tener acceso (prohibición).
    • Cuando no están autenticados (desafío).

RemoteAuthenticationHandler<TOptions> frente a AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> es la clase para la autenticación que requiere un paso de autenticación remota. Una vez finalizado el paso de autenticación remota, el controlador vuelve a llamar al CallbackPath establecido por el controlador. El controlador finaliza el paso de autenticación con la información que se pasa a la ruta de devolución de llamada HandleRemoteAuthenticateAsync. OAuth 2.0 y OIDC usan este patrón. JWT y cookies no lo usan, ya que pueden usar directamente el encabezado de portador y cookie para autenticarse. El proveedor hospedado de forma remota en este caso:

  • Es el proveedor de autenticación.
  • Algunos ejemplos son Facebook, Twitter, Google, Microsoft y cualquier otro proveedor de OIDC que controle la autenticación de los usuarios mediante el mecanismo de controladores.

Authenticate

La acción de autenticación de un esquema de autenticación es la responsable de construir la identity del usuario basándose en el contexto de la solicitud. Devuelve AuthenticateResult, que indica si la autenticación se realizó correctamente y, en caso afirmativo, la identity del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:

  • Un esquema de autenticación de cookie que crea la identity del usuario a partir de las cookies.
  • Un esquema portador JWT que deserializa y valida un token de portador JWT para construir la identity del usuario.

Desafío

La autorización invoca un desafío de autenticación si un usuario no autenticado solicita un punto de conexión que requiere autenticación. Se emite un desafío de autenticación si, por ejemplo, un usuario anónimo solicita un recurso restringido o sigue un vínculo de inicio de sesión. La autorización invoca un desafío con los esquemas de autenticación especificados o con el valor predeterminado, si no se especifica ningún esquema. Vea ChallengeAsync. Ejemplos de desafío de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página de inicio de sesión.
  • Un esquema portador JWT que devuelve un resultado 401 con un encabezado www-authenticate: bearer.

Una acción de desafío debe permitir que el usuario sepa qué mecanismo de autenticación hay que emplear para tener acceso al recurso solicitado.

Prohibición

La autorización llama a una acción de prohibición del esquema de autenticación cuando un usuario autenticado intenta tener acceso a un recurso para el que no tiene permiso de acceso. Vea ForbidAsync. Ejemplos de prohibición de autenticación:

  • Un esquema de autenticación de cookie que redirige al usuario a una página que indica que se ha prohibido el acceso.
  • Un esquema portador JWT que devuelve un resultado 403.
  • Un esquema de autenticación personalizado que redirige a una página en la que el usuario puede solicitar acceso al recurso.

Una acción de prohibición puede permitir que los usuarios sepan que:

  • Están autenticados.
  • No se les permite el acceso al recurso solicitado.

Consulte los vínculos siguientes para conocer las diferencias entre desafío y prohibición:

Proveedores de autenticación por inquilino

El marco ASP.NET Core no tiene una solución integrada para la autenticación de varios inquilinos. Aunque es posible que los clientes escriban una aplicación con autenticación de varios inquilinos, se recomienda usar uno de los siguientes marcos de aplicación ASP.NET Core que admiten la autenticación de varios inquilinos:

Orchard Core

Orchard Core. Visite Orchard Core para ver un ejemplo de proveedores de autenticación por inquilino.

Marco de ABP

El Marco de ABP admite varios patrones arquitectónicos, como modularidad, microservicios, diseño controlado por dominios y de varios inquilinos. Consulte el origen del Marco de ABP en GitHub.

Recursos adicionales