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

  • Artigo
  • 7 minutos para o fim da leitura

Um URI de redirecionamento, ou URL de resposta, é o local para o qual o servidor de autorização enviará o usuário quando o aplicativo for autorizado e receber um código de autorização ou token de acesso. O servidor de autorização envia o código ou token para o URI de redirecionamento, então é importante registrar o local correto como parte do processo de registro do aplicativo.

O modelo de aplicativo AAD (Azure Active Directory) especifica essas restrições para redirecionar URIs:

  • Os URIs de redirecionamento precisa 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 caso do caminho de URL do seu aplicativo em execução. Por exemplo, se o aplicativo incluir .../abc/response-oidc como parte do caminho, não especifique .../ABC/response-oidc no URI de redirecionamento. Como o navegador da Web trata os caminhos diferenciando maiúsculas de minúsculas, os cookies associados a .../abc/response-oidc podem ser excluídos se forem redirecionados para a URL de .../ABC/response-oidc com maiúsculas e minúsculas não correspondentes.

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

    Exemplos:

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

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

    Exemplos:

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

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 sendo conectadas Número máximo de URIs de redirecionamento Descrição
Contas corporativas ou de estudante da Microsoft no locatário do Azure Active Directory (Azure AD) de qualquer organização 256 O campo signInAudience no manifesto do aplicativo é definido como AzureADMyOrg ou AzureADMultipleOrgs.
Contas pessoais e contas corporativas e de estudante da Microsoft 100 O campo signInAudience no manifesto do aplicativo é definido como AzureADandPersonalMicrosoftAccount.

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

Tamanho máximo do URI

Você poderá usar no máximo de 256 caracteres para cada URI de redirecionamento que adicionar a um registro de aplicativo.

Redirecionar URIs no aplicativo vs. objetos de entidade de serviço

  • Sempre adicione URIs de redirecionamento apenas ao objeto de aplicativo.
  • Não adicione valores de URI de redirecionamento a uma entidade de serviço, porque esses valores podem ser removidos quando o objeto de entidade de serviço for sincronizado com o objeto de aplicativo. Isso pode ocorrer em qualquer operação de atualização que dispare 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ó conectam 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 conectar usuários com contas pessoais da Microsoft, como Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live ou Microsoft 365.

Público-alvo para entrada do registro de aplicativo Dá suporte a 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 Azure AD – multilocatário)
Contas em qualquer diretório organizacional (qualquer diretório do Azure AD – multilocatário) e contas pessoais da Microsoft (por exemplo, Skype, Xbox)
Somente contas Microsoft pessoais

Esquemas compatíveis

HTTPS: o esquema HTTPS (https://) tem suporte para todos os URIs de redirecionamento baseados em HTTP.

HTTP: o esquema HTTP (http://) tem suporte apenas para URIs de 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 localhost

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

  1. Os esquemas de URI http são aceitáveis porque o redirecionamento nunca sai do dispositivo. Dessa forma, os dois URIs são aceitáveis:
    • http://localhost/myApp
    • https://localhost/myApp
  2. Devido a intervalos de porta efêmeros geralmente exigidos por aplicativos nativos, o componente port (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, isso significa algumas coisas:

  • Não registre vários URIs de redirecionamento em que apenas a porta é diferente. O servidor de logon escolherá um aleatoriamente e usará o comportamento associado a esse URI de redirecionamento (por exemplo, se for um redirecionamento do tipo web, native ou spa).

    Isso é especialmente importante quando você deseja usar fluxos de autenticação diferentes no mesmo registro de aplicativo, por exemplo, a concessão de 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 precisa ser capaz de distinguir entre os URIs de redirecionamento e não pode fazer isso 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 path do URI. Por exemplo, http://localhost/MyWebApp não corresponde a http://localhost/MyNativeApp.

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

Prefira 127.0.0.1 a localhost

Para impedir que seu aplicativo seja interrompido por firewalls configurados incorretamente ou por adaptadores de rede renomeados, use o endereço de loopback literal do IP 127.0.0.1 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 URIs de redirecionamento no portal do Azure para adicionar um URI de redirecionamento baseado em loopback que usa o esquema http:

Caixa de diálogo de erro no portal do Azure mostrando o URI de redirecionamento de loopback baseado em http não permitido

Para adicionar um URI de redirecionamento que usa o esquema http com o endereço de loopback 127.0.0.1, você precisa modificar o atributo replyUrlsWithType no manifesto do aplicativo.

Restrições em curingas em URIs de redirecionamento

URIs de 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 do RFC 6749), um URI de ponto de extremidade de redirecionamento deve ser um URI absoluto. Dessa forma, quando um URI curinga configurado corresponde a um URI de redirecionamento, cadeias de caracteres de consulta e fragmentos no URI de redirecionamento são removidos.

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

Para adicionar URIs de redirecionamento com curingas aos registros de aplicativo que entram em contas corporativas ou de estudante, use o editor de manifesto do aplicativo em Registros de aplicativo no portal do Azure. Embora seja possível definir um URI de redirecionamento com um curinga usando o editor de manifesto, é altamente recomendável seguir a seção 3.1.2 da RFC 6749. e usam apenas URIs absolutos.

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

Usar um parâmetro de estado

Se você tiver vários subdomínios e o cenário exigir isso, após a autenticação bem-sucedida, você vai redirecionar os usuários à mesma página de onde eles começaram. Pode ser útil usar um parâmetro de estado.

Nesta abordagem:

  1. Crie um URI de redirecionamento "compartilhado" por aplicativo para processar os tokens de segurança que você recebe do ponto de extremidade da autorização.
  2. Seu aplicativo pode enviar parâmetros específicos do aplicativo (como a URL de subdomínio de origem do usuário ou qualquer coisa, como informações de identidade visual) no parâmetro de estado. Ao usar um parâmetro de estado, considere a proteção contra CSRF, como 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 processe a experiência correta para o usuário, ou seja, construa o estado apropriado do aplicativo. O ponto de extremidade da autorização do Azure AD retira o HTML do parâmetro de estado; portanto, certifique-se de que você não está passando o conteúdo HTML nesse parâmetro.
  4. Quando o Azure AD envia uma resposta para o URI de redirecionamento "compartilhado", ele envia o parâmetro de estado de volta para o aplicativo.
  5. Assim, o aplicativo pode usar o valor do parâmetro de estado para determinar a URL de destino do usuário. Não se esqueça de garantir a proteção contra CSRF.

Aviso

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

Próximas etapas

Saiba mais sobre o manifesto do aplicativo do registro de aplicativos.