Partilhar via

Tipos de aplicação na v1.0

Advertência

Este conteúdo destina-se ao ponto de extremidade do Azure AD v1.0 mais antigo. Utilize a plataforma de identidade da Microsoft para novos projetos.

O Azure Ative Directory (Azure AD) dá suporte à autenticação para uma variedade de arquiteturas de aplicativos modernas, todas elas baseadas em protocolos padrão do setor OAuth 2.0 ou OpenID Connect.

O diagrama a seguir ilustra os cenários e tipos de aplicativos e como diferentes componentes podem ser adicionados:

Tipos de aplicativos e cenários

Estes são os cinco principais cenários de aplicativos suportados pelo Azure AD:

Siga os links para saber mais sobre cada tipo de aplicativo e entender os cenários de alto nível antes de começar a trabalhar com o código. Você também pode aprender sobre as diferenças que precisa saber ao escrever um aplicativo específico que funciona com o ponto de extremidade v1.0 ou v2.0.

Observação

O ponto de extremidade v2.0 não oferece suporte a todos os cenários e recursos do Azure AD. Para determinar se você deve usar o ponto de extremidade v2.0, leia sobre as limitações da v2.0.

Você pode desenvolver qualquer um dos aplicativos e cenários descritos aqui usando várias linguagens e plataformas. Todos eles são apoiados por exemplos de código completos disponíveis no guia de exemplos de código: exemplos de código v1.0 por cenário e exemplos de código v2.0 por cenário. Você também pode baixar os exemplos de código diretamente dos repositórios de exemplo correspondentes do GitHub.

Além disso, se seu aplicativo precisar de uma parte ou segmento específico de um cenário de ponta a ponta, na maioria dos casos essa funcionalidade pode ser adicionada independentemente. Por exemplo, se você tiver um aplicativo nativo que chama uma API da Web, poderá adicionar facilmente um aplicativo da Web que também chame a API da Web.

Registo na aplicação

Registar uma aplicação que utiliza o ponto final do Azure AD v1.0

Qualquer aplicativo que terceirize a autenticação para o Azure AD deve ser registrado em um diretório. Esta etapa envolve informar o Azure AD sobre seu aplicativo, incluindo a URL onde ele está localizado, a URL para enviar respostas após a autenticação, o URI para identificar seu aplicativo e muito mais. Esta informação é necessária por algumas razões principais:

  • O Azure AD precisa se comunicar com o aplicativo ao lidar com logon ou troca de tokens. As informações passadas entre o Azure AD e o aplicativo incluem o seguinte:

    • URI da ID do aplicativo - O identificador de um aplicativo. Esse valor é enviado ao Azure AD durante a autenticação para indicar para qual aplicativo o chamador deseja um token. Além disso, esse valor é incluído no token para que o aplicativo saiba que era o destino pretendido.
    • URL de resposta e URI de redirecionamento - Para uma API Web ou aplicativo Web, a URL de resposta é o local para onde o Azure AD enviará a resposta de autenticação, incluindo um token se a autenticação tiver sido bem-sucedida. Para um aplicativo nativo, o URI de Redirecionamento é um identificador exclusivo para o qual o Azure AD redirecionará o agente do usuário em uma solicitação OAuth 2.0.
    • ID do aplicativo - A ID de um aplicativo, que é gerada pelo Azure AD quando o aplicativo é registrado. Ao solicitar um código ou token de autorização, a ID e a Chave do Aplicativo são enviadas ao Azure AD durante a autenticação.
    • Chave - A chave que é enviada junto com uma ID de Aplicativo ao autenticar no Azure AD para chamar uma API Web.

  • O Azure AD precisa garantir que o aplicativo tenha as permissões necessárias para acessar seus dados de diretório, outros aplicativos em sua organização e assim por diante.

Para obter detalhes, saiba como registrar um aplicativo.

Aplicações de inquilino único e multi-inquilino

O provisionamento fica mais claro quando você entende que há duas categorias de aplicativos que podem ser desenvolvidos e integrados ao Azure AD:

  • Aplicativo de locatário único - Um aplicativo de locatário único destina-se ao uso em uma organização. Normalmente, são aplicativos de linha de negócios (LoB) escritos por um desenvolvedor corporativo. Um aplicativo de locatário único só precisa ser acessado pelos usuários em um diretório e, como resultado, ele só precisa ser provisionado em um diretório. Esses aplicativos geralmente são registrados por um desenvolvedor na organização.
  • Aplicativo multilocatário - Um aplicativo multilocatário destina-se ao uso em muitas organizações, não apenas em uma organização. Normalmente, são aplicativos SaaS (software como serviço) escritos por um fornecedor de software independente (ISV). Os aplicativos multilocatários precisam ser provisionados em cada diretório onde serão usados, o que requer o consentimento do usuário ou administrador para registrá-los. Esse processo de consentimento começa quando um aplicativo é registrado no diretório e recebe acesso à Graph API ou talvez a outra API da Web. Quando um usuário ou administrador de uma organização diferente se inscreve para usar o aplicativo, é apresentada uma caixa de diálogo que exibe as permissões que o aplicativo requer. O usuário ou administrador pode então consentir com o aplicativo, que dá ao aplicativo acesso aos dados declarados e, finalmente, registra o aplicativo em seu diretório. Para obter mais informações, consulte Visão geral da estrutura de consentimento.

Considerações adicionais ao desenvolver aplicações de único inquilino ou multi-inquilino

Algumas considerações adicionais surgem ao desenvolver uma aplicação multi-inquilinos ao invés de uma aplicação de inquilino único. Por exemplo, se você estiver disponibilizando seu aplicativo para usuários em vários diretórios, precisará de um mecanismo para determinar em qual locatário eles estão. Um aplicativo de locatário único só precisa procurar um usuário em seu próprio diretório, enquanto um aplicativo multilocatário precisa identificar um usuário específico de todos os diretórios no Azure AD. Para realizar essa tarefa, o Azure AD fornece um ponto de extremidade de autenticação comum onde qualquer aplicativo multilocatário pode direcionar solicitações de entrada, em vez de um ponto de extremidade específico do locatário. Esse ponto de extremidade é https://login.microsoftonline.com/common para todos os diretórios no Azure AD, enquanto um ponto de extremidade específico do locatário pode ser https://login.microsoftonline.com/contoso.onmicrosoft.com. O ponto de extremidade comum é especialmente importante a ser considerado ao desenvolver seu aplicativo, pois você precisará da lógica necessária para lidar com vários locatários durante a entrada, saída e validação de token.

Se você estiver desenvolvendo um aplicativo de locatário único, mas quiser disponibilizá-lo para muitas organizações, poderá facilmente fazer alterações no aplicativo e em sua configuração no Azure AD para torná-lo capaz de multilocatário. Além disso, o Azure AD usa a mesma chave de assinatura para todos os tokens em todos os diretórios, independentemente de você estar fornecendo autenticação em um único locatário ou aplicativo multilocatário.

Cada cenário listado neste documento inclui uma subseção que descreve seus requisitos de provisionamento. Para obter informações mais detalhadas sobre o provisionamento de um aplicativo no Azure AD e as diferenças entre aplicativos de locatário único e multilocatário, consulte Integrando aplicativos com o Azure Ative Directory para obter mais informações. Continue lendo para entender os cenários de aplicativos comuns no Azure AD.

Próximos passos

  • Last updated on