Tipos de aplicativo na v1.0

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

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

Estes são os cinco principais cenários de aplicativo compatíveis com o Azure AD:

• SPA (aplicativo de página única): um usuário precisa entrar em um aplicativo de página única protegido pelo Azure AD.
• Navegador da Web para aplicativo Web: um usuário precisa entrar em um aplicativo Web protegido pelo Azure AD.
• Aplicativo nativo para a API Web: um aplicativo nativo que é executado em um telefone, tablet ou computador precisa autenticar um usuário para obter recursos de uma API Web protegida pelo Azure AD.
• Aplicativo Web para a API Web: um aplicativo Web precisa obter recursos de uma API Web protegida pelo Azure AD.
• Aplicativo daemon ou de servidor para API Web: um aplicativo daemon ou de servidor sem interface de usuário web precisa obter recursos de uma API Web protegida 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 funcione com o ponto de extremidade v1.0 ou o ponto de extremidade v2.0.

Você pode desenvolver qualquer um dos aplicativos e cenários descritos aqui usando vários idiomas 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 do GitHub correspondentes.

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

Registro de aplicativo

Registrando um aplicativo que usa o endpoint Azure AD v1.0

Qualquer aplicativo que terceiriza a autenticação para o Azure AD deve ser registrado em um diretório. Esta etapa envolve contar ao 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. Essas informações são necessárias por alguns motivos principais:

• O Azure AD precisa se comunicar com o aplicativo ao manipular o logon ou a 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 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 de autorização ou token, a ID do aplicativo e a chave são enviadas ao Azure AD durante a autenticação.
  • Chave - A chave que é enviada junto com uma ID do 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.

Aplicativos de locatário único e multilocatário

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

• Aplicativo para um único locatário – Um aplicativo para um único locatário é destinado ao uso em uma organização. Normalmente, são aplicativos LoB (Linha de Negócios) escritos por um desenvolvedor empresarial. Um único aplicativo de locatário 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 normalmente são registrados por um desenvolvedor na organização.
• Aplicativo multilocatário – um aplicativo multilocatário destina-se a ser usado em muitas organizações, não apenas em uma organização. Esses são normalmente aplicativos de software como serviço (SaaS) escritos por um fornecedor de software independente (ISV). Aplicativos multilocatários precisam ser provisionados em cada diretório em que serão usados, o que exige o consentimento do usuário ou do administrador para registrá-los. Esse processo de consentimento é iniciado quando um aplicativo tiver sido registrado no diretório e receber acesso à API do Graph ou talvez a outra API da Web. Quando um usuário ou administrador de uma organização diferente se inscreve para usar o aplicativo, ele recebe uma caixa de diálogo que exibe as permissões necessárias pelo aplicativo. O usuário ou administrador pode então consentir com o aplicativo, que fornece ao aplicativo acesso aos dados declarados e, por fim, 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 aplicativos de locatário único ou multilocatário

Algumas considerações adicionais surgem ao desenvolver um aplicativo multi-tenant em vez de um aplicativo de locatário ú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 único aplicativo de locatário 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 do Azure AD. Para realizar essa tarefa, o Azure AD fornece um ponto de extremidade de autenticação comum, onde qualquer aplicativo multilocatário pode encaminhar pedidos de autenticação, em vez de usar um ponto de extremidade de locatário individual. 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 tenant pode ser https://login.microsoftonline.com/contoso.onmicrosoft.com. O ponto de extremidade comum é especialmente importante de se considerar quando você estiver desenvolvendo seu aplicativo, pois precisará da lógica necessária para gerenciar vários arrendatários durante os processos de autenticação, saída e validação de tokens.

Se você estiver desenvolvendo um único aplicativo de locatário no momento, mas quiser disponibilizá-lo para muitas organizações, poderá fazer alterações facilmente no aplicativo e em sua configuração no Azure AD para torná-lo com capacidade para vários locatários. Além disso, o Azure AD usa a mesma chave de assinatura para todos os tokens em todos os diretórios, seja você 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 Integração de aplicativos com o Azure Active Directory para obter mais informações. Continue lendo para entender os cenários comuns do aplicativo no Azure AD.

Próximas etapas

• Saiba mais sobre outras noções básicas de autenticação do Azure AD