Conexões OAuth 2.0 no gerenciador de credenciais - detalhes e fluxos do processo
APLICA-SE A: Todas as camadas de 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 do processo são divididos em duas partes: gerenciamento e tempo de execução.
Para obter informações básicas sobre o gerenciador de credenciais no Gerenciamento de API, consulte Sobre o gerenciador de credenciais e as credenciais de API no Gerenciamento de API.
Gestão de ligações
A parte de gerenciamento de conexões no gerenciador de credenciais cuida da instalação e configuração de um provedor de credenciais para tokens OAuth 2.0, habilitando o fluxo de consentimento para o provedor e configurando uma ou mais conexões com o 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.
| Passo | Description |
|---|---|
| 5 | 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 login para iniciar o consentimento do OAuth 2.0 no provedor de credenciais. A solicitação inclui uma URL pós-redirecionamento a ser usada na última etapa |
| 6 | A resposta é retornada com uma URL de login que deve ser usada para iniciar o fluxo de consentimento. |
| 7 | O cliente abre um navegador com o URL de login fornecido na etapa anterior. O navegador é redirecionado para o fluxo de consentimento OAuth 2.0 do provedor de credenciais |
| 8 | Depois que o consentimento é aprovado, o navegador é 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 acesso e atualizar tokens |
| 10 | O Gerenciamento de API recebe os tokens e os criptografa |
| 11 | O Gerenciamento de API redireciona para a URL fornecida a partir da etapa 5 |
Provedor de credenciais
Ao configurar seu provedor de credenciais, você pode 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. Aspetos importantes a ter em mente:
- Uma configuração de provedor de credenciais só pode ter um tipo de concessão.
- Uma configuração de provedor de credenciais pode ter várias conexões.
Nota
Com o provedor OAuth 2.0 genérico, outros provedores de identidade que suportam os padrões do fluxo OAuth 2.0 podem ser usados.
Quando você configura 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 OAuth 2.0 e os tokens de atualização do provedor.
Conexão com um provedor de credenciais
Para acessar e usar 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 baseadas em identidades de ID do Microsoft Entra. 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, duas configurações de provedor de credenciais são necessárias. A tabela a seguir resume os dois tipos de subvenção.
| Tipo de subvenção | Description |
|---|---|
| Código de autorização | Vinculado a um contexto de usuário, o que significa que um usuário precisa 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á autorizar novamente. Todos os provedores de credenciais suportam código de autorização. Mais informações |
| Credenciais de cliente | Não está vinculado a um usuário e é frequentemente usado 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. Mais informações |
Consentimento
Para conexões baseadas no tipo de concessão de código de autorização, você deve autenticar-se no provedor e consentir a autorização. Após o login bem-sucedido e a autorização do 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 de ID do Microsoft Entra podem obter acesso às suas credenciais em tempo de execução. Atualmente, as conexões oferecem suporte ao acesso usando entidades de serviço, a identidade da instância de Gerenciamento de API, usuários e grupos.
| Identidade | Description | Benefícios | Considerações |
|---|---|---|---|
| Service principal (Principal 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 o Microsoft Entra ID. 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 Microsoft Entra registrado. | Permite um acesso com escopo mais restrito a cenários de conexão e delegação de usuários. Não está vinculado a uma instância específica de Gerenciamento de API. Depende do Microsoft Entra ID para imposição de permissão. | Para obter o contexto de autorização, é necessário um token de ID do Microsoft Entra. |
Identidade gerenciada <Your API Management instance name> |
Essa opção corresponde a uma identidade gerenciada vinculada à sua instância de Gerenciamento de API. | Por padrão, o acesso é fornecido à identidade gerenciada atribuída ao 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 de Gerenciamento de API pode acessar qualquer conexão que conceda permissões de identidade gerenciada. |
| Utilizadores ou grupos | Usuários ou grupos em seu locatário do Microsoft Entra ID. | Permite limitar o acesso a usuários ou grupos de usuários específicos. | Requer que os usuários tenham uma conta Microsoft Entra ID. |
Tempo de execução das conexões
A parte de tempo de execução requer uma API OAuth 2.0 de back-end para ser configurada com a get-authorization-context política. No tempo de execução, a política busca e armazena tokens de acesso e atualização do repositório de credenciais que o Gerenciamento de API configurou para o provedor. Quando uma chamada entra no Gerenciamento de API e a get-authorization-context política é 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 OAuth 2.0 para atualizar os tokens armazenados do provedor de credenciais. Em seguida, o token de acesso é 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 exemplo de fluxo de processo 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.
| Passo | Description |
|---|---|
| 5 | O cliente envia a solicitação para a instância de Gerenciamento de API |
| 2 | A get-authorization-context política 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 set-header política 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 é devolvida ao cliente |
Conteúdos relacionados
- Visão geral do gerenciador de credenciais
- Configurar provedores de credenciais para o gerenciador de credenciais
- Configurar e usar uma conexão para a API do Microsoft Graph ou a API do GitHub
- Configurar várias conexões de autorização para um provedor
- Configurar uma conexão para acesso delegado pelo usuário