Compartilhar via

Aplicativos serviço a serviço

  • Artigo

Aviso

Este conteúdo é destinado ao ponto de extremidade mais antigo do Azure AD v1.0. Use a plataforma de identidade da Microsoft para obter novos projetos.

Os aplicativos de serviço a serviço podem ser um aplicativo daemon ou para servidores que precisa obter recursos de uma API Web. Há dois subcenários que se aplicam a esta seção:

  • Um daemon que precisa chamar uma API Web, criada no tipo de concessão de credenciais de cliente OAuth 2.0

    Nesse cenário, é importante entender alguns aspectos. Primeiro, a interação do usuário não é possível com um aplicativo daemon, que requer que o aplicativo tenha sua própria identidade. Um exemplo de um aplicativo daemon é um trabalho em lotes ou um serviço de sistema operacional sendo executado em segundo plano. Esse tipo de aplicativo solicita um token de acesso usando sua identidade de aplicativo e apresentando sua ID de Aplicativo, credenciais (senha ou certificado) e URI de ID do aplicativo para o Azure AD. Após a autenticação bem-sucedida, o daemon recebe um token de acesso do Azure AD, que é usado para chamar a API da Web.

  • Um aplicativo para servidores (por exemplo, uma API Web) que precisa chamar uma API Web, criado na especificação de rascunho em nome do OAuth 2.0

    Nesse cenário, imagine que um usuário tenha se autenticado em um aplicativo nativo e que esse aplicativo nativo precisa chamar uma API Web. O Azure AD emite um token de acesso JWT para chamar a API da Web. Se a API da Web precisar chamar outra API da Web de downstream, ele pode usar o fluxo on-behalf-of para delegar a identidade do usuário e se autenticar à API da Web de segunda camada.

Diagrama

Aplicativo Daemon ou de servidor para diagrama da API da Web

Fluxo do protocolo

Identidade do aplicativo com concessão de credenciais do cliente OAuth 2.0

  1. Primeiro, o aplicativo de servidor precisa se autenticar no Azure AD ele mesmo, sem qualquer interação humana, como uma caixa de diálogo de logon interativa. Ele faz uma solicitação ao ponto de extremidade do token do Azure AD, fornecendo a credencial, a ID do Aplicativo e o URI de ID do aplicativo.
  2. O Azure AD autentica o aplicativo e retorna um token de acesso JWT que é usado para chamar a API da Web.
  3. Por meio do HTTPS, o aplicativo Web usa o token de acesso JWT retornado para adicionar a cadeia de caracteres JWT, juntamente com uma designação de "Portador" no cabeçalho de Autorização da solicitação a uma API Web. A API da Web, em seguida, valida o token JWT e, se a validação for bem-sucedida, retorna o recurso desejado.

Identidade de usuário delegado com a especificação de rascunho do OAuth 2.0 On-Behalf-Of

O fluxo discutido abaixo pressupõe que um usuário tenha sido autenticado em outro aplicativo (como um aplicativo nativo) e sua identidade de usuário tiver sido usada para adquirir um token de acesso à API da Web de primeira camada.

  1. O aplicativo nativo envia o token de acesso à API da Web de primeira camada.
  2. A API da Web de primeira camada envia uma solicitação ao ponto de extremidade do token do Azure AD, fornecendo sua ID de Aplicativo e as credenciais, bem como o token de acesso do usuário. Além disso, a solicitação é enviada com um parâmetro on_behalf_of que indica que a API da Web está solicitando novos tokens para chamar uma API da Web downstream em nome do usuário original.
  3. O Azure AD verifica se a API da Web de primeira camada tem permissões para acessar a API da Web de segunda camada e valida a solicitação, retornando um token de acesso JWT e um token de atualização JWT para a API da Web de primeira camada.
  4. Via HTTPS, a API da Web de primeira camada chama a API da Web de segunda camada, acrescentando a cadeia de caracteres do token no cabeçalho de autorização na solicitação. A API da Web de primeira camada pode continuar a chamar a API da Web de segunda camada, desde que o token de acesso e os tokens de atualização sejam válidos.

Exemplos de código

Consulte os exemplos de código para o Aplicativo Daemon ou de Servidor para cenários da API Web: Aplicativo Daemon ou de Servidor para API da Web

Registro de aplicativo

  • Locatário único – Para a identidade do aplicativo e casos de identidade de usuário delegado, o aplicativo daemon ou para servidores deve ser registrado no mesmo diretório no Azure AD. A API da Web pode ser configurada para expor um conjunto de permissões, que são usadas para limitar o acesso do daemon ou do servidor a seus recursos. Se um tipo de identidade de usuário delegado estiver sendo usado, o aplicativo do servidor precisa selecionar as permissões desejadas. Na página Permissão de API do registro de aplicativo, depois de selecionar Adicionar uma permissão e escolher a família de API, escolha Permissões delegadase, em seguida, selecione suas permissões. Essa etapa não será necessária se o tipo de identidade de aplicativo estiver sendo usado.
  • Multilocatário – Primeiro, o aplicativo daemon ou para servidores é configurado para indicar as permissões necessárias para que seja funcional. Essa lista de permissões necessárias é mostrada em uma caixa de diálogo quando um usuário ou administrador no diretório de destino dá consentimento para o aplicativo, o que o torna disponível para sua organização. Alguns aplicativos exigem apenas permissões de nível de usuário, que qualquer usuário na organização pode conceder. Outros aplicativos exigem permissões de nível administrativo, que um usuário na organização não pode conceder. Somente um administrador do diretório pode dar consentimento para aplicativos que exigem esse nível de permissões. Quando o usuário ou administrador concede permissão, ambas as APIs Web são registradas no diretório delas.

Expiração do token

Quando o primeiro aplicativo usa seu código de autorização para obter um token de acesso JWT, ele também recebe um token de atualização JWT. Quando o token de acesso expira, o token de atualização pode ser usado para autenticar o usuário novamente sem solicitar credenciais. Esse token de atualização é usado para autenticar o usuário, o que resulta em um novo token de acesso e token de atualização.

Próximas etapas