O que há de novo na autenticação?

A Microsoft adiciona e modifica periodicamente os recursos e a funcionalidade da plataforma de identidade da Microsoft para melhorar sua segurança, usabilidade e conformidade com os padrões.

Salvo indicação em contrário, as alterações aqui descritas aplicam-se apenas a aplicações registadas após a data de entrada em vigor declarada da alteração.

Consulte este artigo regularmente para saber mais sobre:

• Problemas conhecidos e correções
• Alterações ao protocolo
• Funcionalidade preterida

Agosto de 2024

As Credenciais de Identidade Federada agora usam correspondência que diferencia maiúsculas de minúsculas

Data de entrada em vigor: setembro de 2024

Protocolo afetado: federação de identidades de carga de trabalho

Alterar

Anteriormente, ao fazer a correspondência entre a Credencial de Identidade Federada (FIC) , e os valores em relação ao , issuersubjectcorrespondente , e audience os valores contidos no token enviado ao Microsoft Entra ID por um IdP externo, a correspondência sem diferenciação de maiúsculas e minúsculas era usada.audience subjectissuer Para fornecer um controle mais refinado aos clientes, estamos mudando para a imposição de correspondência sensível a maiúsculas e minúsculas.

Exemplo inválido:

• Assunto do token: repo:contoso/contoso-org:ref:refs/heads/main
• Assunto FIC: repo:Contoso/Contoso-Org:ref:refs/heads/main

Esses dois valores de assunto não diferenciam maiúsculas de minúsculas, portanto, a validação falha. O mesmo mecanismo é aplicado e issuer audience validado.

Essa alteração será aplicada inicialmente a aplicativos ou identidades gerenciadas criadas após August 14th, 2024. Aplicativos inativos ou identidades gerenciadas, determinados por não haver solicitações de Federação de Identidade de Carga de Trabalho feitas por esse aplicativo ou identidade gerenciada entre o período August 1st, 2024 para August 31st, 2024, são necessários para usar a correspondência que diferencia maiúsculas de minúsculas iniciando September 27th, 2024. Para aplicativos ativos, a correspondência sem diferenciação de maiúsculas e minúsculas vem em uma data posterior para ser comunicada.

Para destacar melhor as falhas devido à insensibilidade a maiúsculas e minúsculas, estamos reformulando a mensagem de erro para AADSTS700213. Irá agora declarar;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

O espaço reservado '{subject}' fornece o valor da declaração de assunto contida no token que está sendo enviado do IdP externo para o ID do Microsoft Entra. Este modelo de erro também é usado para falhas que não diferenciam maiúsculas de minúsculas ao redor issuer e audience validação. Se você encontrar esse erro, deverá encontrar a Credencial de Identidade Federada que corresponde ao issuer, subjectou audience listada no erro e confirmar se os valores correspondentes são equivalentes de uma perspetiva que diferencia maiúsculas de minúsculas. Se houver uma incompatibilidade, você precisará substituir o valor atual issuer, subjectou audience no FIC pelo issuer, subjectou audience valor contido na mensagem de erro.

junho de 2024

As candidaturas devem ser registadas numa lista

Data de entrada em vigor: junho de 2024

Pontos de extremidade afetados: v2.0 e v1.0

Protocolo afetado: Todos os fluxos

Alterar

Anteriormente, ao registrar um aplicativo usando a experiência de registros de aplicativos do Microsoft Entra, se o usuário estivesse conectado com sua conta pessoal da Microsoft (MSA), ele poderia optar por associar apenas o aplicativo à sua conta pessoal. Isso significa que o aplicativo não estaria associado ou contido em nenhum diretório (também conhecido como 'locatário' ou 'organização'). No entanto, a partir de junho de 2024, todas as candidaturas têm de ser registadas num diretório. Pode ser um diretório existente ou um novo diretório que o usuário da conta pessoal da Microsoft cria para abrigar seus aplicativos Microsoft Entra e outros recursos da Microsoft. Os usuários podem criar facilmente um novo diretório para usar para essa finalidade ingressando no Microsoft 365 Developer Program ou inscrevendo-se no Azure.

Registrar um aplicativo em um diretório, em vez de apenas associá-lo a uma conta pessoal, tem vários benefícios. Estes são, entre outros:

• Os aplicativos registrados em um diretório têm mais recursos disponíveis, como a capacidade de adicionar mais de um proprietário ao aplicativo e a capacidade de verificar o aplicativo pelo editor.
• O aplicativo está localizado no mesmo local que outros recursos da Microsoft que o desenvolvedor usa, como recursos do Azure.
• O aplicativo recebe benefícios de resiliência aprimorados.

Isso não afetará nenhum aplicativo existente, incluindo aplicativos existentes que estão associados apenas a uma conta pessoal. Apenas a capacidade de registar novas candidaturas será afetada.

Outubro de 2023

Prompt de experiência do usuário do RemoteConnect atualizado

Data de entrada em vigor: outubro de 2023

Pontos de extremidade afetados: v2.0 e v1.0

Protocolo afetado: RemoteConnect

O RemoteConnect é um fluxo entre dispositivos usado para cenários relacionados ao Microsoft Authentication Broker e ao Microsoft Intune envolvendo Tokens de Atualização Primária. Para ajudar a evitar ataques de phishing, o fluxo do RemoteConnect está recebendo linguagem UX atualizada para chamar a atenção de que o dispositivo remoto (o dispositivo que iniciou o fluxo) poderá acessar todos os aplicativos usados pela sua organização após a conclusão bem-sucedida do fluxo.

O prompt que aparece terá a seguinte aparência:

Junho de 2023

Omissão de reclamações de e-mail com um proprietário de domínio não verificado

Data de entrada em vigor: junho de 2023

Pontos de extremidade afetados: v2.0 e v1.0

Alterar

Para aplicativos multilocatário, os e-mails que não são verificados pelo proprietário do domínio são omitidos por padrão quando a declaração opcional email é solicitada em uma carga útil de token.

Um e-mail é considerado verificado pelo proprietário do domínio se:

1. O domínio pertence ao locatário onde a conta de usuário reside e o administrador do locatário fez a verificação do domínio.
2. O email é de uma Conta da Microsoft (MSA).
3. O e-mail é de uma Conta do Google.
4. O e-mail foi usado para autenticação usando o fluxo de senha única (OTP).

Também deve ser notado que as contas do Facebook e SAML/WS-Fed não têm domínios verificados.

Maio de 2023

A função de administrador do Power BI será renomeada para Administrador de Malha.

Data de entrada em vigor: junho de 2023

Pontos finais afetados:

• Listar roleDefinitions - Microsoft Graph v1.0
• Listar directoryRoles - Microsoft Graph v1.0

Alterar

A função Administrador do Power BI é renomeada para Administrador de Malha.

Em 23 de maio de 2023, a Microsoft apresentou o Microsoft Fabric, que oferece uma experiência de integração de dados alimentada pelo Data Factory, engenharia de dados alimentada pela Synapse, data warehouse, ciência de dados e experiências de análise em tempo real e business intelligence (BI) com o Power BI — tudo hospedado em uma solução SaaS centrada no lago. A administração do locatário e da capacidade para essas experiências é centralizada no portal de Administração da Malha (anteriormente conhecido como portal de administração do Power BI).

A partir de junho de 2023, a função de Administrador do Power BI é renomeada para Administrador de Malha para se alinhar com a mudança de escopo e responsabilidade dessa função. Todos os aplicativos, incluindo Microsoft Entra ID, Microsoft Graph APIs, Microsoft 365 e GDAP, começarão a refletir o novo nome da função ao longo de várias semanas.

Como lembrete, o código e os scripts do aplicativo não devem tomar decisões com base no nome da função ou no nome para exibição.

Dezembro de 2021

Os usuários do AD FS verão mais solicitações de logon para garantir que o usuário correto esteja conectado.

Data de entrada em vigor: dezembro de 2021

Pontos de extremidade afetados: Autenticação integrada do Windows

Protocolo afetado: Autenticação Integrada do Windows

Alterar

Hoje, quando um usuário é enviado ao AD FS para autenticação, ele será conectado silenciosamente em qualquer conta que já tenha uma sessão com o AD FS. O início de sessão silencioso ocorre mesmo que o utilizador pretenda iniciar sessão numa conta de utilizador diferente. Para reduzir a frequência com que esta entrada incorreta ocorre, a partir de dezembro, o Microsoft Entra ID enviará o parâmetro para o prompt=login AD FS se o Gestor de Conta Web no Windows fornecer o ID do Microsoft Entra a durante o login_hint início de sessão, o que indica que um utilizador específico é pretendido para iniciar sessão.

Quando os requisitos acima forem atendidos (o WAM é usado para enviar o usuário para o Microsoft Entra ID para entrar, um login_hint é incluído e a instância do AD FS para o domínio do usuário oferece suporte prompt=login), o usuário não será conectado silenciosamente e, em vez disso, solicitado a fornecer um nome de usuário para continuar entrando no AD FS. Se desejarem entrar em sua sessão existente do AD FS, eles podem selecionar a opção "Continuar como usuário atual" exibida abaixo do prompt de login. Caso contrário, eles podem continuar com o nome de usuário com o qual pretendem entrar.

Esta alteração será implementada em dezembro de 2021 ao longo de várias semanas. Não altera o comportamento de início de sessão para:

• Aplicativos que usam IWA diretamente
• Aplicativos usando OAuth
• Domínios que não são federados a uma instância do AD FS

Outubro de 2021

O erro 50105 foi corrigido para não retornar interaction_required durante a autenticação interativa

Data de entrada em vigor: outubro de 2021

Pontos de extremidade afetados: v2.0 e v1.0

Protocolo afetado: todos os fluxos de usuário para aplicativos que exigem atribuição de usuário

Alterar

O erro 50105 (a designação atual) é emitido quando um usuário não atribuído tenta entrar em um aplicativo que um administrador marcou como exigindo atribuição de usuário. Esse é um padrão comum de controle de acesso, e os usuários geralmente devem encontrar um administrador para solicitar uma atribuição para desbloquear o acesso. O erro tinha um bug que causaria loops infinitos em aplicativos bem codificados que manipulavam corretamente a resposta de interaction_required erro. interaction_required diz a um aplicativo para executar a autenticação interativa, mas mesmo depois de fazê-lo, o Microsoft Entra ID ainda retornaria uma resposta de interaction_required erro.

O cenário de erro foi atualizado, de modo que, durante a autenticação não interativa (onde prompt=none é usado para ocultar a UX), o aplicativo será instruído a executar a autenticação interativa usando uma interaction_required resposta de erro. Na autenticação interativa subsequente, o Microsoft Entra ID agora manterá o usuário e mostrará uma mensagem de erro diretamente, impedindo que um loop ocorra.

Como lembrete, o código do aplicativo não deve tomar decisões com base em cadeias de caracteres de código de erro como AADSTS50105. Em vez disso, siga nossas diretrizes de tratamento de erros e use as respostas de autenticação padronizadas como interaction_required e login_required encontradas no campo padrão error na resposta. Os outros campos de resposta destinam-se ao consumo apenas por seres humanos que resolvem os seus problemas.

Você pode revisar o texto atual do erro 50105 e muito mais no serviço de pesquisa de erros: https://login.microsoftonline.com/error?code=50105.

O Uri do AppId em aplicativos de locatário único exigirá o uso de esquema padrão ou domínios verificados

Data de entrada em vigor: outubro de 2021

Pontos de extremidade afetados: v2.0 e v1.0

Protocolo afetado: Todos os fluxos

Alterar

Para aplicativos de locatário único, adicionar ou atualizar o URI do AppId valida que o domínio no URI do esquema HTTPS está listado na lista de domínios verificados no locatário do cliente ou que o valor usa o esquema padrão (api://{appId}) fornecido pelo ID do Microsoft Entra. Isso pode impedir que os aplicativos adicionem um URI AppId se o domínio não estiver na lista de domínios verificados ou se o valor não usar o esquema padrão. Para encontrar mais informações sobre domínios verificados, consulte a documentação de domínios personalizados.

A alteração não afeta as aplicações existentes que utilizam domínios não verificados no URI de AppID. Ele valida apenas novos aplicativos ou quando um aplicativo existente atualiza um URI de identificador ou adiciona um novo à coleção identifierUri. As novas restrições se aplicam apenas aos URIs adicionados à coleção de identificador de um aplicativo após 15 de outubro de 2021. Os URIs AppId já na coleção identifierUris de um aplicativo quando a restrição entrar em vigor em 15 de outubro de 2021 continuarão a funcionar mesmo se você adicionar novos URIs a essa coleção.

Se uma solicitação falhar na verificação de validação, a API do aplicativo para criar/atualizar retornará um 400 badrequest para o cliente indicando HostNameNotOnVerifiedDomain.

Os seguintes formatos de URI de ID de aplicativo baseados em esquema API e HTTP são suportados. Substitua os valores de espaço reservado conforme descrito na lista a seguir à tabela.

ID do aplicativo suportado Formatos de URI	Exemplo de URIs de ID de aplicativo
api://< appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://< tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://< tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://< string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://< tenantInitialDomain.onmicrosoft.com/>< string>	https://contoso.onmicrosoft.com/productsapi
https://< verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://< string>.<verificadoCustomDomain>	https://product.contoso.com
https://< string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> - A propriedade application identifier (appId) do objeto do aplicativo.
• <string> - O valor da cadeia de caracteres para o host ou o segmento do caminho da api.
• <tenantId> - Um GUID gerado pelo Azure para representar o locatário no Azure.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, onde< tenantInitialDomain> é o nome de domínio inicial que o criador do locatário especificou na criação do locatário.
• <verifiedCustomDomain> - Um domínio personalizado verificado configurado para seu locatário do Microsoft Entra.

Agosto de 2021

O Acesso Condicional só será acionado para escopos explicitamente solicitados

Data de vigência: agosto de 2021, com implantação gradual a partir de abril.

Pontos finais afetados: v2.0

Protocolo afetado: Todos os fluxos usando consentimento dinâmico

Os aplicativos que usam o consentimento dinâmico hoje recebem todas as permissões para as quais têm consentimento, mesmo que não tenham sido solicitados pelo nome no scope parâmetro. Um aplicativo solicitando apenas user.read , mas com consentimento, files.read pode ser forçado a passar o requisito de Acesso Condicional atribuído para files.read, por exemplo.

Para reduzir o número de prompts de Acesso Condicional desnecessários, a ID do Microsoft Entra está alterando a maneira como os escopos são fornecidos aos aplicativos para que apenas os escopos explicitamente solicitados acionem o Acesso Condicional. Os aplicativos que dependem do comportamento anterior do Microsoft Entra ID de incluir todos os escopos no token, solicitados ou não, podem quebrar devido à falta de escopos.

Os aplicativos agora receberão tokens de acesso com uma combinação de permissões: tokens solicitados e aqueles para os quais eles têm consentimento que não exigem prompts de Acesso Condicional. O escopo de acesso para o token é refletido no parâmetro de scope resposta do token.

Essa alteração será feita para todos os aplicativos, exceto aqueles com uma dependência observada desse comportamento. Os desenvolvedores receberão divulgação se estiverem isentos dessa alteração, pois podem depender dos prompts adicionais de Acesso Condicional.

Exemplos

Uma aplicação tem consentimento para user.read, files.readwritee tasks.read. files.readwrite tem políticas de Acesso Condicional aplicadas a ele, enquanto as outras duas não. Se um aplicativo fizer uma solicitação de token para scope=user.reado , e o usuário conectado no momento não tiver passado por nenhuma política de Acesso Condicional, o token resultante será para as user.read permissões e tasks.read . tasks.read está incluído porque a aplicação tem consentimento para o mesmo e não requer que uma política de Acesso Condicional seja imposta.

Se o aplicativo solicitar scope=files.readwrite, o Acesso Condicional exigido pelo locatário será acionado, forçando o aplicativo a mostrar um prompt de autenticação interativo onde a política de Acesso Condicional pode ser satisfeita. O token retornado terá todos os três escopos.

Se o aplicativo fizer uma última solicitação para qualquer um dos três escopos (digamos, scope=tasks.read), o ID do Microsoft Entra verá que o usuário já concluiu as políticas de Acesso Condicional necessárias para files.readwriteo e emitirá novamente um token com todas as três permissões.

Junho de 2021

A UX do fluxo de código do dispositivo agora incluirá um prompt de confirmação do aplicativo

Data de entrada em vigor: junho de 2021.

Pontos de extremidade afetados: v2.0 e v1.0

Protocolo afetado: O fluxo de código do dispositivo

Para ajudar a evitar ataques de phishing, o fluxo de código do dispositivo agora inclui um prompt que valida que o usuário está entrando no aplicativo esperado.

O prompt que aparece tem esta aparência:

Maio de 2020

Correção de bug: Microsoft Entra ID não irá mais URL-codificar o parâmetro state duas vezes

Data de entrada em vigor: maio de 2021

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: todos os fluxos que visitam o ponto de extremidade (fluxo implícito e fluxo de /authorize código de autorização)

Um bug foi encontrado e corrigido na resposta de autorização do Microsoft Entra. Durante a /authorize etapa de autenticação, o state parâmetro da solicitação é incluído na resposta, para preservar o estado do aplicativo e ajudar a evitar ataques CSRF. O Microsoft Entra ID codificou incorretamente o state parâmetro por URL antes de inseri-lo na resposta, onde foi codificado mais uma vez. Isso resultaria em aplicativos rejeitando incorretamente a resposta do Microsoft Entra ID.

O Microsoft Entra ID não codificará mais duas vezes esse parâmetro, permitindo que os aplicativos analisem corretamente o resultado. Esta alteração será feita para todas as candidaturas.

Os pontos de extremidade do Azure Government estão mudando

Data de entrada em vigor: 5 de maio de 2020 (Término em junho de 2020)

Pontos finais afetados: Todos

Protocolo afetado: Todos os fluxos

Em 1 de junho de 2018, a autoridade oficial do Microsoft Entra para o Azure Government mudou de https://login-us.microsoftonline.com para https://login.microsoftonline.us. Essa alteração também se aplicou ao Microsoft 365 GCC High e DoD, que o Azure Government Microsoft Entra ID também atende. Se você possui um aplicativo dentro de um locatário do governo dos EUA, você deve atualizar seu aplicativo para entrar usuários no ponto de .us extremidade.

Em 5 de maio de 2020, o Microsoft Entra ID começará a aplicar a alteração do ponto de extremidade, bloqueando os usuários do governo de entrar em aplicativos hospedados em locatários do governo dos EUA usando o ponto de extremidade público (microsoftonline.com). As aplicações afetadas começarão a ver um erro AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Esse erro indica que o aplicativo está tentando entrar em um usuário do governo dos EUA no ponto de extremidade de nuvem pública. Se o seu aplicativo estiver em um locatário de nuvem pública e se destinar a oferecer suporte a usuários do governo dos EUA, você precisará atualizá-lo para suportá-los explicitamente. Isso pode exigir a criação de um novo registro de aplicativo na nuvem do governo dos EUA.

A aplicação desta alteração será feita através de uma implementação gradual com base na frequência com que os utilizadores da nuvem do Governo dos EUA iniciam sessão na aplicação – as aplicações que iniciam sessão em utilizadores do Governo dos EUA raramente verão a aplicação em primeiro lugar e as aplicações frequentemente utilizadas por utilizadores do Governo dos EUA serão as últimas a ter a aplicação da aplicação. Esperamos que a aplicação esteja completa em todos os aplicativos em junho de 2020.

Para obter mais detalhes, consulte a postagem do blog do Azure Government sobre essa migração.

Março de 2020

As senhas de usuário serão restritas a 256 caracteres.

Data de entrada em vigor: 13 de março de 2020

Pontos finais afetados: Todos

Protocolo afetado: Todos os fluxos de usuários.

Os utilizadores com palavras-passe com mais de 256 caracteres que iniciam sessão diretamente no Microsoft Entra ID (não num IDP federado, como o AD FS) serão solicitados a alterar as respetivas palavras-passe antes de poderem iniciar sessão. Os administradores podem receber solicitações para ajudar a redefinir a senha do usuário.

O erro nos logs de entrada será semelhante ao AADSTS 50052: InvalidPasswordExceedsMaxLength.

Mensagem: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Remediação:

O utilizador não consegue iniciar sessão porque a sua palavra-passe excede o comprimento máximo permitido. Eles devem entrar em contato com o administrador para redefinir a senha. Se o SSPR estiver habilitado para seu locatário, ele poderá redefinir sua senha seguindo o link "Esqueceu sua senha".

Fevereiro de 2020

Fragmentos vazios serão anexados a cada redirecionamento HTTP a partir do ponto de extremidade de login.

Data de entrada em vigor: 8 de fevereiro de 2020

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: fluxos OAuth e OIDC que usam response_type=query - isso abrange o fluxo de código de autorização em alguns casos e o fluxo implícito.

Quando uma resposta de autenticação é enviada de login.microsoftonline.com para um aplicativo via redirecionamento HTTP, o serviço acrescentará um fragmento vazio à URL de resposta. Isso evita uma classe de ataques de redirecionamento, garantindo que o navegador elimine qualquer fragmento existente na solicitação de autenticação. Nenhum aplicativo deve ter uma dependência desse comportamento.

Agosto de 2019

A semântica do formulário POST será aplicada de forma mais rigorosa - espaços e aspas serão ignorados

Data de entrada em vigor: 2 de setembro de 2019

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: em qualquer lugar onde o POST é usado (credenciais de cliente, resgate de código de autorização, ROPC, OBO e resgate de token de atualização)

A partir da semana de 2 de setembro de 2019, as solicitações de autenticação que usam o método POST serão validadas usando padrões HTTP mais rígidos. Especificamente, espaços e aspas duplas (") não serão mais removidos dos valores do formulário de solicitação. Não se espera que essas alterações quebrem nenhum cliente existente e garantirão que as solicitações enviadas para o Microsoft Entra ID sejam sempre tratadas de forma confiável. No futuro (veja acima), planejamos rejeitar adicionalmente parâmetros duplicados e ignorar a lista técnica dentro das solicitações.

Exemplo:

Hoje, ?e= "f"&g=h é analisado de forma idêntica como ?e=f&g=h - assim == ef . Com esta alteração, seria agora analisado de modo a - é improvável que e == "f" este seja um argumento válido, e o pedido falharia agora.

Julho de 2019

Os tokens somente de aplicativo para aplicativos de locatário único só são emitidos se o aplicativo cliente existir no locatário de recurso

Data de entrada em vigor: 26 de julho de 2019

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: Credenciais do cliente (tokens somente de aplicativo)

Uma alteração de segurança entrou em vigor em 26 de julho de 2019, alterando a forma como os tokens somente de aplicativo (por meio da concessão de credenciais do cliente) são emitidos. Anteriormente, os aplicativos tinham permissão para obter tokens para chamar qualquer outro aplicativo, independentemente da presença no locatário ou das funções consentidas para esse aplicativo. Esse comportamento foi atualizado para que, para recursos (às vezes chamados de APIs da Web) definidos como locatário único (o padrão), o aplicativo cliente deve existir dentro do locatário de recurso. O consentimento existente entre o cliente e a API ainda não é necessário, e os aplicativos ainda devem fazer suas próprias verificações de autorização para garantir que uma roles declaração esteja presente e contenha o valor esperado para a API.

A mensagem de erro para este cenário atualmente afirma:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Para resolver esse problema, use a experiência de Consentimento do Administrador para criar a entidade de serviço do aplicativo cliente em seu locatário ou crie-a manualmente. Esse requisito garante que o locatário tenha dado permissão ao aplicativo para operar dentro do locatário.

Pedido de exemplo

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... Neste exemplo, o locatário de recurso (autoridade) é contoso.com, o aplicativo de recurso é um aplicativo de locatário único chamado gateway.contoso.com/api para o locatário da Contoso e o aplicativo cliente é 00001111-aaaa-2222-bbbb-3333cccc4444. Se o aplicativo cliente tiver uma entidade de serviço dentro Contoso.com, essa solicitação poderá continuar. Se isso não acontecer, no entanto, a solicitação falhará com o erro acima.

No entanto, se o aplicativo de gateway da Contoso fosse um aplicativo multilocatário, a solicitação continuaria independentemente de o aplicativo cliente ter uma entidade de serviço dentro Contoso.com.

Os URIs de redirecionamento agora podem conter parâmetros de cadeia de caracteres de consulta

Data de entrada em vigor: 22 de julho de 2019

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: Todos os fluxos

De acordo com o RFC 6749, os aplicativos Microsoft Entra agora podem registrar e usar URIs de redirecionamento (resposta) com parâmetros de consulta estáticos (como https://contoso.com/oauth2?idp=microsoft) para solicitações OAuth 2.0. Os URIs de redirecionamento dinâmico ainda são proibidos, pois representam um risco de segurança, e isso não pode ser usado para reter informações de estado em uma solicitação de autenticação - para isso, use o state parâmetro.

O parâmetro de consulta estática está sujeito à correspondência de cadeia de caracteres para URIs de redirecionamento como qualquer outra parte do URI de redirecionamento - se nenhuma cadeia de caracteres for registrada que corresponda ao redirect_uri decodificado por URI, a solicitação será rejeitada. Se o URI for encontrado no registro do aplicativo, toda a cadeia de caracteres será usada para redirecionar o usuário, incluindo o parâmetro de consulta estática.

Neste momento (final de julho de 2019), a experiência do usuário de registro do aplicativo no portal do Azure ainda bloqueia os parâmetros de consulta. No entanto, você pode editar o manifesto do aplicativo manualmente para adicionar parâmetros de consulta e testar isso em seu aplicativo.

Março de 2019

Os clientes de looping serão interrompidos

Data de entrada em vigor: 25 de março de 2019

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: Todos os fluxos

Por vezes, as aplicações cliente podem comportar-se mal, emitindo centenas do mesmo pedido de início de sessão durante um curto período de tempo. Essas solicitações podem ou não ser bem-sucedidas, mas todas contribuem para uma experiência ruim do usuário e cargas de trabalho aumentadas para o IDP, aumentando a latência para todos os usuários e reduzindo a disponibilidade do IDP. Esses aplicativos estão operando fora dos limites do uso normal e devem ser atualizados para se comportarem corretamente.

Os clientes que emitirem solicitações duplicadas várias vezes receberão um invalid_grant erro: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

A maioria dos clientes não precisará alterar o comportamento para evitar esse erro. Somente clientes mal configurados (aqueles sem cache de token ou aqueles que já exibem loops de prompt) serão afetados por esse erro. Os clientes são rastreados por instância localmente (via cookie) nos seguintes fatores:

• Dica do usuário, se houver

• Escopos ou recursos que estão sendo solicitados

• ID de Cliente

• Redirecionar URL

• Tipo e modo de resposta

Os aplicativos que fizerem várias solicitações (15+) em um curto período de tempo (5 minutos) receberão um invalid_grant erro explicando que estão fazendo looping. Os tokens solicitados têm vida útil suficientemente longa (10 minutos no mínimo, 60 minutos por padrão), portanto, solicitações repetidas durante esse período de tempo são desnecessárias.

Todos os aplicativos devem lidar mostrando invalid_grant um prompt interativo, em vez de solicitar silenciosamente um token. Para evitar esse erro, os clientes devem garantir que estão armazenando corretamente em cache os tokens que recebem.

Outubro de 2018

Os códigos de autorização já não podem ser reutilizados

Data de entrada em vigor: 15 de novembro de 2018

Pontos finais afetados: v1.0 e v2.0

Protocolo afetado: fluxo de código

A partir de 15 de novembro de 2018, o Microsoft Entra ID deixará de aceitar códigos de autenticação usados anteriormente para aplicativos. Essa alteração de segurança ajuda a alinhar a ID do Microsoft Entra com a especificação OAuth e será aplicada nos pontos de extremidade v1 e v2.

Se seu aplicativo reutilizar códigos de autorização para obter tokens para vários recursos, recomendamos que você use o código para obter um token de atualização e, em seguida, use esse token de atualização para adquirir tokens adicionais para outros recursos. Os códigos de autorização só podem ser usados uma vez, mas os tokens de atualização podem ser usados várias vezes em vários recursos. Qualquer novo aplicativo que tente reutilizar um código de autenticação durante o fluxo de código OAuth receberá um erro invalid_grant.

Para obter mais informações sobre tokens de atualização, consulte Atualizando os tokens de acesso. Se estiver usando ADAL ou MSAL, isso será tratado para você pela biblioteca - substitua a segunda instância de AcquireTokenByAuthorizationCodeAsync por AcquireTokenSilentAsync.

Maio de 2018

Os tokens de ID não podem ser usados para o fluxo OBO

Data: 1 de maio de 2018

Pontos finais afetados: v1.0 e v2.0

Protocolos afetados: fluxo implícito e fluxo em nome

Após 1º de maio de 2018, id_tokens não pode ser usado como afirmação em um fluxo OBO para novos aplicativos. Em vez disso, os tokens de acesso devem ser usados para proteger APIs, mesmo entre um cliente e a camada intermediária do mesmo aplicativo. As aplicações registadas antes de 1 de maio de 2018 continuarão a funcionar e poderão trocar id_tokens por um token de acesso; no entanto, esse padrão não é considerado uma prática recomendada.

Para contornar essa alteração, você pode fazer o seguinte:

1. Crie uma API da Web para seu aplicativo, com um ou mais escopos. Este ponto de entrada explícito permitirá um controlo e segurança mais refinados.
2. No manifesto do seu aplicativo, no portal do Azure ou no portal de registro do aplicativo, verifique se o aplicativo tem permissão para emitir tokens de acesso por meio do fluxo implícito. Isso é controlado através da oauth2AllowImplicitFlow chave.
3. Quando seu aplicativo cliente solicitar um id_token via response_type=id_token, solicite também um token de acesso (response_type=token) para a API da Web criada acima. Assim, ao usar o ponto de extremidade v2.0, o scope parâmetro deve ser semelhante ao api://GUID/SCOPE. No ponto de extremidade v1.0, o resource parâmetro deve ser o URI do aplicativo da API da Web.
4. Passe esse token de acesso para a camada intermediária no lugar do id_token.