Eventos
Campeonato mundial de DataViz de Power BI
14 feb, 16 - 31 mar, 16
Con 4 posibilidades de entrar, podrías ganar un paquete de conferencia y convertirlo en el Live Grand Finale en Las Vegas
Saber másInformación general sobre la autenticación de ASP.NET Core
Por Mike Rousos
La autenticación es el proceso de determinar la identidad 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.AddSchemedirectamente.
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:
C#
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 AddAuthentication de JwtBearerDefaults.AuthenticationScheme 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.
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:
- Esquema de autenticación
- El esquema de autenticación predeterminado, que se describe en las dos secciones siguientes.
- Establezca directamente HttpContext.User.
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).
Cuando solo hay un único esquema de autenticación registrado, el esquema de autenticación único:
- Se usa automáticamente como DefaultScheme.
- Elimina la necesidad de especificar
DefaultSchemeen AddAuthentication(IServiceCollection) o AddAuthenticationCore(IServiceCollection).
Para deshabilitar automáticamente el uso del esquema de autenticación único como DefaultScheme, llame a AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").
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.
Un controlador de autenticación:
- Es un tipo que implementa el comportamiento de un esquema.
- Se deriva de IAuthenticationHandler o AuthenticationHandler<TOptions>.
- Tiene la responsabilidad principal de autenticar a los usuarios.
Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:
- Si la autenticación se realiza correctamente, construya AuthenticationTicket objetos que representen la identidad del usuario.
- 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> 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.
La acción de autenticación de un esquema de autenticación es responsable de construir la identidad del usuario en función del contexto de solicitud. Devuelve un AuthenticateResult que indica si la autenticación se realizó correctamente y, si es así, la identidad del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:
- Un cookie esquema de autenticación que construye la identidad del usuario a partir de cookies.
- Esquema de portador JWT que deserializa y valida un token de portador JWT para construir la identidad del usuario.
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.
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:
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
Por Mike Rousos
La autenticación es el proceso de determinar la identidad 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.AddSchemedirectamente.
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:
C#
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 AddAuthentication de JwtBearerDefaults.AuthenticationScheme 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.
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:
- Esquema de autenticación
- El esquema de autenticación predeterminado, que se describe en la sección siguiente.
- Establezca directamente HttpContext.User.
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).
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.
Un controlador de autenticación:
- Es un tipo que implementa el comportamiento de un esquema.
- Se deriva de IAuthenticationHandler o AuthenticationHandler<TOptions>.
- Tiene la responsabilidad principal de autenticar a los usuarios.
Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:
- Construya AuthenticationTicket objetos que representan la identidad del usuario si la autenticación tiene éxito.
- 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> 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.
La acción de autenticación de un esquema de autenticación es responsable de construir la identidad del usuario en función del contexto de solicitud. Devuelve un AuthenticateResult que indica si la autenticación se realizó correctamente y, si es así, la identidad del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:
- Un cookie esquema de autenticación que construye la identidad del usuario a partir de cookies.
- Esquema de portador JWT que deserializa y valida un token de portador JWT para construir la identidad del usuario.
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.
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:
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.
Por Mike Rousos
La autenticación es el proceso de determinar la identidad 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.AddSchemedirectamente.
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:
C#
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
options => Configuration.Bind("JwtSettings", options))
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
options => Configuration.Bind("CookieSettings", options));
El parámetro AddAuthentication de JwtBearerDefaults.AuthenticationScheme 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.
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:
- Esquema de autenticación
- El esquema de autenticación predeterminado, que se describe en la sección siguiente.
- Establezca directamente HttpContext.User.
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).
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.
Un controlador de autenticación:
- Es un tipo que implementa el comportamiento de un esquema.
- Se deriva de IAuthenticationHandler o AuthenticationHandler<TOptions>.
- Tiene la responsabilidad principal de autenticar a los usuarios.
Según la configuración del esquema de autenticación y el contexto de la solicitud entrante, los controladores de autenticación:
- Construya AuthenticationTicket objetos que representan la identidad del usuario si la autenticación es exitosa.
- 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> 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.
La acción de autenticación de un esquema de autenticación es responsable de construir la identidad del usuario en función del contexto de solicitud. Devuelve un AuthenticateResult que indica si la autenticación se realizó correctamente y, si es así, la identidad del usuario en un vale de autenticación. Vea AuthenticateAsync. Ejemplos de autenticación:
- Un cookie esquema de autenticación que construye la identidad del usuario a partir de cookies.
- Esquema de portador JWT que deserializa y valida un token de portador JWT para construir la identidad del usuario.
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.
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:
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. 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.
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
Comentarios de ASP.NET Core
ASP.NET Core es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: