Partilhar via

Aplicações nativas

  • 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 nativas são aplicações que chamam uma API Web em nome de um utilizador. Este cenário baseia-se no tipo de concessão de código de autorização OAuth 2.0 com um cliente público, conforme descrito na secção 4.1 da especificação OAuth 2.0. A aplicação nativa obtém um token de acesso para o utilizador com o protocolo OAuth 2.0. Em seguida, este token de acesso é enviado no pedido para a API Web, que autoriza o utilizador e devolve o recurso pretendido.

Diagrama

Diagrama da Aplicação Nativa para a API Web

Fluxo de protocolo

Se estiver a utilizar as Bibliotecas de Autenticação do AD, a maioria dos detalhes do protocolo descritos abaixo são processados por si, como o pop-up do browser, a colocação em cache de tokens e o processamento de tokens de atualização.

  1. Ao utilizar um pop-up do browser, a aplicação nativa faz um pedido ao ponto final de autorização no Azure AD. Este pedido inclui o ID da Aplicação e o URI de redirecionamento da aplicação nativa, conforme mostrado no portal do Azure e o URI do ID da aplicação para a API Web. Se o utilizador ainda não tiver iniciado sessão, ser-lhe-á pedido para iniciar sessão novamente
  2. Azure AD autentica o utilizador. Se for uma aplicação multi-inquilino e for necessário consentimento para utilizar a aplicação, o utilizador terá de consentir se ainda não o tiver feito. Depois de conceder consentimento e após a autenticação bem-sucedida, Azure AD emite uma resposta de código de autorização ao URI de redirecionamento da aplicação cliente.
  3. Quando Azure AD emite uma resposta de código de autorização de volta ao URI de redirecionamento, a aplicação cliente interrompe a interação do browser e extrai o código de autorização da resposta. Com este código de autorização, a aplicação cliente envia um pedido para o ponto final de token do Azure AD que inclui o código de autorização, detalhes sobre a aplicação cliente (ID da Aplicação e URI de redirecionamento) e o recurso pretendido (URI do ID da aplicação para a API Web).
  4. O código de autorização e as informações sobre a aplicação cliente e a API Web são validados por Azure AD. Após a validação bem-sucedida, Azure AD devolve dois tokens: um token de acesso JWT e um token de atualização JWT. Além disso, Azure AD devolve informações básicas sobre o utilizador, como o nome a apresentar e o ID do inquilino.
  5. Através de HTTPS, a aplicação cliente 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.
  6. Quando o token de acesso expirar, a aplicação cliente receberá um erro que indica que o utilizador tem de autenticar novamente. Se a aplicação tiver um token de atualização válido, pode ser utilizado para adquirir um novo token de acesso sem pedir ao utilizador para iniciar sessão novamente. Se o token de atualização expirar, a aplicação terá de autenticar interativamente o utilizador mais uma vez.

Nota

O token de atualização emitido pelo Azure AD pode ser utilizado para aceder a vários recursos. Por exemplo, se tiver uma aplicação cliente com permissão para chamar duas APIs Web, o token de atualização também pode ser utilizado para obter um token de acesso para a outra API Web.

Exemplos de código

Veja os exemplos de código para cenários de API Da Aplicação Nativa para a API Web. E, verifique com frequência. Adicionamos novos exemplos com frequência. Aplicação Nativa para a API Web.

Registo de aplicações

Para registar uma aplicação no ponto final Azure AD v1.0, consulte Registar uma aplicação.

  • Inquilino único – a aplicação nativa e a API Web têm de estar registadas 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 da aplicação nativa aos respetivos recursos. Em seguida, a aplicação cliente seleciona as permissões pretendidas no menu pendente "Permissões para Outras Aplicações" no portal do Azure.
  • Multi-inquilino – em primeiro lugar, a aplicação nativa só está registada no diretório do programador ou do publicador. Em segundo lugar, a aplicação nativa está configurada 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 torna disponível para a respetiva organização. Algumas aplicações apenas necessitam de 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órios pode dar consentimento a aplicações que necessitem deste nível de permissões. Quando o utilizador ou administrador consente, apenas a API Web é registada no respetivo diretório.

Expiração do token

Quando a aplicação nativa 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 exigir que iniciem sessão novamente. Este token de atualização é utilizado para autenticar o utilizador, o que resulta num novo token de acesso e token de atualização.

Passos seguintes