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.

Revelando o básico

Antes de se aprofundar nos detalhes, sugerimos que você se familiarize com os Ambientes e obtenha uma visão geral dos Hosts de Conectores 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. 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 Authorization Server gera um código de autorização e conclui a janela de autenticação.
2. Munido de um código de autorização, o Tulip solicita um token com segurança, 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, um token de atualização. 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

Exemplo de configuração

Tipos de autenticação

A Tulip suporta dois tipos de autenticação OAuth2.0: Admin OAuth e Operator OAuth. A principal distinção está em como as credenciais são compartilhadas entre os usuários.

• OAuth (Admin): 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.
• OAuth (Operator): Segmenta a autenticação com base no usuário conectado ao Tulip Player. Se um usuário não se autenticou ou a autenticação expirou, o usuário passa pelo fluxo OAuth dentro do Tulip Player.

URL do código de autorização

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

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.

ID do cliente e segredo do cliente

Gerado a partir da interface do usuário do provedor OAuth, o ID do cliente é passado com a solicitação inicial de um código de autenticaçã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. Ativado 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 Header extra às solicitações de atualização quando ativado.
• Ignorar prompt de consentimento do usuário: Controla o atributo prompt da solicitação de 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