Partilhar via

Escolha uma solução de gerenciamento de identity

  • Artigo

A maioria dos aplicativos Web dá suporte à autenticação para garantir que os usuários sejam quem eles afirmam ser. Um usuário pode ser uma pessoa ou outro aplicativo. O gerenciamento de acesso garante que os usuários só possam ver e modificar as informações que estão autorizadas a ver e modificar. Por exemplo, um usuário final não deve ter acesso à seção administrativa de um site. as soluções de gerenciamento Identity são criadas para lidar com os requisitos de tarefas relacionadas à autenticação e autorização. Para saber mais sobre o gerenciamento de identity, confira O que é gerenciamento de identity e acesso?. Muitas soluções de gerenciamento de identity para aplicativos Web .NET estão disponíveis, cada uma com diferentes recursos e requisitos para usar ou instalar. Esse artigo fornece diretrizes sobre como escolher a solução certa.

Gerenciamento básico de identity com o ASP.NET Core Identity

ASP.NET Core é fornecido com um provedor de autenticação interno: ASP.NET Core Identity. O provedor inclui as APIs, a interface do usuário e a configuração do banco de dados de back-end para dar suporte ao gerenciamento de identidades de usuário, ao armazenamento de credenciais do usuário e à concessão ou revogação de permissões. Outros recursos compatíveis incluem:

Para a maioria dos cenários, esse pode ser o único provedor necessário.

Para saber mais:

Em outros cenários, um servidor ou serviço que gerencia a autenticação e a identity pode ser benéfico.

Decida se um servidor OIDC é necessário

Os aplicativos Web exigem uma maneira de lembrar ações passadas porque a Web, por padrão, não tem estado. Caso contrário, os usuários seriam forçados a inserir suas credenciais sempre que navegassem para uma nova página. A solução comum para lembrar o estado é utilizar cookies, um mecanismo baseado em navegador para armazenar dados. O servidor Web envia a cookie inicial e, em seguida, o navegador o armazena e o envia de volta com cada solicitação. Isso é feito automaticamente sem a necessidade de o desenvolvedor escrever qualquer código. Cookies são fáceis de usar e integrados ao navegador, mas são projetados para uso em um único site ou domínio da Web. A solução padrão incorporada ao ASP.NET Core usa a autenticação baseada em cookie.

Tokens são contêineres com metadados que são passados explicitamente pelos cabeçalhos ou corpo de solicitações HTTP. A principal vantagem dos tokens em relação aos cookies é que eles não estão vinculados a um aplicativo ou domínio específico. Em vez disso, os tokens geralmente são assinados com criptografia assimétrica. Por exemplo, os servidores OIDC emitem tokens com informações sobre identity usando o formato JWT (Token Web JSON), que inclui assinatura. A criptografia assimétrica usa uma combinação de uma chave privada conhecida apenas para o signatário e uma chave pública que todos podem saber. Tokens também podem ser criptografados.

O token assinado não pode ser adulterado devido à chave privada. A chave pública:

  • Torna possível validar o token para garantir que ele não tenha sido alterado.
  • Garante que ela foi gerada pela entidade que contém a chave privada.

A principal desvantagem de usar tokens é que eles exigem um serviço (normalmente um servidor OIDC) para emitir e fornecer validação para tokens. O serviço deve ser instalado, configurado e mantido.

É comum que um servidor OIDC seja necessário para aplicativos que expõem APIs baseadas na Web que são consumidas por outros aplicativos. Para APIs baseadas na Web expostas, as interfaces do usuário do cliente, como SPA (Aplicativos de Página Única), clientes móveis e clientes da área de trabalho, são consideradas parte do mesmo aplicativo. Exemplos de SPA incluem Angular, React e Blazor WebAssembly. Se aplicativos diferentes do seu aplicativo Web ou de qualquer interface do usuário do cliente precisarem fazer uma chamada de API segura para seu aplicativo, você provavelmente desejará usar tokens. Se você tiver apenas UIs de cliente, o ASP.NET Core Identity fornecerá a opção de adquirir um token durante a autenticação. O token de autenticação emitido pelo ASP.NET Core Identity:

  • Pode ser usado por clientes móveis e de área de trabalho. Os cookies são preferenciais em vez de tokens para segurança e simplicidade.
  • Não é adequado para gerenciar o acesso de aplicativos de terceiros.

Outro motivo pelo qual um servidor OIDC é necessário é para compartilhar entradas com outros aplicativos. Normalmente chamado de logon único, esse recurso permite que os usuários:

  • Entrem uma vez com o formulário de um aplicativo Web.
  • Use as credenciais resultantes para se autenticar com outros aplicativos sem precisar entrar novamente ou escolher uma senha diferente.

Normalmente, um servidor OIDC é preferido para fornecer uma solução segura e escalonável para logon único.

Para aplicativos que não compartilham logons com outros aplicativos, a maneira mais simples de proteger rapidamente um aplicativo é usar o provedor ASP.NET Core Identity interno. Caso contrário, um servidor OIDC fornecido por uma solução de gerenciamento de identity de terceiros é necessário. Os servidores OIDC estão disponíveis como:

  • Produtos que você instala em seu servidor, chamados de auto-host.
  • Os contêineres são executados em um host como o Docker.
  • Serviços baseados na Web com os quais você se integra para gerenciar a identity.

Algumas soluções são gratuitas e de software livre, enquanto outras são licenciadas comercialmente. Consulte as soluções de gerenciamento de identity para obter uma lista de opções disponíveis. É possível que sua organização já use um provedor de identity. Nesse caso, pode fazer sentido usar o provedor existente em vez de escolher uma solução diferente. Todas as principais soluções fornecem documentação para configurar o ASP.NET Core para usar seu produto ou serviço.

Cenários desconectados

Muitas soluções, como o Microsoft Entra ID, são baseadas em nuvem e exigem uma conexão com a Internet para funcionar. Se o ambiente não permitir conectividade com a Internet, você não poderá usar o serviço.

O ASP.NET Core Identity funciona perfeitamente bem em cenários desconectados, como:

  • O aplicativo não pode acessar a Internet.
  • O aplicativo ainda deve funcionar na rede local mesmo se a Internet estiver desconectada.

Se você precisar de um servidor OIDC completo para um cenário desconectado, escolha uma das seguintes opções:

  • Uma solução que permite instalar e executar o serviço em seus próprios computadores.
  • Execute o serviço de autenticação localmente como um contêiner.

Decida onde os dados do usuário, como entradas, são armazenados

Outro fator importante a ser considerado é onde os dados de entrada do usuário são armazenados. Muitos desenvolvedores escolhem serviços externos baseados em nuvem, como o Microsoft Entra ID, para gerenciar a identity. Um provedor de serviços baseado em nuvem:

  • Assume as responsabilidades de armazenar dados com segurança.
  • Mantém o software atualizado com os patches e versões de segurança mais recentes.
  • Conformidade com os regulamentos de privacy

Outros preferem armazenar dados em seus próprios servidores devido a regulamentos, conformidade, política ou outros motivos.

Se os dados forem armazenados em seus servidores, provavelmente você precisará escolher uma solução instalável ou baseada em contêiner.

Identity vs servidor OIDC

Use o diagrama a seguir para ajudá-lo a decidir se deseja usar o sistema ASP.NET Core Identity ou um servidor OIDC para autenticação e autorização:

Fluxo de decisão de gerenciamento de Identity

A tabela a seguir lista algumas das coisas a serem consideradas ao escolher sua solução de gerenciamento de identity.

Recurso Auto-host (infraestrutura ou contêiner) Nuvem
Integração de aplicativo Soluções locais que são implementadas como bibliotecas ou estruturas geralmente podem ser integradas diretamente em seu próprio aplicativo. Soluções baseadas em contêiner exigem uma entrega para ocorrer entre seu aplicativo Web e o serviço baseado em contêiner. As soluções baseadas em nuvem normalmente se integram em pontos específicos no fluxo de entrada e fornecem configuração para atualizar a interface do usuário para corresponder ao tema, mas o nível de personalização disponível é limitado.
Configuration As soluções de auto-host exigem a configuração do software para o ambiente, além de configurar como você deseja gerenciar identidades. As soluções baseadas em contêiner normalmente fornecem uma interface do usuário baseada na Web para configuração. As soluções baseadas em nuvem normalmente fornecem uma interface do usuário baseada na Web para configuração.
Personalização As soluções de auto-host geralmente são altamente personalizáveis, incluindo alterações baseadas em código. Embora as soluções em contêineres forneçam opções de extensibilidade, elas geralmente são mais limitadas. Os serviços baseados em nuvem permitem a personalização, mas normalmente são limitados a alterações baseadas em configuração.
Manutenção Os produtos instalados exigem um recurso dedicado para garantir que todos os patches de segurança sejam aplicados em tempo hábil e gerenciar atualizações. O processo de atualização e patch para contêineres geralmente é de menor atrito e envolve simplesmente a instalação da imagem de contêiner fornecida. O provedor de serviços mantém sua solução baseada em nuvem, incluindo a aplicação de patches necessários e o tratamento de atualizações.
Armazenamento de credenciais do usuário Você é responsável pela governança de dados e pelo tratamento de violações. Gerenciando os riscos associados ao tratamento de credenciais do usuário e em conformidade com as regulamentações. é delegado ao provedor de serviços.

Para obter mais informações sobre as opções disponíveis, consulte Identity soluções de gerenciamento para ASP.NET Core.

Próximas etapas