Partilhar via

Visão geral da autenticação ASP.NET Core

Por Mike Rousos

A autenticação é o processo de determinar a identidade de um usuário. A autorização é o processo de determinar se um utilizador tem acesso a um recurso. No ASP.NET Core, a autenticação é gerida pelo serviço de autenticação, IAuthenticationServiceque é utilizado pelo middleware de autenticação. O serviço de autenticação usa manipuladores de autenticação registrados para concluir ações relacionadas à autenticação. Exemplos de ações relacionadas com autenticação incluem:

  • Autenticar um utilizador.
  • Responder quando um utilizador não autenticado tenta aceder a um recurso restrito.

Os handlers de autenticação registados e as suas opções de configuração são chamados de "esquemas".

Os esquemas de autenticação são especificados através do registo dos serviços de autenticação em Program.cs:

Por exemplo, o seguinte código regista serviços de autenticação e manipuladores para os esquemas de autenticação "cookie" e "JWT Bearer":

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

O AddAuthentication parâmetro JwtBearerDefaults.AuthenticationScheme é o nome do esquema a usar como padrão quando um esquema específico não é solicitado.

Se forem usados múltiplos esquemas, as políticas de autorização (ou atributos de autorização) podem especificar o esquema de autenticação (ou esquemas) de que dependem para autenticar o utilizador. No exemplo acima, o esquema de autenticação cookie pode ser usado ao especificar o seu nome CookieAuthenticationDefaults.AuthenticationScheme (por padrão, embora seja possível fornecer um nome diferente ao invocar AddCookie).

Em alguns casos, a chamada a AddAuthentication é feita automaticamente por outros métodos de extensão. Por exemplo, ao usar ASP.NET Core Identity, AddAuthentication é chamado internamente.

O middleware de autenticação é adicionado em Program.cs ao chamar UseAuthentication. A chamada UseAuthentication regista o middleware que utiliza os esquemas de autenticação previamente registados. Chame UseAuthentication antes de qualquer middleware que dependa de utilizadores autenticados.

Conceitos de autenticação

A autenticação é responsável por fornecer o ClaimsPrincipal para autorização, a fim de tomar decisões sobre permissões. Existem múltiplas abordagens de esquemas de autenticação para selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações:

Quando existe apenas um único esquema de autenticação registado, este torna-se o esquema padrão. Se vários esquemas forem registados e o esquema padrão não for especificado, um esquema deve ser especificado no atributo authorize, caso contrário, é lançado o seguinte erro:

InvalidOperationException: Não foi especificado nenhum Schema de Autenticação e não foi encontrado o Schema DefaultAuthenticate. Os esquemas padrão podem ser definidos usando AddAuthentication(string defaultScheme) ou AddAuthentication(Action<AuthenticationOptions> , configureOptions).

DefaultScheme

Quando existe apenas um único esquema de autenticação registado, ele:

Para desativar automaticamente usando o único esquema de autenticação como o DefaultScheme, chama AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

Esquema de autenticação

O esquema de autenticação pode selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações. Para mais informações, consulte Autorizar com um esquema específico.

Um esquema de autenticação é um nome que corresponde a:

  • Um gestor de autenticação.
  • Opções para configurar essa instância específica do handler.

Os esquemas são úteis como mecanismo para referir os comportamentos de autenticação, desafio e proibição do manipulador associado. Por exemplo, uma política de autorização pode usar nomes de esquemas para especificar qual (ou esquemas) de autenticação devem ser usados para autenticar o utilizador. Ao configurar a autenticação, é comum especificar o esquema de autenticação predefinido. O esquema padrão é usado a menos que um recurso solicite um esquema específico. Também é possível:

  • Especifique diferentes esquemas padrão para autenticar, desafiar e proibir ações.
  • Combinar vários esquemas num só usando esquemas de políticas.

Manipulador de autenticação

Um manipulador de autenticação:

Com base na configuração do esquema de autenticação e no contexto do pedido recebido, os manipuladores de autenticação:

  • Construir AuthenticationTicket objetos que representem a identidade do utilizador se a autenticação for bem-sucedida.
  • Devolva 'sem resultado' ou 'falha' se a autenticação não for bem-sucedida.
  • Ter métodos para desafiar e proibir ações quando os utilizadores tentam aceder a recursos:
    • Eles não têm autorização para aceder (proíbe).
    • Quando não estão autenticados (desafio).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> é a classe para autenticação que requer um passo de autenticação remota. Quando o passo de autenticação remota termina, o handler faz uma chamada de retorno para o CallbackPath definido pelo próprio handler. O handler termina o passo de autenticação usando a informação passada para o HandleRemoteAuthenticateAsync caminho de callback. O OAuth 2.0 e o OIDC usam ambos este padrão. O JWT e os cookies não o fazem, pois podem usar diretamente o cabeçalho de autorização e o cookie para autenticação. O fornecedor hospedado remotamente neste caso:

  • É o fornecedor de autenticação.
  • Exemplos incluem Facebook, Twitter, Google, Microsoft e qualquer outro fornecedor OIDC que gere a autenticação dos utilizadores através do mecanismo dos handlers.

Authenticate

A ação de autenticação de um esquema de autenticação é responsável por construir a identidade do utilizador com base no contexto do pedido. Retorna um AuthenticateResult que indica se a autenticação foi bem-sucedida e, em caso de sucesso, a identidade do utilizador num ticket de autenticação. Consulte AuthenticateAsync. Exemplos autenticados incluem:

  • Um esquema de autenticação que constrói a identidade do utilizador a partir de cookie cookies.
  • Um esquema portador JWT que desserializa e valida um token portador JWT para construir a identidade do utilizador.

Desafio

Um desafio de autenticação é invocado pela Autorização quando um utilizador não autenticado solicita um endpoint que requer autenticação. É emitido um desafio de autenticação, por exemplo, quando um utilizador anónimo solicita um recurso restrito ou segue um link de login. A autorização invoca um desafio usando o(s) esquema(s) de autenticação especificado(s), ou o padrão se não for especificado nenhum. Consulte ChallengeAsync. Exemplos de desafios de autenticação incluem:

  • Um cookie esquema de autenticação que redireciona o utilizador para uma página de login.
  • Um esquema de portador JWT que devolve um resultado 401 com um cabeçalho www-authenticate: bearer.

Uma ação de desafio deve informar o utilizador sobre qual o mecanismo de autenticação a usar para aceder ao recurso solicitado.

Proibir

A ação de proibição de um esquema de autenticação é chamada por Autorização quando um utilizador autenticado tenta aceder a um recurso ao qual não tem permissão para aceder. Consulte ForbidAsync. Exemplos de proibição de autenticação incluem:

  • Um esquema de autenticação que redireciona o utilizador para uma página indicando que o acesso está proibido.
  • Um esquema bearer JWT que devolve um código de status HTTP 403.
  • Um esquema de autenticação personalizado que redireciona para uma página onde o utilizador pode solicitar acesso ao recurso.

Uma ação proibida pode informar o utilizador:

  • Estão autenticados.
  • Não lhes é permitido aceder ao recurso solicitado.

Consulte os seguintes links para as diferenças entre desafiar e proibir:

Fornecedores de autenticação por inquilino

ASP.NET Core não tem uma solução incorporada para autenticação multi-inquilino. Embora seja possível que os clientes escrevam um usando as funcionalidades integradas, recomendamos que considerem o Orchard Core, ABP Framework ou Finbuckle.MultiTenant para autenticação multi-inquilino.

Orchard Core é:

  • Um framework de aplicações de código aberto, modular e multi-inquilino construído com ASP.NET Core.
  • Um sistema de gestão de conteúdos (CMS) construído sobre essa estrutura de aplicações.

Consulte o código-fonte do Orchard Core para um exemplo de fornecedores de autenticação por inquilino.

O ABP Framework suporta vários padrões arquitetónicos, incluindo modularidade, microserviços, design orientado ao domínio e multi-inquilino. Consulte o código-fonte do Framework ABP no GitHub.

Finbuckle.MultiInquilino:

  • Código aberto
  • Proporciona resolução de inquilinos
  • Leve
  • Fornece isolamento de dados
  • Configure o comportamento da aplicação de forma única para cada inquilino

Recursos adicionais

Por Mike Rousos

A autenticação é o processo de determinar a identidade de um usuário. A autorização é o processo de determinar se um utilizador tem acesso a um recurso. No ASP.NET Core, a autenticação é gerida pelo serviço de autenticação, IAuthenticationServiceque é utilizado pelo middleware de autenticação. O serviço de autenticação usa manipuladores de autenticação registrados para concluir ações relacionadas à autenticação. Exemplos de ações relacionadas com autenticação incluem:

  • Autenticar um utilizador.
  • Responder quando um utilizador não autenticado tenta aceder a um recurso restrito.

Os handlers de autenticação registados e as suas opções de configuração são chamados de "esquemas".

Os esquemas de autenticação são especificados através do registo dos serviços de autenticação em Program.cs:

Por exemplo, o seguinte código regista serviços de autenticação e manipuladores para os esquemas de autenticação "cookie" e "JWT Bearer":

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

O AddAuthentication parâmetro JwtBearerDefaults.AuthenticationScheme é o nome do esquema a usar como padrão quando um esquema específico não é solicitado.

Se forem usados múltiplos esquemas, as políticas de autorização (ou atributos de autorização) podem especificar o esquema de autenticação (ou esquemas) de que dependem para autenticar o utilizador. No exemplo acima, o esquema de autenticação cookie pode ser usado ao especificar o seu nome CookieAuthenticationDefaults.AuthenticationScheme (por padrão, embora seja possível fornecer um nome diferente ao invocar AddCookie).

Em alguns casos, a chamada a AddAuthentication é feita automaticamente por outros métodos de extensão. Por exemplo, ao usar ASP.NET Core Identity, AddAuthentication é chamado internamente.

O middleware de autenticação é adicionado em Program.cs ao chamar UseAuthentication. A chamada UseAuthentication regista o middleware que utiliza os esquemas de autenticação previamente registados. Chame UseAuthentication antes de qualquer middleware que dependa de utilizadores autenticados.

Conceitos de autenticação

A autenticação é responsável por fornecer o ClaimsPrincipal para autorização, a fim de tomar decisões sobre permissões. Existem múltiplas abordagens de esquemas de autenticação para selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações:

Não há verificação automática de esquemas. Se o esquema padrão não for especificado, o esquema deve ser especificado no atributo authorize, caso contrário, é lançado o seguinte erro:

InvalidOperationException: Não foi especificado nenhum Schema de Autenticação e não foi encontrado o Schema DefaultAuthenticate. Os esquemas padrão podem ser definidos usando AddAuthentication(string defaultScheme) ou AddAuthentication(Action<AuthenticationOptions> , configureOptions).

Esquema de autenticação

O esquema de autenticação pode selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações. Para mais informações, consulte Autorizar com um esquema específico.

Um esquema de autenticação é um nome que corresponde a:

  • Um gestor de autenticação.
  • Opções para configurar essa instância específica do handler.

Os esquemas são úteis como mecanismo para referir os comportamentos de autenticação, desafio e proibição do manipulador associado. Por exemplo, uma política de autorização pode usar nomes de esquemas para especificar qual (ou esquemas) de autenticação devem ser usados para autenticar o utilizador. Ao configurar a autenticação, é comum especificar o esquema de autenticação predefinido. O esquema padrão é usado a menos que um recurso solicite um esquema específico. Também é possível:

  • Especifique diferentes esquemas padrão para autenticar, desafiar e proibir ações.
  • Combinar vários esquemas num só usando esquemas de políticas.

Manipulador de autenticação

Um manipulador de autenticação:

Com base na configuração do esquema de autenticação e no contexto do pedido recebido, os manipuladores de autenticação:

  • Construir AuthenticationTicket objetos que representem a identidade do utilizador se a autenticação for bem-sucedida.
  • Devolva 'sem resultado' ou 'falha' se a autenticação não for bem-sucedida.
  • Ter métodos para desafiar e proibir ações quando os utilizadores tentam aceder a recursos:
    • Eles não têm autorização para aceder (proíbe).
    • Quando não estão autenticados (desafio).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> é a classe para autenticação que requer um passo de autenticação remota. Quando o passo de autenticação remota termina, o handler faz uma chamada de retorno para o CallbackPath definido pelo próprio handler. O handler termina o passo de autenticação usando a informação passada para o HandleRemoteAuthenticateAsync caminho de callback. O OAuth 2.0 e o OIDC usam ambos este padrão. O JWT e os cookies não o fazem, pois podem usar diretamente o cabeçalho de autorização e o cookie para autenticação. O fornecedor hospedado remotamente neste caso:

  • É o fornecedor de autenticação.
  • Exemplos incluem Facebook, Twitter, Google, Microsoft e qualquer outro fornecedor OIDC que gere a autenticação dos utilizadores através do mecanismo dos handlers.

Authenticate

A ação de autenticação de um esquema de autenticação é responsável por construir a identidade do utilizador com base no contexto do pedido. Retorna um AuthenticateResult que indica se a autenticação foi bem-sucedida e, em caso de sucesso, a identidade do utilizador num ticket de autenticação. Consulte AuthenticateAsync. Exemplos autenticados incluem:

  • Um esquema de autenticação que constrói a identidade do utilizador a partir de cookie cookies.
  • Um esquema portador JWT que desserializa e valida um token portador JWT para construir a identidade do utilizador.

Desafio

Um desafio de autenticação é invocado pela Autorização quando um utilizador não autenticado solicita um endpoint que requer autenticação. É emitido um desafio de autenticação, por exemplo, quando um utilizador anónimo solicita um recurso restrito ou segue um link de login. A autorização invoca um desafio usando o(s) esquema(s) de autenticação especificado(s), ou o padrão se não for especificado nenhum. Consulte ChallengeAsync. Exemplos de desafios de autenticação incluem:

  • Um cookie esquema de autenticação que redireciona o utilizador para uma página de login.
  • Um esquema de portador JWT que devolve um resultado 401 com um cabeçalho www-authenticate: bearer.

Uma ação de desafio deve informar o utilizador sobre qual o mecanismo de autenticação a usar para aceder ao recurso solicitado.

Proibir

A ação de proibição de um esquema de autenticação é chamada por Autorização quando um utilizador autenticado tenta aceder a um recurso ao qual não tem permissão para aceder. Consulte ForbidAsync. Exemplos de proibição de autenticação incluem:

  • Um esquema de autenticação que redireciona o utilizador para uma página indicando que o acesso está proibido.
  • Um esquema bearer JWT que devolve um código de status HTTP 403.
  • Um esquema de autenticação personalizado que redireciona para uma página onde o utilizador pode solicitar acesso ao recurso.

Uma ação proibida pode informar o utilizador:

  • Estão autenticados.
  • Não lhes é permitido aceder ao recurso solicitado.

Consulte os seguintes links para as diferenças entre desafiar e proibir:

Fornecedores de autenticação por inquilino

ASP.NET Core não tem uma solução incorporada para autenticação multi-inquilino. Embora seja possível que os clientes escrevam um usando as funcionalidades integradas, recomendamos que considerem o Orchard Core ou o ABP Framework para autenticação multi-inquilino.

Orchard Core é:

  • Um framework de aplicações de código aberto, modular e multi-inquilino construído com ASP.NET Core.
  • Um sistema de gestão de conteúdos (CMS) construído sobre essa estrutura de aplicações.

Consulte o código-fonte do Orchard Core para um exemplo de fornecedores de autenticação por inquilino.

O ABP Framework suporta vários padrões arquitetónicos, incluindo modularidade, microserviços, design orientado ao domínio e multi-inquilino. Consulte o código-fonte do Framework ABP no GitHub.

Recursos adicionais

Por Mike Rousos

A autenticação é o processo de determinar a identidade de um usuário. A autorização é o processo de determinar se um utilizador tem acesso a um recurso. No ASP.NET Core, a autenticação é gerida pelo serviço de autenticação, IAuthenticationServiceque é utilizado pelo middleware de autenticação. O serviço de autenticação usa manipuladores de autenticação registrados para concluir ações relacionadas à autenticação. Exemplos de ações relacionadas com autenticação incluem:

  • Autenticar um utilizador.
  • Responder quando um utilizador não autenticado tenta aceder a um recurso restrito.

Os handlers de autenticação registados e as suas opções de configuração são chamados de "esquemas".

Os esquemas de autenticação são especificados através do registo dos serviços de autenticação em Startup.ConfigureServices:

Por exemplo, o seguinte código regista serviços de autenticação e manipuladores para os esquemas de autenticação "cookie" e "JWT Bearer":

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

O AddAuthentication parâmetro JwtBearerDefaults.AuthenticationScheme é o nome do esquema a usar como padrão quando um esquema específico não é solicitado.

Se forem usados múltiplos esquemas, as políticas de autorização (ou atributos de autorização) podem especificar o esquema de autenticação (ou esquemas) de que dependem para autenticar o utilizador. No exemplo acima, o esquema de autenticação cookie pode ser usado ao especificar o seu nome CookieAuthenticationDefaults.AuthenticationScheme (por padrão, embora seja possível fornecer um nome diferente ao invocar AddCookie).

Em alguns casos, a chamada a AddAuthentication é feita automaticamente por outros métodos de extensão. Por exemplo, ao usar ASP.NET Core Identity, AddAuthentication é chamado internamente.

O middleware de autenticação é adicionado em Startup.Configure ao chamar UseAuthentication. A chamada UseAuthentication regista o middleware que utiliza os esquemas de autenticação previamente registados. Chame UseAuthentication antes de qualquer middleware que dependa de utilizadores autenticados. Ao usar o encaminhamento de endpoint, a chamada para UseAuthentication deve ser:

  • Após UseRouting, para que a informação da rota esteja disponível para decisões de autenticação.
  • Antes de UseEndpoints, para que os utilizadores sejam autenticados antes de aceder aos endpoints.

Conceitos de autenticação

A autenticação é responsável por fornecer o ClaimsPrincipal para autorização, a fim de tomar decisões sobre permissões. Existem múltiplas abordagens de esquemas de autenticação para selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações:

Não há verificação automática de esquemas. Se o esquema padrão não for especificado, o esquema deve ser especificado no atributo authorize, caso contrário, é lançado o seguinte erro:

InvalidOperationException: Não foi especificado nenhum Schema de Autenticação e não foi encontrado o Schema DefaultAuthenticate. Os esquemas padrão podem ser definidos usando AddAuthentication(string defaultScheme) ou AddAuthentication(Action<AuthenticationOptions> , configureOptions).

Esquema de autenticação

O esquema de autenticação pode selecionar qual o handler de autenticação responsável por gerar o conjunto correto de reivindicações. Para mais informações, consulte Autorizar com um esquema específico.

Um esquema de autenticação é um nome que corresponde a:

  • Um gestor de autenticação.
  • Opções para configurar essa instância específica do handler.

Os esquemas são úteis como mecanismo para referir os comportamentos de autenticação, desafio e proibição do manipulador associado. Por exemplo, uma política de autorização pode usar nomes de esquemas para especificar qual (ou esquemas) de autenticação devem ser usados para autenticar o utilizador. Ao configurar a autenticação, é comum especificar o esquema de autenticação predefinido. O esquema padrão é usado a menos que um recurso solicite um esquema específico. Também é possível:

  • Especifique diferentes esquemas padrão para autenticar, desafiar e proibir ações.
  • Combinar vários esquemas num só usando esquemas de políticas.

Manipulador de autenticação

Um manipulador de autenticação:

Com base na configuração do esquema de autenticação e no contexto do pedido recebido, os manipuladores de autenticação:

  • Construir AuthenticationTicket objetos que representem a identidade do utilizador se a autenticação for bem-sucedida.
  • Devolva 'sem resultado' ou 'falha' se a autenticação não for bem-sucedida.
  • Ter métodos para desafiar e proibir ações quando os utilizadores tentam aceder a recursos:
    • Eles não têm autorização para aceder (proíbe).
    • Quando não estão autenticados (desafio).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> é a classe para autenticação que requer um passo de autenticação remota. Quando o passo de autenticação remota termina, o handler faz uma chamada de retorno para o CallbackPath definido pelo próprio handler. O handler termina o passo de autenticação usando a informação passada para o HandleRemoteAuthenticateAsync caminho de callback. O OAuth 2.0 e o OIDC usam ambos este padrão. O JWT e os cookies não o fazem, pois podem usar diretamente o cabeçalho de autorização e o cookie para autenticação. O fornecedor hospedado remotamente neste caso:

  • É o fornecedor de autenticação.
  • Exemplos incluem Facebook, Twitter, Google, Microsoft e qualquer outro fornecedor OIDC que gere a autenticação dos utilizadores através do mecanismo dos handlers.

Authenticate

A ação de autenticação de um esquema de autenticação é responsável por construir a identidade do utilizador com base no contexto do pedido. Retorna um AuthenticateResult que indica se a autenticação foi bem-sucedida e, em caso de sucesso, a identidade do utilizador num ticket de autenticação. Consulte AuthenticateAsync. Exemplos autenticados incluem:

  • Um esquema de autenticação que constrói a identidade do utilizador a partir de cookie cookies.
  • Um esquema portador JWT que desserializa e valida um token portador JWT para construir a identidade do utilizador.

Desafio

Um desafio de autenticação é invocado pela Autorização quando um utilizador não autenticado solicita um endpoint que requer autenticação. É emitido um desafio de autenticação, por exemplo, quando um utilizador anónimo solicita um recurso restrito ou segue um link de login. A autorização invoca um desafio usando o(s) esquema(s) de autenticação especificado(s), ou o padrão se não for especificado nenhum. Consulte ChallengeAsync. Exemplos de desafios de autenticação incluem:

  • Um cookie esquema de autenticação que redireciona o utilizador para uma página de login.
  • Um esquema de portador JWT que devolve um resultado 401 com um cabeçalho www-authenticate: bearer.

Uma ação de desafio deve informar o utilizador sobre qual o mecanismo de autenticação a usar para aceder ao recurso solicitado.

Proibir

A ação de proibição de um esquema de autenticação é chamada por Autorização quando um utilizador autenticado tenta aceder a um recurso ao qual não tem permissão para aceder. Consulte ForbidAsync. Exemplos de proibição de autenticação incluem:

  • Um esquema de autenticação que redireciona o utilizador para uma página indicando que o acesso está proibido.
  • Um esquema bearer JWT que devolve um código de status HTTP 403.
  • Um esquema de autenticação personalizado que redireciona para uma página onde o utilizador pode solicitar acesso ao recurso.

Uma ação proibida pode informar o utilizador:

  • Estão autenticados.
  • Não lhes é permitido aceder ao recurso solicitado.

Consulte os seguintes links para as diferenças entre desafiar e proibir:

Fornecedores de autenticação por inquilino

O framework ASP.NET Core não tem uma solução integrada para autenticação multitenant. Embora seja possível para os clientes escreverem uma aplicação com autenticação multi-inquilino, recomendamos a utilização de um dos seguintes frameworks asp.net principais que suportam autenticação multi-inquilino:

Orchard Core

Orchard Core. Consulte o código-fonte do Orchard Core para um exemplo de fornecedores de autenticação por inquilino.

Quadro ABP

O ABP Framework suporta vários padrões arquitetónicos, incluindo modularidade, microserviços, design orientado ao domínio e multi-inquilino. Consulte o código-fonte do Framework ABP no GitHub.

Recursos adicionais

  • Last updated on