Quando você tem um servidor confiável (Node, .NET, PHP etc.), faça a troca de token ali para o client secret nunca chegar ao navegador.

Isso corresponde a configurações OAuth de código customizadas que você controla. Os caminhos em popup do SDK React e JS puro são separados — Intastellar Sign-In — React e JavaScript.

Como encaixa

1. O navegador termina o fluxo de redirect e cai no seu callback com code e state.
2. Sua rota de callback verifica state e chama o backend (ou roda no servidor na mesma requisição) para trocar o código.
3. O backend faz POST em TOKEN_ENDPOINT com grant_type=authorization_code, code, redirect_uri, client_id e client_secret.
4. O backend cria uma sessão para o usuário (define cookie, guarda tokens no servidor).
5. O navegador é redirecionado ao app só com seu cookie de sessão (não o secret).

Exemplo (conceitual)

POST TOKEN_ENDPOINT
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

Inclua parâmetros PKCE se este cliente for híbrido ou se o passo de autorização usou PKCE.

Armazenamento do secret

• Carregue client_secret de variáveis de ambiente ou gerenciador de secrets.
• Rotacione secrets se expostos; use credenciais separadas por ambiente.

Perguntas frequentes

O front-end pode chamar a URL de token com o secret?

Não. Tudo no navegador pode ser copiado. Mantenha o secret no servidor.

Usamos PKCE no navegador — ainda usamos o secret?

Depende do tipo de cliente e do registro. Se o navegador iniciou o fluxo com PKCE como cliente público, a troca pode não usar secret — confira no console. Existem configurações híbridas; siga sua referência técnica.

Próximo

Logout, erros e solução de problemas.