Práticas recomendadas e recomendações da plataforma de identidade da Microsoft

Este artigo destaca as práticas recomendadas, recomendações e descuidos comuns ao integrar com a plataforma de identidade da Microsoft. Esta lista de verificação irá guiá-lo para uma integração segura e de alta qualidade. Reveja esta lista regularmente para se certificar de que mantém a qualidade e a segurança da integração da sua aplicação com a plataforma de identidade. A lista de verificação não se destina a rever todo o seu pedido. O conteúdo da lista de verificação está sujeito a alterações à medida que fazemos melhorias na plataforma.

Se você está apenas começando, confira a documentação da plataforma de identidade da Microsoft para saber mais sobre noções básicas de autenticação, cenários de aplicativos na plataforma de identidade da Microsoft e muito mais.

Use a lista de verificação a seguir para garantir que seu aplicativo seja efetivamente integrado à plataforma de identidade da Microsoft.

Noções Básicas

Leia e compreenda as Políticas da Plataforma Microsoft. Certifique-se de que seu aplicativo esteja de acordo com os termos descritos, pois eles foram projetados para proteger os usuários e a plataforma.

Propriedade

Certifique-se de que as informações associadas à conta que utilizou para registar e gerir aplicações estão atualizadas.

Imagem corporativa

Aderir às diretrizes de Branding para aplicativos.

Forneça um nome e um logotipo significativos para seu aplicativo. Essas informações aparecem no prompt de consentimento do seu aplicativo. Certifique-se de que o seu nome e logótipo são representativos da sua empresa/produto para que os utilizadores possam tomar decisões informadas. Certifique-se de que não está a violar quaisquer marcas registadas.

Privacidade

Forneça links para os termos de serviço e a declaração de privacidade do seu aplicativo.

Segurança

Gerencie seus URIs de redirecionamento:

• Mantenha a propriedade de todos os seus URIs de redirecionamento e mantenha os registros DNS para eles atualizados.
• Não use curingas (*) em seus URIs.
• Para aplicativos Web, verifique se todos os URIs são seguros e criptografados (por exemplo, usando esquemas https).
• Para clientes públicos, use URIs de redirecionamento específicos da plataforma, se aplicável (principalmente para iOS e Android). Caso contrário, use URIs de redirecionamento com uma grande quantidade de aleatoriedade para evitar colisões ao chamar de volta para seu aplicativo.
• Se o seu aplicativo estiver sendo usado a partir de um agente Web isolado, você poderá usar https://login.microsoftonline.com/common/oauth2/nativecliento .
• Revise e corte todos os URIs de redirecionamento não utilizados ou desnecessários regularmente.

Se seu aplicativo estiver registrado em um diretório, minimize e monitore manualmente a lista de proprietários de registro de aplicativo.

Não habilite o suporte para o fluxo de concessão implícito OAuth2, a menos que explicitamente necessário. Saiba mais sobre o cenário válido aqui.

Vá além do nome de usuário/senha. Não use o ROPC (resource owner password credential flow), que lida diretamente com as senhas dos usuários. Esse fluxo requer um alto grau de confiança e exposição do usuário e só deve ser usado quando outros fluxos mais seguros não puderem ser usados. Esse fluxo ainda é necessário em alguns cenários (como DevOps), mas cuidado que usá-lo imporá restrições ao seu aplicativo. Para abordagens mais modernas, leia Fluxos de autenticação e cenários de aplicativos.

Proteja e gerencie suas credenciais confidenciais de aplicativo para aplicativos Web, APIs da Web e aplicativos daemon. Use credenciais de certificado, não credenciais de senha (segredos de cliente). Se tiver de utilizar uma credencial de palavra-passe, não a defina manualmente. Não armazene credenciais em código ou configuração e nunca permita que elas sejam manipuladas por humanos. Se possível, use identidades gerenciadas para recursos do Azure ou o Cofre de Chaves do Azure para armazenar e girar regularmente suas credenciais.

Verifique se seu aplicativo solicita as permissões de menor privilégio. Peça apenas as permissões de que seu aplicativo precisa absolutamente e somente quando você precisar delas. Entenda os diferentes tipos de permissões. Use apenas as permissões do aplicativo se necessário; Use permissões delegadas sempre que possível. Para obter uma lista completa das permissões do Microsoft Graph, consulte esta referência de permissões.

Se você estiver protegendo uma API usando a plataforma de identidade da Microsoft, pense cuidadosamente nas permissões que ela deve expor. Considere qual é a granularidade certa para sua solução e quais permissões exigem o consentimento do administrador. Verifique as permissões esperadas nos tokens de entrada antes de tomar qualquer decisão de autorização.

Implementação

Utilize soluções de autenticação modernas (OAuth 2.0, OpenID Connect) para iniciar sessão de utilizadores em segurança.

Não programe diretamente contra protocolos como OAuth 2.0 e Open ID. Em vez disso, aproveite a Biblioteca de Autenticação da Microsoft (MSAL). As bibliotecas MSAL encapsulam com segurança os protocolos de segurança em uma biblioteca fácil de usar e você obtém suporte interno para cenários de Acesso Condicional, logon único (SSO) em todo o dispositivo e suporte a cache de token integrado. Para obter mais informações, consulte a lista de bibliotecas de cliente suportadas pela Microsoft. Se você deve codificar manualmente para os protocolos de autenticação, você deve seguir o Microsoft SDL ou metodologia de desenvolvimento semelhante. Preste muita atenção às considerações de segurança nas especificações de padrões para cada protocolo.

NÃO olhe para o valor do token de acesso nem tente analisá-lo como um cliente. Eles podem alterar valores, formatos ou até mesmo se tornarem criptografados sem aviso prévio - sempre use o token de ID se o seu cliente precisar aprender algo sobre o usuário. Apenas APIs da Web devem analisar tokens de acesso (já que são eles que definem o formato e definem as chaves de criptografia). Enviar um token de acesso diretamente para uma API pelo cliente é um risco de segurança, pois são credenciais confidenciais que concedem acesso a determinados recursos. Os desenvolvedores não devem presumir que o cliente pode ser confiável para validar o token de acesso.

Migre aplicativos existentes da Biblioteca de Autenticação do Ative Directory do Azure (ADAL) para a Biblioteca de Autenticação da Microsoft. MSAL é a mais recente solução de plataforma de identidade da Microsoft e está disponível em .NET, JavaScript, Android, iOS, macOS, Python e Java. Leia mais sobre como migrar aplicativos de corretagem ADAL.NET, ADAL.js e ADAL.NET e iOS.

Para aplicativos móveis, configure cada plataforma usando a experiência de registro do aplicativo. Para que seu aplicativo aproveite o Microsoft Authenticator ou o Portal da Empresa Microsoft para logon único, seu aplicativo precisa de um "URI de redirecionamento de broker" configurado. Isso permite que a Microsoft retorne o controle ao seu aplicativo após a autenticação. Ao configurar cada plataforma, a experiência de registo da aplicação irá guiá-lo ao longo do processo. Use o início rápido para baixar um exemplo de trabalho. No iOS, use corretores e webview do sistema sempre que possível.

Em aplicativos ou APIs da Web, mantenha um cache de token por conta. Para aplicativos Web, o cache de token deve ser inserido pelo ID da conta. Para as APIs Web, o hash do token utilizado para chamar a API deve criar uma chave para a conta. MSAL.NET fornece serialização de cache de token personalizado no .NET e no .NET Framework. Por motivos de segurança e desempenho, nossa recomendação é serializar um cache por usuário. Para obter mais informações, leia sobre a serialização de cache de token.

Se os dados exigidos pelo seu aplicativo estiverem disponíveis por meio do Microsoft Graph, solicite permissões para esses dados usando o ponto de extremidade do Microsoft Graph em vez da API individual.

Experiência do utilizador final

Entenda a experiência de consentimento e configure as partes do prompt de consentimento do seu aplicativo para que os usuários finais e administradores tenham informações suficientes para determinar se confiam no seu aplicativo.

Minimize o número de vezes que um usuário precisa inserir credenciais de login ao usar seu aplicativo tentando autenticação silenciosa (aquisição silenciosa de tokens) antes de fluxos interativos.

Não use "prompt=consent" para cada login. Use prompt=consent apenas se você determinou que precisa pedir consentimento para permissões adicionais (por exemplo, se você alterou as permissões necessárias do seu aplicativo).

Quando aplicável, enriqueça seu aplicativo com dados do usuário. Usar a API do Microsoft Graph é uma maneira fácil de fazer isso. A ferramenta Graph Explorer que pode ajudá-lo a começar.

Registe o conjunto completo de permissões que a sua aplicação requer para que os administradores possam conceder consentimento facilmente ao seu inquilino. Use o consentimento incremental em tempo de execução para ajudar os usuários a entender por que seu aplicativo está solicitando permissões que podem preocupar ou confundir os usuários quando solicitado na primeira inicialização.

Implemente uma experiência de saída única limpa. É um requisito de privacidade e segurança, e contribui para uma boa experiência do usuário.

Testar

Teste as políticas de Acesso Condicional que podem afetar a capacidade dos usuários de usar seu aplicativo.

Teste seu aplicativo com todas as contas possíveis que você planeja oferecer suporte (por exemplo, contas corporativas ou de estudante, contas pessoais da Microsoft, contas de criança e contas soberanas).

Recursos adicionais

Explore informações aprofundadas sobre o v2.0:

• Plataforma de identidade da Microsoft (visão geral)
• Referência de protocolos de plataforma de identidade da Microsoft
• Referência de tokens de acesso
• Referência de tokens de ID
• Referência de bibliotecas de autenticação
• Permissões e consentimento na plataforma de identidades da Microsoft
• Microsoft Graph API