Conexões OAuth 2.0 no gerenciador de credenciais – detalhes e fluxos do processo

  • Artigo

APLICA-SE A: todas as camadas do Gerenciamento de API

Este artigo fornece detalhes sobre os fluxos de processo para gerenciar conexões OAuth 2.0 usando o gerenciador de credenciais no Gerenciamento de API do Azure. Os fluxos de processo são divididos em duas partes: gerenciamento e runtime.

Para obter informações sobre o gerenciador de credenciais no Gerenciamento de API, confira Sobre o gerenciador de credenciais e credenciais de API no Gerenciamento de API.

Gerenciamento de conexões

A parte de gerenciamento das conexões no gerenciador de credenciais cuida da configuração de um provedor de credenciais para tokens do OAuth 2.0. Isso inclui a habilitação do fluxo de consentimento para o provedor e a configuração de uma ou mais conexões ao provedor de credenciais para acesso às credenciais.

A imagem a seguir resume o fluxo de processo para criar uma conexão no Gerenciamento de API que usa o tipo de concessão de código de autorização.

Diagrama mostrando o fluxo do processo de criação de credenciais.

Etapa Descrição
1 O cliente envia uma solicitação para criar um provedor de credenciais
2 O provedor de credenciais é criado e uma resposta é enviada de volta
3 O cliente envia uma solicitação para criar uma conexão
4 A conexão é criada e uma resposta é enviada de volta com a informação de que a conexão não está "conectada"
5 O cliente envia uma solicitação para recuperar uma URL de logon para iniciar o processo de consentimento do OAuth 2.0 no provedor de credenciais. A solicitação inclui uma URL de pós-redirecionamento a ser usada na última etapa
6 A resposta é retornada com uma URL de logon que deve ser usada para iniciar o fluxo de consentimento.
7 O cliente abre um navegador com a URL de logon fornecida na etapa anterior. O navegador é redirecionado para o fluxo de consentimento OAuth 2.0 do provedor de credenciais
8 Depois da aprovação do consentimento, o navegador será redirecionado com um código de autorização para a URL de redirecionamento configurada no provedor de credenciais
9 O Gerenciamento de API usa o código de autorização para buscar tokens de acesso e atualização
10 O Gerenciamento de API recebe os tokens e os criptografa
11 O Gerenciamento de API redireciona para URL fornecida da etapa 5

Provedor de credenciais

Ao configurar o provedor de credenciais, você poderá escolher entre diferentes provedores OAuth e tipos de concessão (código de autorização ou credencial de cliente). Cada provedor requer configurações específicas. Coisas importantes a ter em mente:

  • Uma configuração do provedor de credenciais só pode ter um tipo de concessão.
  • Uma configuração do provedor de credenciais pode ter várias conexões.

Observação

Com o provedor OAuth 2.0 genérico, outros provedores de identidade que dão suporte aos padrões do fluxo do OAuth 2.0 podem ser usado.

Ao configurar um provedor de credenciais, o gerenciador de credenciais nos bastidores cria um repositório de credenciais que é usado para armazenar em cache os tokens de acesso e os tokens de atualização OAuth 2.0.

Conexão com um provedor de credenciais

Para acessar e usar os tokens para um provedor, os aplicativos cliente precisam de uma conexão com o provedor de credenciais. Uma determinada conexão é permitida por políticas de acesso com base nas identidades do Microsoft Entra ID. Você pode configurar várias conexões para um provedor.

O processo de configuração de uma conexão difere com base na concessão configurada e é específico para a configuração do provedor de credenciais. Por exemplo, se você quiser configurar o Microsoft Entra ID para usar ambos os tipos de concessão, serão necessárias duas configurações de provedor de credenciais. A tabela a seguir resume os dois tipos de concessão.

Tipo de concessão Descrição
Código de Autorização Está associada a um contexto de usuário, o que significa que um usuário precisar consentir com a conexão. Desde que o token de atualização seja válido, o Gerenciamento de API pode recuperar novos tokens de acesso e atualização. Se o token de atualização se tornar inválido, o usuário precisará reautorizar. Todas as credenciais de identidade dão suporte ao código de autorização. Saiba mais
Credenciais do cliente Não está associada a um usuário e geralmente é usada em cenários de aplicativo para aplicativo. Nenhum consentimento é necessário para o tipo de concessão de credenciais do cliente e a conexão não se torna inválida. Saiba mais

Para conexões baseadas no tipo de concessão de código de autorização, você deve autenticar-se no provedor e consentir com a autorização. Após o logon e a autorização bem-sucedidos pelo provedor de credenciais, o provedor retorna tokens de acesso e atualização válidos, que são criptografados e salvos pelo Gerenciamento de API.

Política de acesso

Você configura uma ou mais políticas de acesso para cada conexão. As políticas de acesso determinam quais identidades do Microsoft Entra ID pode obter acesso às suas credenciais em runtime. Atualmente, as conexões dão suporte ao acesso usando entidades de serviço, a identidade, os usuários e os grupos da instância de Gerenciamento de API.

Identidade Descrição Benefícios Considerações
Entidade de serviço Identidade cujos tokens podem ser usados para autenticar e conceder acesso a recursos específicos do Azure, quando uma organização está usando a ID do Microsoft Entra. Ao usar uma entidade de serviço, as organizações evitam criar usuários fictícios para gerenciar a autenticação quando precisam acessar um recurso. Uma entidade de serviço é uma identidade do Microsoft Entra que representa um aplicativo registrado do Microsoft Entra. Permite acesso com escopo mais rígido a cenários de conexão e delegação de usuário. Não está vinculado a uma instância do Gerenciamento de API específica. Depende da ID do Microsoft Entra para a imposição de permissões. Obter o contexto de autorização requer um token do Microsoft Entra ID.
Identidade gerenciada <Your API Management instance name> Essa opção corresponde a uma identidade gerenciada vinculada à sua instância do Gerenciamento de API. Por padrão, o acesso é fornecido à identidade gerenciada atribuída pelo sistema para a instância de gerenciamento de API correspondente. A identidade está vinculada à sua instância de Gerenciamento de API. Qualquer pessoa com acesso de Colaborador à instância do Gerenciamento de API pode acessar conexões que concedam permissões de identidade gerenciada.
Usuários ou grupos Usuários ou grupos em seu locatário do Microsoft Entra ID. Permite limitar o acesso a usuários ou grupos específicos de usuários. Exige que os usuários tenham uma conta do Microsoft Entra ID.

Runtime de conexões

A parte de runtime requer que uma API OAuth 2.0 de back-end seja configurada com a política get-authorization-context. Em runtime, a política busca e armazena tokens de acesso e de atualização do repositório de credenciais configurado pelo Gerenciamento de API para o provedor. Quando uma chamada chega no Gerenciamento de API e a política get-authorization-context é executada, ela primeiro valida se o token de autorização existente é válido. Se o token de autorização tiver expirado, o Gerenciamento de API usará um fluxo do OAuth 2.0 para atualizar os tokens armazenados a partir do provedor de credenciais. Em seguida, o token de acesso será usado para autorizar o acesso ao serviço de back-end.

Durante a execução da política, o acesso aos tokens também é validado usando políticas de acesso.

A imagem a seguir mostra um fluxo de processo de exemplo para buscar e armazenar tokens de autorização e atualização com base em uma conexão que usa o tipo de concessão de código de autorização. Depois que os tokens forem recuperados, uma chamada será feita para a API de back-end.

Diagrama que mostra o fluxo do processo para recuperar o token em runtime.

Etapa Descrição
1 O cliente envia a solicitação para a instância do Gerenciamento de API
2 A política get-authorization-context verifica se o token de acesso é válido para a conexão atual
3 Se o token de acesso tiver expirado, mas o token de atualização for válido, o Gerenciamento de API tentará buscar novos tokens de acesso e atualização do provedor de credenciais configurado
4 O provedor de credenciais retorna um token de acesso e um token de atualização, que são criptografados e salvos no Gerenciamento de API
5 Depois que os tokens forem recuperados, o token de acesso será anexado usando a política set-header como um cabeçalho de autorização para a solicitação de saída para a API de back-end
6 A resposta é retornada para o Gerenciamento de API
7 A resposta é retornada ao cliente

Conteúdo relacionado