• Issue Jira Produção: https://jiraproducao.totvs.com.br/browse/IDEIA-2626

• Reporter: TOTVS IDEIA

• Creator: Miguel Ninno Daipre

• Formulário de origem: Abertura de issue para Plataforma Carol

• Formulário preenchido por: miguel.daipre@totvs.com.br

• Informe a sua área de atuação na TOTVS: RH

• Ambiente impactado: Desenvolvimento

• Fase/estágio: Estamos em tempo de PROJETO

• Informe o assunto a ser direcionado: Quero reportar um tema que não consta em nenhuma das opções anteriores

• Informe a Org relacionada: arcadis

• Informe o tenant/ambiente relacionado: arcadis

• Ciente de que, caso precise trazer upload de anexos, ele deverá acontecer na issue criada no JIRA Produção.: Estou ciente que o envio destas evidências será realizado diretamente na issue criada no JIRA PRODUÇÃO.

• Informe a prioridade da sua issue: MÉDIA: não acontece em ambiente produtivo e nem possui impacto financeiro direto. Ex.: problemas de teste, homologação ou desenvolvimento.

• Sendo prioridade CRÍTICA, relate a justificativa:

• Descreva o seu problema:

Contexto

Na issue DRHCLOCKIN-11213, estamos implementando suporte a login SSO com Microsoft Entra ID no aplicativo TOTVS Clock In (React Native).

Atualmente, o app utiliza um WebView embutido (react-native-webview) para autenticação via Carol, porém esse método não compartilha cookies nem sessão de navegador, impossibilitando o uso da sessão Microsoft já ativa no dispositivo.

Para corrigir isso, estamos migrando o fluxo de autenticação para utilizar:

• Chrome Custom Tabs no Android

• ASWebAuthenticationSession / SFSafariViewController no iOS

Essas APIs permitem o uso do navegador real do sistema, aproveitando cookies e sessões já autenticadas do usuário.

Comportamento atual

Hoje, ao chamar a URL:

https://arcadis.carol.ai/auth?org=arcadis&redirect=/clockin-mobile&logout=false

O fluxo de autenticação é concluído com um redirect interno (mudando window.location ou href) e resposta HTTP 200.
Esse comportamento funciona em WebView, mas não é detectado pelas APIs nativas de autenticação (Custom Tabs / ASWebAuthSession), pois elas dependem de uma resposta HTTP real de redirecionamento (302/303/307) para encerrar a aba e retornar ao aplicativo.

Comportamento esperado

Ao finalizar o processo de autenticação, a Plataforma Carol deve retornar uma resposta HTTP 302 (Found) apontando para o deep link do aplicativo, conforme o exemplo abaixo:

HTTP/1.1 302 FoundLocation: clockin://deepLinkCallback?handoffToken=<TOKEN>

O redirecionamento deve respeitar o parâmetro redirect informado na URL de login, por exemplo:

https://arcadis.carol.ai/auth?org=arcadis&redirect=clockin://deepLinkCallback&logout=false

Esse comportamento permite que o Chrome Custom Tab (Android) e o ASWebAuthenticationSession (iOS) fechem automaticamente e retornem o controle ao app, entregando o token de autenticação (handoffToken).

Motivação técnica

O método utilizado no app é:

WebBrowser.openAuthSessionAsync(authUrl, redirectUrl)

Esse método monitora as navegações do navegador até detectar um redirecionamento HTTP 302 para o redirectUrl informado.

Somente nesse momento o fluxo é concluído e o controle retorna ao app.

Se o backend da Carol retornar apenas um HTTP 200 com redirecionamento via JavaScript, o evento não será detectado e o login não será finalizado.

Benefício esperado

• Permitir o uso da sessão já autenticada da Microsoft no dispositivo (SSO real via Microsoft Entra ID)

• Conformidade com práticas recomendadas de autenticação em apps móveis (OAuth2 + PKCE)

• Remover dependência de WebView e melhorar segurança e UX

Documentos técnicos de referência

Especificações oficiais que definem o uso de HTTP 302 no fluxo OAuth2:

1. RFC 6749 – The OAuth 2.0 Authorization Framework

   "If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI using the 'application/x-www-form-urlencoded' format, per Appendix B, in the HTTP response with a 302 (Found) status code."
   https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2

2. Authlete – OAuth 2.0 and OpenID Connect Authorization Endpoint Spec

   “For both Authorization Code Flow and Implicit Flow, OAuth 2.0 specifies that a successful response from the authorization endpoint is HTTP status ‘302 Found’, redirecting the user agent …”
   https://www.authlete.com/developers/definitive_guide/authorization_endpoint_spec/#2-response-format

3. Auth0 – OAuth2 Authorization Flow

   “A successful response is 302 Found, which triggers a redirect to the redirect_uri with the authorization code as a query parameter.”
   https://auth0.com/docs/authenticate/protocols/oauth

Esses documentos confirmam que o comportamento correto de um servidor de autorização é responder com HTTP 302 apontando para a redirect_uri após a autenticação bem-sucedida.

Próximos passos

Pretendo anexar um vídeo demonstrando:

1. O comportamento atual (redirect interno com 200)

1. O comportamento esperado (HTTP 302 → fechamento automático → retorno ao app)

Também estamos disponíveis para uma breve reunião e validação da implementação necessária na Carol.