Quais são as novidades para autenticação?

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

A menos que indicado de outra forma, as alterações descritas aqui se aplicam somente aos aplicativos registrados após a data efetiva declarada da alteração.

Verifique este artigo regularmente para saber mais sobre:

• Problemas conhecidos e correções
• Alterações do protocolo
• Funcionalidades preteridas

Dica

Para ser notificado sobre as atualizações desta página, adicione esta URL ao seu leitor de feed RSS:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Outubro de 2023

Prompt de UX do RemoteConnect atualizado

Data de início de vigência: outubro de 2023

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

Protocolo afetado: RemoteConnect

RemoteConnect é um fluxo entre dispositivos usado para cenários relacionados ao Microsoft Authentication Broker e ao Microsoft Intune envolvendo Tokens de Atualização Primários. Para ajudar a evitar ataques de phishing, o fluxo RemoteConnect receberá uma linguagem de UX atualizada para chamar 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 exibido terá esta aparência:

Junho de 2023

Omissão de declarações de email com um proprietário de domínio não verificado

Data de efetivação: junho de 2023

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

Alteração

Para aplicativos multilocatários, os emails 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 um conteúdo de token.

Um email será considerado proprietário do domínio verificado se:

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

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

Maio de 2023

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

Data de efetivação: junho de 2023

Pontos de extremidade afetados:

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

Alteração

A função Administrador do Power BI será renomeada para Administrador do Fabric.

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

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

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

Dezembro de 2021

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

Data de início de vigência: dezembro 2021

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

Protocolo impactado: autenticação integrada do Windows

Alteração

Hoje, quando um usuário é enviado ao AD FS para autenticação, ele será conectado silenciosamente a qualquer conta que já tenha uma sessão válida com o AD FS. Essa entrada silenciosa ocorre mesmo que o usuário tenha a intenção de entrar em outra conta de usuário. Para reduzir a frequência dessa entrada incorreta, a partir de dezembro, o Microsoft Entra ID enviará o parâmetro prompt=login para o AD FS se o Gerenciador de Contas da Web (WAM) no Windows fornecer ao Microsoft Entra ID um login_hint durante o logon, o que indica que a entrada de um usuário específico é desejada.

Quando os requisitos acima são atendidos (o WAM é usado para direcionar o usuário ao 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 a prompt=login), o usuário não é silenciosamente conectado e, em vez disso, é solicitado a fornecer um nome de usuário para continuar a entrar no AD FS. Se quiserem entrar na sessão do AD FS existente, eles poderão selecionar a opção "Continuar como usuário atual", exibida abaixo do prompt de logon. Caso contrário, eles podem continuar com o nome de usuário com o qual pretendem entrar.

Essa alteração será distribuída em dezembro de 2021 ao longo de várias semanas. Isso não altera o comportamento de entrada para:

• Aplicativos que usam IWA diretamente
• Aplicativos que usam OAuth
• Domínios que não são federados para 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 início de vigência: 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

Alteração

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 com exigência de atribuição de usuário. Esse é um padrão de controle de acesso comum; os usuários geralmente devem procurar um administrador para solicitar a atribuição a fim de desbloquear o acesso. O erro tinha um bug que poderia causar loops infinitos em aplicativos bem codificados que manipulavam corretamente a resposta de erro interaction_required. interaction_required instrui um aplicativo a executar a autenticação interativa, mas mesmo depois disso, o Microsoft Entra ID ainda retorna uma resposta de erro interaction_required.

O cenário de erro foi atualizado, de modo que durante a autenticação não interativa (em que prompt=none é usado para ocultar o a experiência do usuário), o aplicativo será instruído a executar a autenticação interativa usando uma resposta de erro interaction_required. Na autenticação interativa subsequente, o Microsoft Entra ID 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 da resposta. Os outros campos de resposta destinam-se apenas ao consumo por seres humanos que solucionam problemas.

Você pode examinar o texto atual do erro 50105 e muito mais no serviço de pesquisa de erro: 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 início de vigência: outubro de 2021

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

Protocolo afetado: todos os fluxos

Altere

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

A alteração não afeta os aplicativos existentes que usam domínios não verificados em seu URI do AppID. Ele valida somente novos aplicativos, ou quando um aplicativo existente atualiza URIs de identificador, ou adiciona um novo à coleção identifierUri. As novas restrições se aplicam somente a URIs adicionados à coleção identifierUris de um aplicativo após o dia 15 de outubro de 2021. Os URIs do AppId que já estiverem na coleção identifierUris de um aplicativo quando a restrição entrar em vigor, no dia 15 de outubro de 2021, continuarão a funcionar mesmo que você adicione 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.

Há suporte para os seguintes formatos de URI de ID de aplicativo baseados em esquema HTTP e API. Substitua os valores nos espaços reservados conforme descrito na lista após a tabela.

ID do aplicativo com suporte Formatos de URI	URIs de ID do aplicativo de exemplo
api://<appId>	api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<appId>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<string>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api
api://<string>/<appId>	api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> - A propriedade do identificador de aplicativo (appId) do objeto de aplicativo.
• <string> - O valor da cadeia de caracteres do host ou do segmento de linha da AP.
• <tenantId> - Um GUID gerado pelo Azure para representar o locatário no Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, em que <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 que foi configurado para seu locatário do Microsoft Entra.

Observação

Ao usar o esquema api://, adicione um valor de cadeia de caracteres diretamente após "api://". Por exemplo, api://<string>. Esse valor de cadeia de caracteres pode ser um GUID ou uma cadeia de caracteres arbitrária. Se você adicionar um valor de GUID, ele deverá corresponder à ID do aplicativo ou à ID do locatário. O valor do URI da ID do aplicativo deve ser exclusivo para seu locatário. Se você adicionar api://<tenantId> como o URI da ID do aplicativo, ninguém mais poderá usar esse URI em nenhum outro aplicativo. Recomenda-se usar api://<appId> ou o esquema HTTP como alternativa.

Importante

O valor do URI da ID do aplicativo não deve terminar com um caractere "/" de barra.

Observação

Embora seja seguro remover os identifierUris para registros de aplicativo dentro do locatário atual, a remoção do identifierUris pode fazer com que os clientes falhem para outros registros de aplicativo.

Agosto de 2021

O acesso condicional só será disparado para escopos explicitamente solicitados

Data de entrada em vigor: agosto de 2021, com distribuição gradual a partir de abril.

Pontos de extremidade afetados: v2.0

Protocolo afetado: todos os fluxos usando o consentimento dinâmico

Atualmente, os aplicativos que usam o consentimento dinâmico recebem todas as permissões para as quais eles têm consentimento, mesmo que não tenham sido solicitados por nome no parâmetro scope. Um aplicativo que solicita apenas user.read, mas com consentimento para 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, o Microsoft Entra ID está alterando a forma como os escopos são fornecidos aos aplicativos, para que somente os escopos explicitamente solicitados disparem o acesso condicional. Os aplicativos que dependem do comportamento anterior do Microsoft Entra ID de incluir todos os escopos no token, quer sejam solicitados ou não, podem ser interrompidos devido a escopos ausentes.

Os aplicativos agora receberão tokens de acesso com uma combinação de permissões: tokens solicitados, e aqueles para os quais há o consentimento de que não exigem prompts de acesso condicional. Os escopos do token de acesso são refletidos no parâmetro de resposta scope do token.

Essa alteração será feita para todos os aplicativos, exceto aqueles com uma dependência observada sobre esse comportamento. Os desenvolvedores receberão atendimento se forem isentos dessa alteração, pois podem ter uma dependência dos prompts de acesso condicional adicionais.

Exemplos

Um aplicativo tem consentimento para user.read, files.readwrite e tasks.read. files.readwrite tem políticas de acesso condicional aplicadas a ele, ao passo que os outros dois não têm. Se um aplicativo fizer uma solicitação de token para scope=user.read, e o usuário conectado no momento não tiver passado uma política de acesso condicional, o token resultante será para as permissões user.read e tasks.read. tasks.read está incluído porque o aplicativo tem o consentimento e não exige que uma política de acesso condicional seja imposta.

Se o aplicativo solicitar scope=files.readwrite, o acesso condicional exigido pelo locatário será disparado, forçando o aplicativo a mostrar um prompt de autenticação interativa em que a política de acesso condicional pode ser atendida. 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 Microsoft Entra ID verá que o usuário já concluiu as políticas de acesso condicional necessárias para o files.readwrite e emitirá novamente um token com todas as três permissões nele.

Junho de 2021

A UX de 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 do código do dispositivo agora inclui um prompt que valida se o usuário está entrando no aplicativo esperado.

O prompt que aparece é semelhante ao seguinte:

Maio de 2020

Correção de bug: o Microsoft Entra ID não codificará mais a URL do parâmetro de estado duas vezes

Data de efetivação: maio de 2021

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

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

Um bug foi encontrado e corrigido na resposta de autorização do Microsoft Entra. Durante o segmento de autenticação /authorize, o parâmetro state da solicitação é incluído na resposta, a fim de preservar o estado do aplicativo e ajudar a evitar ataques de CSRF. O Microsoft Entra ID codificou incorretamente por URL o parâmetro state antes de inseri-lo na resposta, onde ele 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 esse parâmetro duas vezes, para que os aplicativos analisem o resultado corretamente. Essa alteração será feita em todos os aplicativos.

Os pontos de extremidade do Azure Governamental estão mudando

Data de entrada em vigor: 5 de maio de 2020 (com conclusão em junho de 2020)

Pontos de extremidade afetados: todos

Protocolo afetado: todos os fluxos

Em 1º de junho de 2018, a Autoridade do Microsoft Entra para o Azure Governamental mudou de https://login-us.microsoftonline.com para https://login.microsoftonline.us. Essa alteração também é aplicada ao GCC High e DoD do Microsoft 365, para os quais o Microsoft Entra ID do Azure Governamental também oferece serviços. Se você tiver aplicativos em um locatário do governo dos EUA atualize-os para conectar os usuários no ponto de extremidade .us.

A partir de 5 de maio de 2020, o Microsoft Entra ID começará a aplicar a alteração do ponto de extremidade, bloqueando a conexão dos usuários governamentais em aplicativos hospedados nos locatários do governo dos EUA por meio do ponto de extremidade público (microsoftonline.com). Os aplicativos afetados 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 público na nuvem. Se o aplicativo estiver em um locatário de nuvem pública e pretende oferecer suporte a usuários do governo dos EUA, você precisará atualizar o aplicativo para dar suporte a eles explicitamente. Isso pode exigir a criação de um novo registro de aplicativo na nuvem do governo dos EUA.

A imposição dessa alteração será feita usando uma distribuição gradual com base na frequência com que os usuários da nuvem do governo dos EUA entram no aplicativo. Ou seja, os aplicativos que entram raramente em usuários do governo dos EUA verão a imposição primeiro e os aplicativos frequentemente usados pelos usuários do governo dos EUA serão os últimos a ter a imposição aplicada. Esperamos que a imposição seja concluída em todos os aplicativos em junho de 2020.

Para obter mais detalhes, confira a postagem no blog do Azure Governamental sobre essa migração.

Março de 2020

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

Data de efetivação: 13 de março de 2020

Pontos de extremidade afetados: todos

Protocolo afetado: todos os fluxos de usuário.

Os usuários com senhas com mais de 256 caracteres que entram diretamente no Microsoft Entra ID (não um IDP federado, como o AD FS) serão solicitados a alterar suas senhas antes de poderem entrar. Os administradores podem receber solicitações para ajudar a redefinir a senha do usuário.

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

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

Correção:

O usuário não consegue entrar porque a senha dele excede o comprimento máximo permitido. Eles devem entrar em contato com o administrador para redefinir a senha. Se o SSPR estiver habilitado para o locatário, ele poderá redefinir a senha seguindo o link "Esqueceu a senha".

Fevereiro de 2020

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

Data de efetivação: 8 de fevereiro de 2020

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

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

Quando uma resposta de autenticação é enviada do login.microsoftonline.com para um aplicativo pelo redirecionamento HTTP, o serviço acrescentará um fragmento vazio à URL de resposta. Isso impedirá uma classe de ataques de redirecionamento, pois garante que o navegador apagará qualquer fragmento existente na solicitação de autenticação. Nenhum aplicativo deve depender desse comportamento.

Agosto de 2019

A semântica do formulário POST será imposta com mais rigorosidade – espaços e aspas serão ignorados

Data de efetivação: 2 de setembro de 2019

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

Protocolo afetado: todo lugar onde POST for usado (credenciais do cliente, resgate de código de autorização, ROPC, OBOe resgate de token de atualização)

A partir da semana de 02 de setembro de 2019, as solicitações de autenticação que usam o método POST passaram a ser validadas usando padrões HTTP mais estritos. Especificamente, espaços e aspas duplas (") não serão mais removidos dos valores do formulário de solicitação. Essas alterações não devem interromper clientes existentes e garantirão que as solicitações enviadas ao Microsoft Entra ID sejam sempre gerenciadas de maneira confiável. No futuro (veja acima), planejamos rejeitar ainda mais parâmetros duplicados e ignorar a BOM em solicitações.

Exemplo:

Hoje, ?e= "f"&g=h é analisado de forma idêntica como ?e=f&g=h – então e == f. Com essa alteração, agora ela será analisada de modo que e == "f" – isso dificilmente será um argumento válido e a solicitação agora falharia.

Julho de 2019

Tokens somente de aplicativo para aplicativos de locatário único só serão emitidos se o aplicativo cliente existir no locatário de recursos

Data de efetivação: 26 de julho de 2019

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

Protocolo afetado: credenciais de cliente (tokens somente de aplicativo)

No dia 26 de julho de 2019, entrou em vigor uma alteração de segurança que altera a maneira como os tokens somente de aplicativo (por meio da concessão de credenciais de cliente) são emitidos. Anteriormente, os aplicativos eram autorizados a obter tokens para chamar 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 um único locatário (o padrão), o aplicativo cliente exista dentro do locatário do 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 declaração roles esteja presente e contenha o valor esperado para a API.

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

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 corrigir esse problema, use a experiência de consentimento do administrador para criar a entidade de serviço do aplicativo cliente no locatário ou crie-a manualmente. Esse requisito garante que o locatário concedeu a permissão de aplicativo para operar dentro do locatário.

Solicitação 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 (autoridade) do recurso é contoso.com, o aplicativo de recurso é um aplicativo de locatário único chamado gateway.contoso.com/api para o locatário Contoso e o aplicativo cliente é 00001111-aaaa-2222-bbbb-3333cccc4444. Se o aplicativo cliente tiver uma entidade de serviço dentro de Contoso.com, essa solicitação poderá continuar. No entanto, se não tiver, a solicitação falhará com o erro acima.

Se o aplicativo de gateway da Contoso for multilocatário, a solicitação continuará, independentemente do aplicativo cliente ter uma entidade de serviço em Contoso.com.

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

Data de efetivação: 22 de julho de 2019

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

Protocolo afetado: todos os fluxos

De acordo com a RFC 6749, os aplicativos do 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 do OAuth 2.0. URIs de redirecionamento dinâmico ainda são proibidos, pois representam um risco de segurança e não podem ser usados para reter informações de estado em uma solicitação de autenticação – para isso, use o parâmetro state.

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 que corresponda à redirect_uri decodificada por URI estiver registrada, a solicitação será rejeitada. Se o URI for encontrado no registro de aplicativo, a cadeia de caracteres inteira será usada para redirecionar o usuário, incluindo o parâmetro de consulta estática.

Naquele momento (fim de julho de 2019), a UX de registro de aplicativo no portal do Azure ainda bloqueava parâmetros de consulta. No entanto, você pode editar manualmente o manifesto do aplicativo para adicionar parâmetros de consulta e testá-lo no aplicativo.

Março de 2019

Os clientes de looping serão interrompidos

Data de efetivação: 25 de março de 2019

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

Protocolo afetado: todos os fluxos

Às vezes, os aplicativos cliente podem se comportar de forma inadequada e emitir centenas da mesma solicitação de logon em um curto período de tempo. Essas solicitações podem ou não ser bem-sucedidas, mas contribuem para uma experiência de usuário ruim e um aumento de cargas de trabalho para o IDP, o que aumenta a latência para todos os usuários e reduz a disponibilidade do IDP. Esses aplicativos estão operando fora dos limites de uso normal e devem ser atualizados para se comportarem corretamente.

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

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

• Dica de usuário, se houver

• Escopos ou recursos sendo solicitados

• ID do Cliente

• URI de redirecionamento

• Tipo e modo de resposta

Os aplicativos que fazem várias solicitações (mais de 15) em um curto período (5 minutos) receberão um erro invalid_grant que explicará que eles estão em loop. Os tokens solicitados têm tempos de vida suficientemente longos (10 minutos no mínimo, 60 minutos por padrão), o que torna solicitações repetidas nesse período de tempo desnecessárias.

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

Outubro de 2018

Não é mais possível reutilizar códigos de autorização

Data de efetivação: 15 de novembro de 2018

Pontos de extremidade 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 deixar o Microsoft Entra ID em conformidade com a especificação do OAuth e será aplicada aos pontos de extremidade v1 e v2.

Se seu aplicativo reutiliza 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, utilize esse token de atualização para adquirir tokens adicionais para outros recursos. Os códigos de autorização só podem ser usados uma vez; porém, os códigos de atualização podem ser usados várias vezes em diferentes recursos. Qualquer aplicativo novo 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 Atualização de tokens de acesso. Se estiver usando a ADAL ou a MSAL, isso será feito 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 de extremidade afetados: v1.0 e v2.0

Protocolos afetados: fluxo implícito e fluxo on-behalf-of

Após 1º de maio de 2018, os id_tokens não podem ser usados como a declaração em um Fluxo OBO para novos aplicativos. Em vez disso, é necessário usar tokens de acesso para proteger as APIs, até mesmo entre um cliente e a camada intermediária do mesmo aplicativo. Os aplicativos registrados antes de 1º de maio de 2018 continuarão funcionando e poderão trocar id_tokens por um token de acesso; no entanto, esse padrão não é considerado uma melhor prática.

Para contornar essa alteração, é possível fazer o seguinte:

1. Crie uma API Web para o aplicativo, com um ou mais escopos. Esse ponto de entrada explícito permitirá que segurança e controle mais precisos.
2. No manifesto do 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 pela chave oauth2AllowImplicitFlow.
3. Quando o aplicativo cliente solicita um id_token via response_type=id_token, também solicita um token de acesso (response_type=token) para a API Web criada acima. Portanto, ao usar o ponto de extremidade v 2.0, o parâmetro scope deverá ser semelhante ao api://GUID/SCOPE. No ponto de extremidade v1.0, o parâmetro resource deve ser o URI da API do aplicativo Web.
4. Passe esse token de acesso para a camada intermediária no lugar de id_token.