Share via

Aplicações de serviço a serviço

  • 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.

As aplicações de serviço a serviço podem ser uma aplicação de servidor ou daemon que precisa de obter recursos a partir de uma API Web. Existem dois sub-cenários que se aplicam a esta secção:

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

    Neste cenário, é importante compreender algumas coisas. Em primeiro lugar, a interação do utilizador não é possível com uma aplicação daemon, o que requer que a aplicação tenha a sua própria identidade. Um exemplo de uma aplicação daemon é um trabalho de lote ou um serviço do sistema operativo em execução em segundo plano. Este tipo de aplicação pede um token de acesso através da identidade da aplicação e apresenta o ID da Aplicação, a credencial (palavra-passe ou certificado) e o URI do ID da aplicação para Azure AD. Após a autenticação bem-sucedida, o daemon recebe um token de acesso do Azure AD, que é depois utilizado para chamar a API Web.

  • Uma aplicação de servidor (como uma API Web) que precisa de chamar uma API Web, criada com base na especificação de rascunho OAuth 2.0 On-Behalf-Of

    Neste cenário, imagine que um utilizador se autenticou numa aplicação nativa e que esta aplicação nativa precisa de chamar uma API Web. Azure AD emite um token de acesso JWT para chamar a API Web. Se a API Web precisar de chamar outra API Web a jusante, pode utilizar o fluxo em nome de para delegar a identidade do utilizador e autenticar-se na API Web de segunda camada.

Diagrama

Diagrama da API Daemon ou Daemon ou Daemon para a API Web

Fluxo de protocolo

Identidade da aplicação com concessão de credenciais de cliente OAuth 2.0

  1. Em primeiro lugar, a aplicação de servidor tem de se autenticar com Azure AD como ela própria, sem qualquer interação humana, como uma caixa de diálogo de início de sessão interativo. Faz um pedido ao ponto final do token do Azure AD, fornecendo a credencial, o ID da Aplicação e o URI do ID da aplicação.
  2. Azure AD autentica a aplicação e devolve um token de acesso JWT que é utilizado para chamar a API Web.
  3. Através de HTTPS, a aplicação Web utiliza o token de acesso JWT devolvido para adicionar a cadeia JWT com uma designação "Portador" no cabeçalho Autorização do pedido à API Web. Em seguida, a API Web valida o token JWT e, se a validação for bem-sucedida, devolve o recurso pretendido.

Identidade de utilizador delegada com o OAuth 2.0 On-Behalf-Of Draft Specification

O fluxo abordado abaixo pressupõe que um utilizador foi autenticado noutra aplicação (como uma aplicação nativa) e que a respetiva identidade de utilizador foi utilizada para adquirir um token de acesso para a API Web de primeira camada.

  1. A aplicação nativa envia o token de acesso para a API Web de primeira camada.
  2. A API Web de primeira camada envia um pedido para o ponto final do token do Azure AD, fornecendo o ID da Aplicação e as credenciais, bem como o token de acesso do utilizador. Além disso, o pedido é enviado com um parâmetro on_behalf_of que indica que a API Web está a pedir novos tokens para chamar uma API Web a jusante em nome do utilizador original.
  3. Azure AD verifica se a API Web de primeira camada tem permissões para aceder à API Web de segunda camada e valida o pedido, devolvendo um token de acesso JWT e um token de atualização JWT à API Web de primeira camada.
  4. Através de HTTPS, a API Web de primeira camada chama a API Web de segunda camada ao acrescentar a cadeia de token no cabeçalho Autorização no pedido. A API Web de primeira camada pode continuar a chamar a API Web de segunda camada, desde que o token de acesso e os tokens de atualização sejam válidos.

Exemplos de código

Veja os exemplos de código para cenários da API Daemon ou da Aplicação de Servidor para a API Web: Servidor ou APLICAÇÃO Daemon para a API Web

Registo de aplicações

  • Inquilino único – para a identidade da aplicação e os casos de identidade de utilizador delegado, o daemon ou a aplicação de servidor tem de estar registado no mesmo diretório no Azure AD. A API Web pode ser configurada para expor um conjunto de permissões, que são utilizadas para limitar o acesso do daemon ou do servidor aos respetivos recursos. Se estiver a ser utilizado um tipo de identidade de utilizador delegado, a aplicação de servidor tem de selecionar as permissões pretendidas. Na página Permissão da API para o registo da aplicação, depois de selecionar Adicionar uma permissão e escolher a família de API, selecione Permissões delegadas e, em seguida, selecione as suas permissões. Este passo não é necessário se o tipo de identidade da aplicação estiver a ser utilizado.
  • Multi-inquilino - Primeiro, o daemon ou a aplicação de servidor está configurado para indicar as permissões necessárias para estar funcional. Esta lista de permissões necessárias é apresentada numa caixa de diálogo quando um utilizador ou administrador no diretório de destino dá consentimento à aplicação, o que a disponibiliza à organização. Algumas aplicações apenas requerem permissões ao nível do utilizador, que qualquer utilizador na organização pode consentir. Outras aplicações requerem permissões ao nível do administrador, às quais um utilizador na organização não pode consentir. Apenas um administrador de diretório pode dar consentimento a aplicações que exijam este nível de permissões. Quando o utilizador ou administrador consente, ambas as APIs Web são registadas no respetivo diretório.

Expiração do token

Quando a primeira aplicação utiliza o respetivo código de autorização para obter um token de acesso JWT, também recebe um token de atualização JWT. Quando o token de acesso expirar, o token de atualização pode ser utilizado para autenticar novamente o utilizador sem pedir credenciais. Este token de atualização é então utilizado para autenticar o utilizador, o que resulta num novo token de acesso e token de atualização.

Passos seguintes