Partilhar via

Tipos de aplicações em v1.0

  • Artigo

Aviso

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

O Azure Active Directory (Azure AD) suporta a autenticação para uma variedade de arquiteturas de aplicações modernas, todas baseadas em protocolos padrão da indústria OAuth 2.0 ou OpenID Connect.

O diagrama seguinte ilustra os cenários e os tipos de aplicações e como podem ser adicionados diferentes componentes:

Tipos de Aplicações e cenários

Estes são os cinco cenários de aplicações principais suportados pelo Azure AD:

Siga as ligações para saber mais sobre cada tipo de aplicação e compreender os cenários de alto nível antes de começar a trabalhar com o código. Também pode saber mais sobre as diferenças que precisa de saber ao escrever uma determinada aplicação que funcione com o ponto final v1.0 ou o ponto final v2.0.

Nota

O ponto final v2.0 não suporta todos os cenários e funcionalidades Azure AD. Para determinar se deve utilizar o ponto final v2.0, leia sobre as limitações v2.0.

Pode desenvolver qualquer uma das aplicações e cenários descritos aqui com vários idiomas e plataformas. São todos 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. Também pode transferir os exemplos de código diretamente a partir dos repositórios de exemplo do GitHub correspondentes.

Além disso, se a sua aplicação precisar de uma parte ou segmento específico de um cenário ponto a ponto, na maioria dos casos essa funcionalidade pode ser adicionada de forma independente. Por exemplo, se tiver uma aplicação nativa que chama uma API Web, pode adicionar facilmente uma aplicação Web que também chame a API Web.

Registo de aplicações

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

Qualquer aplicação que subcontrata a autenticação para Azure AD tem de estar registada num diretório. Este passo envolve informar Azure AD sobre a sua aplicação, incluindo o URL onde está localizada, o URL para enviar respostas após a autenticação, o URI para identificar a sua aplicação e muito mais. Estas informações são necessárias por alguns motivos fundamentais:

  • Azure AD precisa de comunicar com a aplicação ao processar tokens de início de sessão ou de troca. As informações transmitidas entre Azure AD e a aplicação incluem o seguinte:

    • URI do ID da Aplicação – o identificador de uma aplicação. Este valor é enviado para Azure AD durante a autenticação para indicar para que aplicação o autor da chamada quer um token. Além disso, este valor está incluído no token para que a aplicação saiba que era o destino pretendido.
    • URL de Resposta e URI de Redirecionamento – para uma API Web ou aplicação Web, o URL de Resposta é a localização onde Azure AD enviará a resposta de autenticação, incluindo um token se a autenticação tiver sido bem-sucedida. Para uma aplicação nativa, o URI de Redirecionamento é um identificador exclusivo para o qual Azure AD redirecionará o agente de utilizador num pedido OAuth 2.0.
    • ID da Aplicação – o ID de uma aplicação, que é gerado por Azure AD quando a aplicação é registada. Ao pedir um código de autorização ou token, o ID da Aplicação e a Chave são enviados para Azure AD durante a autenticação.
    • Chave – a chave que é enviada juntamente com um ID da Aplicação ao autenticar para Azure AD chamar uma API Web.

  • Azure AD tem de garantir que a aplicação tem as permissões necessárias para aceder aos seus dados de diretório, outras aplicações na sua organização, etc.

Para obter detalhes, saiba como registar uma aplicação.

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

O aprovisionamento torna-se mais claro quando compreende que existem duas categorias de aplicações que podem ser desenvolvidas e integradas com Azure AD:

  • Aplicação de inquilino único – uma única aplicação de inquilino destina-se a ser utilizada numa organização. Normalmente, são aplicações de linha de negócio (LoB) escritas por um programador empresarial. Uma única aplicação de inquilino só tem de ser acedida por utilizadores num diretório e, como resultado, só precisa de ser aprovisionada num diretório. Normalmente, estas aplicações são registadas por um programador na organização.
  • Aplicação multi-inquilino – uma aplicação multi-inquilino destina-se a ser utilizada em muitas organizações e não apenas numa organização. Normalmente, trata-se de aplicações de software como serviço (SaaS) escritas por um fornecedor independente de software (ISV). As aplicações multi-inquilino têm de ser aprovisionadas em cada diretório onde serão utilizadas, o que requer o consentimento do utilizador ou administrador para as registar. Este processo de consentimento começa quando uma aplicação foi registada no diretório e recebe acesso à Graph API ou talvez a outra API Web. Quando um utilizador ou administrador de uma organização diferente se inscreve para utilizar a aplicação, é apresentada uma caixa de diálogo que apresenta as permissões necessárias para a aplicação. Em seguida, o utilizador ou administrador pode consentir a aplicação, que dá à aplicação acesso aos dados indicados e, por fim, registar a aplicação no respetivo diretório. Para obter mais informações, veja Descrição geral do Framework de Consentimento.

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

Algumas considerações adicionais surgem ao desenvolver uma aplicação multi-inquilino em vez de uma única aplicação de inquilino. Por exemplo, se estiver a disponibilizar a sua aplicação aos utilizadores em vários diretórios, precisa de um mecanismo para determinar em que inquilino se encontram. Uma única aplicação de inquilino só precisa de procurar um utilizador no seu próprio diretório, enquanto uma aplicação multi-inquilino precisa de identificar um utilizador específico de todos os diretórios no Azure AD. Para realizar esta tarefa, Azure AD fornece um ponto final de autenticação comum onde qualquer aplicação multi-inquilino pode direcionar pedidos de início de sessão, em vez de um ponto final específico do inquilino. Este ponto final destina-se https://login.microsoftonline.com/common a todos os diretórios em Azure AD, enquanto um ponto final específico do inquilino pode ser https://login.microsoftonline.com/contoso.onmicrosoft.com. O ponto final comum é especialmente importante a considerar ao desenvolver a sua aplicação, uma vez que precisará da lógica necessária para processar vários inquilinos durante o início de sessão, o fim de sessão e a validação do token.

Se estiver atualmente a desenvolver uma única aplicação de inquilino, mas quiser disponibilizá-la a muitas organizações, pode fazer facilmente alterações à aplicação e à respetiva configuração no Azure AD para torná-la compatível com vários inquilinos. Além disso, Azure AD utiliza a mesma chave de assinatura para todos os tokens em todos os diretórios, quer esteja a fornecer autenticação num único inquilino ou numa aplicação multi-inquilino.

Cada cenário listado neste documento inclui uma subsecção que descreve os respetivos requisitos de aprovisionamento. Para obter informações mais aprofundadas sobre o aprovisionamento de uma aplicação no Azure AD e as diferenças entre aplicações individuais e multi-inquilinos, veja Integrar aplicações com o Azure Active Directory para obter mais informações. Continue a ler para compreender os cenários comuns da aplicação no Azure AD.

Passos seguintes