Restrições e limitações de URI de redirecionamento (URL de resposta)

  • Artigo

Um URI de redirecionamento, ou URL de resposta, é o local para onde o servidor de autorização envia o utilizador depois de a aplicação ter sido autorizada com sucesso e ter recebido um código de autorização ou um token de acesso. O servidor de autorização envia o código ou token para o URL de redirecionamento, por isso, é importante que registe a localização correta como parte do processo de registo da aplicação.

O modelo de aplicativo Microsoft Entra especifica essas restrições para redirecionar URIs:

  • Os URIs de redirecionamento devem começar com o esquema https. Há algumas exceções para URIs de redirecionamento localhost .

  • Os URIs de redirecionamento diferenciam maiúsculas de minúsculas e devem corresponder ao caminho da URL do seu aplicativo em execução. Por exemplo, se seu aplicativo incluir como parte de seu caminho .../abc/response-oidc, não especifique .../ABC/response-oidc no URI de redirecionamento. Como o navegador da Web trata os caminhos como diferenciadores de maiúsculas e minúsculas, os cookies associados podem .../abc/response-oidc ser excluídos se redirecionados para o URL incompatível com maiúsculas e minúsculas .../ABC/response-oidc .

  • Os URIs de redirecionamento não configurados com um segmento de caminho são retornados com uma barra à direita (''/) na resposta. Isto aplica-se apenas quando o modo de resposta é query ou fragment.

    Exemplos:

    • https://contoso.com é devolvido como https://contoso.com/
    • http://localhost:7071 é devolvido como http://localhost:7071/

  • Os URIs de redirecionamento que contêm um segmento de caminho não são acrescentados com uma barra à direita na resposta.

    Exemplos:

    • https://contoso.com/abc é devolvido como https://contoso.com/abc
    • https://contoso.com/abc/response-oidc é devolvido como https://contoso.com/abc/response-oidc

  • Os URIs de redirecionamento não suportam caracteres especiais - ! $ ' ( ) , ;

Número máximo de URIs de redirecionamento

Esta tabela mostra o número máximo de URIs de redirecionamento que você pode adicionar a um registro de aplicativo na plataforma de identidade da Microsoft.

Contas a iniciar sessão Número máximo de URIs de redirecionamento Description
Contas escolares ou profissionais da Microsoft no locatário do Microsoft Entra de qualquer organização 256 signInAudience no manifesto do aplicativo é definido como AzureADMyOrg ou AzureADMultipleOrgs
Contas pessoais da Microsoft e contas corporativas e de estudante 100 signInAudience no manifesto do aplicativo está definido como AzureADandPersonalMicrosoftAccount

O número máximo de URIs de redirecionamento não pode ser aumentado por motivos de segurança. Se o seu cenário exigir mais URIs de redirecionamento do que o limite máximo permitido, considere a seguinte abordagem de parâmetro de estado como a solução.

Comprimento máximo do URI

Você pode usar um máximo de 256 caracteres para cada URI de redirecionamento adicionado a um registro de aplicativo.

Redirecionar URIs em objetos de aplicativo versus entidade de serviço

  • Adicione sempre os URIs de redirecionamento apenas ao objeto da aplicação.
  • Não adicione valores de URI de redirecionamento ao principal de serviço, dado que estes valores podem ser removidos quando o objeto do principal de serviço é sincronizado com o objeto da aplicação. Este erro pode ocorrer devido a qualquer operação de atualização que acione uma sincronização entre os dois objetos.

Suporte a parâmetros de consulta em URIs de redirecionamento

Os parâmetros de consulta são permitidos em URIs de redirecionamento para aplicativos que só entram em usuários com contas corporativas ou de estudante.

Os parâmetros de consulta não são permitidos em URIs de redirecionamento para qualquer registro de aplicativo configurado para entrar em usuários com contas pessoais da Microsoft, como Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live ou Microsoft 365.

Público de início de sessão de registo da aplicação Suporta parâmetros de consulta no URI de redirecionamento
Contas somente neste diretório organizacional (somente Contoso - Locatário único)
Contas em qualquer diretório organizacional (Qualquer diretório do Microsoft Entra — Multi-inquilino)
Contas em qualquer diretório organizacional (Qualquer diretório Microsoft Entra - Multilocatário) e contas pessoais da Microsoft (por exemplo, Skype, Xbox)
Apenas contas pessoais da Microsoft

Regimes apoiados

HTTPS: O esquema HTTPS (https://) é suportado para todos os URIs de redirecionamento baseados em HTTP.

HTTP: O esquema HTTP (http://) é suportado apenas para URIs localhost e deve ser usado somente durante o desenvolvimento e teste de aplicativos locais ativos.

Exemplo de URI de redirecionamento Validade
https://contoso.com Válido
https://contoso.com/abc/response-oidc Válido
https://localhost Válido
http://contoso.com/abc/response-oidc Inválido
http://localhost Válido
http://localhost/abc Válido

Exceções de host local

De acordo com as seções 8.3 e 7.3 do RFC 8252, os URIs de redirecionamento "loopback" ou "localhost" vêm com duas considerações especiais:

  1. http Os esquemas de URI são aceitáveis porque o redirecionamento nunca sai do dispositivo. Como tal, ambos os URIs são aceitáveis:
    • http://localhost/myApp
    • https://localhost/myApp
  2. Devido a intervalos de portas efêmeras frequentemente exigidos por aplicativos nativos, o componente de porta (por exemplo, :5001 ou :443) é ignorado para fins de correspondência de um URI de redirecionamento. Como resultado, todos esses URIs são considerados equivalentes:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

Do ponto de vista do desenvolvimento, isto significa algumas coisas:

  • Não registre vários URIs de redirecionamento em que apenas a porta é diferente. O servidor de login escolherá um arbitrariamente e usará o comportamento associado a esse URI de redirecionamento (por exemplo, se é um webredirecionamento -, -, nativeou spa-type).

    Isso é especialmente importante quando você deseja usar fluxos de autenticação diferentes no mesmo registro de aplicativo, por exemplo, a concessão do código de autorização e o fluxo implícito. Para associar o comportamento de resposta correto a cada URI de redirecionamento, o servidor de logon deve ser capaz de distinguir entre os URIs de redirecionamento e não pode fazê-lo quando apenas a porta é diferente.

  • Para registrar vários URIs de redirecionamento no localhost para testar fluxos diferentes durante o desenvolvimento, diferencie-os usando o componente de caminho do URI. Por exemplo, http://localhost/MyWebApp não corresponde a http://localhost/MyNativeApp.

  • O endereço de loopback IPv6 ([::1]) não é suportado no momento.

Prefira 127.0.0.1 a localhost

Para evitar que seu aplicativo seja quebrado por firewalls mal configurados ou interfaces de rede renomeadas, use o endereço 127.0.0.1 de loopback literal IP no URI de redirecionamento em vez de localhost. Por exemplo, https://127.0.0.1.

No entanto, você não pode usar a caixa de texto Redirecionar URIs no portal do Azure para adicionar um URI de redirecionamento baseado em loopback que usa o http esquema:

Error dialog in Azure portal showing disallowed http-based loopback redirect URI

Para adicionar um URI de redirecionamento que usa o esquema com o endereço de loopback, você deve modificar atualmente o http127.0.0.1atributo replyUrlsWithType no manifesto do aplicativo.

Restrições sobre curingas em URIs de redirecionamento

URIs curinga como https://*.contoso.com podem parecer convenientes, mas devem ser evitados devido a implicações de segurança. De acordo com a especificação OAuth 2.0 (seção 3.1.2 da RFC 6749), um URI de ponto de extremidade de redirecionamento deve ser um URI absoluto. Como tal, quando um URI curinga configurado corresponde a um URI de redirecionamento, as cadeias de caracteres de consulta e fragmentos no URI de redirecionamento são removidos.

Atualmente, não há suporte para URIs curinga em registros de aplicativos configurados para entrar em contas pessoais da Microsoft e contas corporativas ou de estudante. No entanto, os URIs curinga são permitidos para aplicativos configurados para entrar somente em contas corporativas ou de estudante no locatário do Microsoft Entra de uma organização.

Para adicionar URIs de redirecionamento com curingas a registros de aplicativos que entram em contas corporativas ou de estudante, use o editor de manifesto do aplicativo em Registros de aplicativos no portal do Azure. Embora seja possível definir um URI de redirecionamento com um curinga usando o editor de manifesto, recomendamos que você siga a seção 3.1.2 do RFC 6749. e use apenas URIs absolutos.

Se o seu cenário exigir mais URIs de redirecionamento do que o limite máximo permitido, considere a seguinte abordagem de parâmetro de estado em vez de adicionar um URI de redirecionamento curinga.

Usar um parâmetro de estado

Se você tiver vários subdomínios e seu cenário exigir que, após a autenticação bem-sucedida, redirecione os usuários para a mesma página a partir da qual eles começaram, usar um parâmetro de estado pode ser útil.

Nesta abordagem:

  1. Crie um URI de redirecionamento "compartilhado" por aplicativo para processar os tokens de segurança recebidos do ponto de extremidade de autorização.
  2. Seu aplicativo pode enviar parâmetros específicos do aplicativo (como URL de subdomínio onde o usuário se originou ou qualquer coisa como informações de marca) no parâmetro state. Ao usar um parâmetro de estado, proteja-se contra a proteção CSRF, conforme especificado na seção 10.12 da RFC 6749.
  3. Os parâmetros específicos do aplicativo incluirão todas as informações necessárias para que o aplicativo renderize a experiência correta para o usuário, ou seja, construa o estado apropriado do aplicativo. O ponto de extremidade de autorização do Microsoft Entra retira HTML do parâmetro state, portanto, certifique-se de que você não está passando conteúdo HTML nesse parâmetro.
  4. Quando o Microsoft Entra ID envia uma resposta para o URI de redirecionamento "compartilhado", ele enviará o parâmetro state de volta para o aplicativo.
  5. O aplicativo pode usar o valor no parâmetro state para determinar para qual URL enviar o usuário posteriormente. Certifique-se de validar a proteção CSRF.

Aviso

Essa abordagem permite que um cliente comprometido modifique os parâmetros adicionais enviados no parâmetro state, redirecionando assim o usuário para uma URL diferente, que é a ameaça de redirecionador aberto descrita na RFC 6819. Portanto, o cliente deve proteger esses parâmetros criptografando o estado ou verificando-o por algum outro meio, como validar o nome de domínio no URI de redirecionamento em relação ao token.

Próximos passos

Saiba mais sobre o registro do aplicativo Manifesto do aplicativo.