O que é o OAuth2.0?

Explorando o OAuth2.0

Bem-vindo a uma exploração do OAuth2.0, um protocolo de autenticação poderoso, mas muitas vezes incompreendido, dentro do universo Tulip. Neste artigo, vamos desvendar os fundamentos, guiá-lo pelos fluxos de autenticação suportados pela Tulip, desmistificar a configuração do seu conector inicial e compartilhar dicas rápidas para um início perfeito.

O OAuth2.0 pode ser complexo e, para manter as coisas concisas, omitimos alguns aspectos técnicos detalhados neste artigo. Se você quiser se aprofundar no manuseio de tokens de atualização, gerenciamento de escopo e público-alvo e configurações de conector personalizadas da Tulip, recomendamos consultar este guia técnico detalhado do OAuth2.0.

Tipos de autenticação

A Tulip suporta três tipos de autenticação OAuth2.0: OAuth2.0 (conta de serviço), OAuth2.0 (credenciais de usuário) e OAuth2.0 (credenciais de cliente). A principal distinção está em como as credenciais são compartilhadas entre os usuários e o fluxo que é executado em relação à especificação OAuth. Uma lista completa e uma descrição dos fluxos exclusivos do OAuth estão disponíveis aqui: https://frontegg.com/blog/oauth-flows.

:::(Info) (Observação) Em versões anteriores do Tulip, o OAuth2.0 (Service Account) era chamado de OAuth2 (Admin) e o OAuth2.0 (User Credentials) era chamado de OAuth2 (Operator):

Fluxo do código de autorização:

• OAuth2.0 (conta de serviço): Usa as credenciais fornecidas durante o teste do conector para todos os usuários no Tulip Player. Ideal para credenciais compartilhadas em sua organização. A reautenticação do administrador é necessária se as credenciais expirarem.
• OAuth2.0 (Credenciais do usuário): Segmenta a autenticação com base no usuário conectado ao Tulip Player. Se um usuário não se autenticou ou se a autenticação expirou, o usuário passa pelo fluxo OAuth dentro do Tulip Player.

Fluxo de credenciais do cliente:

• OAuth2.0 (Credenciais do cliente): Esse tipo de concessão é usado pela Tulip para obter um token de acesso por meio de autenticação com o servidor de autorização usando as credenciais do cliente (ID do cliente e segredo do cliente), normalmente para acessar recursos em seu próprio nome e não em nome de um usuário.

Revelando os conceitos básicos

Antes de se aprofundar nos detalhes, sugerimos que você se familiarize com os Ambientes e obtenha uma visão geral dos Hosts de Conector e suas funções.

O OAuth2.0 serve como um mecanismo para a Tulip (o cliente) estabelecer sua identidade com seus sistemas de negócios.

Fluxo do código de autorização

:::(Warning) (Aviso) Para concluir o processo de autenticação do usuário, seu navegador precisa permitir pop-ups. Se o seu conector estiver configurado com vários ambientes, cada ambiente abrirá uma janela pop-up separada durante a autenticação.

Como verificar se os pop-ups estão ativados no Chrome:

1. Abra o Chrome e clique no menu de três pontos no canto superior direito da janela.
2. Selecione Configurações no menu suspenso.
3. Role a tela para baixo e clique em Privacidade e segurança.
4. Na seção "Privacidade e segurança", clique em Configurações do site.
5. Role a tela para baixo e clique em Pop-ups e redirecionamentos.
6. Certifique-se de que o botão de alternância esteja definido para permitir pop-ups ou adicione manualmente o site à lista de sites autorizados a exibir pop-ups.

Se os pop-ups estiverem bloqueados, o Chrome exibirá um pequeno ícone na barra de endereços sempre que um pop-up for bloqueado. Você pode clicar nesse ícone para permitir rapidamente os pop-ups da Tulip:::

O acesso é concedido por meio de um handshake e a Tulip suporta principalmente o fluxo de código de autorização, o fluxo OAuth mais comum. Aqui está uma visão geral condensada de como esse fluxo se desenvolve:

1. O usuário inicia o fluxo clicando no botão Testar antes de salvar um Conector.
2. A Tulip se comunica com o servidor de autorização do seu provedor OAuth, compartilhando parâmetros específicos, como identidade do cliente, escopos (o que você está tentando acessar) e outros detalhes relevantes.
3. O servidor de autorização solicita que o usuário conceda acesso, conforme exemplificado abaixo:

1. Com o consentimento do usuário, o servidor de autorização gera um código de autorização e conclui a janela de autenticação.
2. Munida de um código de autorização, a Tulip solicita com segurança um token entrando em contato com o ponto de extremidade do token, fornecendo o código de autorização, o ID do cliente, o segredo do cliente e propriedades adicionais.
3. Após validar o código de autorização, o servidor responde com um token e, opcionalmente, com um token de atualização. Esse token serve para solicitações autorizadas pelo usuário.
4. O Tulip agora pode executar solicitações em nome dos usuários, com o token fornecido para autorização.

Veja os diagramas abaixo para entender o caminho da execução:

Fluxo de credenciais do cliente

O fluxo de credenciais do cliente é usado principalmente para a interação de dois sistemas comerciais. Esse fluxo é configurado uma vez e depois compartilhado por todos os usuários.

1. O usuário inicia o fluxo clicando no botão Testar antes de salvar um Conector.
2. A Tulip se comunica com o servidor de autorização do seu provedor OAuth, compartilhando parâmetros específicos, como identidade do cliente, escopos (o que você está tentando acessar) e outros detalhes relevantes.
3. O servidor de autorização retorna um token de acesso, supondo que o ID do cliente e o segredo do cliente estejam corretos. Opcionalmente, um token de atualização também pode ser retornado. Esse token serve para solicitações autorizadas pelo usuário.
4. A Tulip agora pode executar solicitações em nome dos usuários, com o token fornecido para autorização.

Configuração do OAuth

:::(Warning) (Serviços locais) Os pontos de extremidade Authorize e Token devem estar acessíveis à nuvem para que a Tulip execute a autenticação para conectores::::

URL do código de autorização

Esse é o URL que a Tulip contata na etapa 2 do fluxo do código de autenticação. Encontrado na documentação da API do seu provedor OAuth, normalmente termina em /auth ou /authorize.

Observação: esse campo não está presente para Credenciais de Cliente.

URL do token de acesso

Após a resposta do servidor de autorização, é feita uma solicitação ao URL do token de acesso para obter um token para autenticação. Geralmente termina em /token.

Observação: esse campo não está presente nas Credenciais do Cliente.

ID do cliente e segredo do cliente

Gerada a partir da interface do usuário do seu provedor OAuth, a ID do cliente é passada com a solicitação inicial de um código de autorização. A ID do cliente e o segredo do cliente acompanham todas as solicitações de token.

Público e escopo

O público especifica os ativos específicos aos quais o usuário busca acesso, enquanto o escopo define as ações desejadas nesses ativos. Ambos são transmitidos durante a solicitação do código de autorização na etapa 2.

Opções adicionais

• Enviar dados de solicitação de token como JSON: altera o tipo de codificação da solicitação enviada ao URL do token. Ative se necessário para integrações específicas.
• Send Authentication Header for refresh request (Enviar cabeçalho de autenticação para solicitação de atualização): Adiciona um cabeçalho extra às solicitações de atualização quando ativado.
• Ignorar prompt de consentimento do usuário: Controla o atributo prompt da solicitação do código de autenticação. Desativado define-o como consentimento, enquanto ativado define-o como login, permitindo que o provedor OAuth decida sobre a tela de login a ser exibida.

:::(Warning) (Observação) Para algumas integrações, exclua ou defina o atributo prompt como nenhum. Entre em contato com support@tulip.co para obter mais funcionalidades:::

Aprofundando

Deseja obter mais insights? Explore estes artigos:

• Configuração e detalhes técnicos do OAuth2.0
• Como executar uma função de conector em vários ambientes