Detalhes técnicos e de configuração do OAuth2.0

Neste artigo, vamos nos aprofundar nos detalhes técnicos de como a Tulip implementa o OAuth para autenticação de conectores. O OAuth é poderoso, mas vem com alguma complexidade adicional. Este guia tem o objetivo de abordar quaisquer questões técnicas sobre o que a Tulip suporta e como ele é integrado.

Observação: O fluxo de Credenciais do Cliente difere um pouco do fluxo do código de autorização. As etapas 1 e 2 não são relevantes para o fluxo de Credenciais do Cliente.

Fluxo do código de autorização da Tulip

:::(Warning) (Serviços On-Prem) Os endpoints Authorize e Token devem estar acessíveis à nuvem para que a Tulip execute a autenticação para conectores :::

A Tulip inicia o processo de autenticação ao testar um conector ou executar uma função de conector em um aplicativo.

1. Redirecionar para o servidor de autorização:

O aplicativo da Tulip redireciona o usuário para o Authorization Server (AS) juntamente com parâmetros específicos, incluindo response_type (definido como "code" para Authorization Code Flow), client_id (atribuído na UI do conector), redirect_uri (predefinido pela Tulip), escopo e público (definidos na UI) e estado (uma string aleatória para proteger contra ataques de Cross-Site Request Forgery).

Exemplo:GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. O usuário concede o consentimento:

O servidor de autorização autentica o usuário e apresenta a ele uma tela de consentimento. O usuário pode analisar as permissões solicitadas e decidir se concede ou nega acesso ao aplicativo de terceiros.

:::(Warning) (Observação) Na configuração de um conector give, o controle "Skip user consent prompt" permite controlar o atributo prompt na solicitação de autorização. Com esse controle desativado, será usado o valor consentimento; quando ativado, será usado o login.

Se forem necessários valores adicionais do atributo prompt, entre em contato com support@tulip.co e habilitaremos outras opções para essa propriedade. :::

3. Código de autorização:

Se o usuário conceder consentimento, o Authorization Server gera um código de autorização e redireciona o usuário de volta à Tulip junto com o código de autorização. O parâmetro de estado também é incluído, permitindo que o cliente verifique a integridade da resposta. Esse parâmetro de estado deve corresponder ao parâmetro de estado passado na Etapa 1.

Exemplo de redirecionamento para o URI de redirecionamento do cliente:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Solicitação de token:

O cliente agora tem o código de autorização e o utiliza para fazer uma solicitação segura de servidor para servidor ao ponto de extremidade do token do servidor de autorização. O cliente inclui o grant_type (definido como "authorization_code"), client_id, client_secret (um segredo conhecido apenas pelo cliente e pelo servidor de autorização), redirect_uri e o código de autorização.

Exemplo de solicitação de token:

grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET ```


### 5. Resposta do token de acesso:


Se o código de autorização for válido, o servidor de autorização responderá com um token de acesso e, opcionalmente, um token de atualização. O token de acesso é usado pelo cliente para se autenticar ao fazer solicitações à API protegida em nome do usuário.


Exemplo de resposta de token:


`{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE" }`


### 6. Acessar o servidor de recursos:


A Tulip agora pode usar o token de acesso obtido para fazer solicitações autorizadas ao Resource Server (API) em nome do usuário. O token de acesso geralmente é incluído no cabeçalho Authorization (Autorização) da solicitação HTTP.


Exemplo de solicitação de API:`GET /api/resource Authorization: Portador ACCESS_TOKEN`


## Gerenciando a expiração do token com tokens de atualização


Os servidores de autorização normalmente definem datas de expiração para os tokens para regular o acesso, com janelas de expiração variáveis, dependendo do sistema com interface. No entanto, os tokens de curta duração representam um desafio, pois a autenticação constante do usuário interrompe a experiência do usuário nos aplicativos Tulip.


Para resolver esse problema, o OAuth oferece suporte a tokens de atualização. Embora opcionais, eles são altamente recomendados, pois simplificam a experiência do usuário, permitindo que a Tulip atualize os tokens sem problemas, sem a necessidade de intervenção manual dos operadores.


### Como a Tulip gerencia a atualização de tokens


Quando a Tulip detecta que um token de acesso expirou, ela tenta automaticamente usar o token de atualização associado para obter um novo token. O objetivo principal é minimizar a reautenticação do usuário. As etapas a seguir descrevem a lógica executada pela Tulip:


![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)


1. **Detecção de expiração:**
2. A Tulip identifica um token expirado com base em seu atributo `expires_in` recebido na [etapa 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) do fluxo de autenticação.
3. **Tentativa de fluxo de token:**
4. A Tulip inicia o fluxo de token usando o tipo `de` concessão `refresh_token`, substituindo o tipo `de` concessão `authorization_code` usado no fluxo de autenticação inicial.
5. **Validação de token:**
6. Se um novo token for obtido, a Tulip o armazena e prossegue com a execução da função de conector solicitada pelo usuário.


	* Se for bem-sucedido, os dados serão fornecidos ao tempo de execução do aplicativo Tulip.
	* Se o novo token falhar com um erro OAuth, a Tulip tenta novamente o processo até 5 vezes, voltando à etapa 1 a cada vez.
	* Se o novo token falhar com qualquer outro erro, um erro será exibido no tempo de execução do player.
7. **Tratamento da ausência de token:**
8. Se um novo token não for fornecido, o Tulip solicita que o usuário no player se submeta à autenticação, iniciando todo o processo de autenticação.
9. Após a conclusão, a função do conector é executada e os dados são retornados.


Ao implementar tokens de atualização, a Tulip garante uma experiência de usuário mais tranquila, gerenciando de forma inteligente a expiração e a renovação do token, minimizando as interrupções no fluxo de trabalho.


## Leitura adicional


* [Introdução aos Hosts de Conectores da Tulip](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Snapshotting do conector](/r230/docs/connector-snapshotting)
* [Explicação sobre o OAuth2.0](/r230/docs/oauth20-explained)