Estou trabalhando em um fluxo OAuth 2.0 usando Authorization Code Grant com PKCE, envolvendo dois servidores locais:
- https://sso-identify.test (servidor SSO)
- https://cookie-1.test (Aplicação web front-end)
O que implementei:
O frontend redireciona o usuário para autorização e depois retorna a chamada para /auth/callback
.
No retorno de chamada, troco o código de autorização por tokens de acesso e atualização usando um /oauth/tokens
endpoint dedicado em sso-identify.test.
Laravel responde com:
{
"access_token": "...",
"refresh_token": "...",
"expires_in": "..."
}
Nesse caso, o JS terá acesso ao refresh_token.
Como armazeno o refresh_token?
Todos os tokens devem ser trocados entre os servidores e armazenados no servidor identificado pela sessão do usuário. Isso significa que o usuário deve ter apenas uma sessão no servidor do front-end . Obviamente, essa sessão se manifesta no cliente como um cookie que contém apenas o ID da sessão.
O
access_token
é usado para chamadas de API e é armazenado na memória do cliente, pois expira deexpires_in
qualquer forma. Quando chegar a hora de atualizar oaccess_token
, faça uma chamada de API para o SEU servidor, que contém a sessão e, portanto, todos os tokens necessários para atualizar oaccess_token
.O armazenamento acessível via JavaScript não é seguro.
Resumindo, não armazene
refresh_token
no cliente.Atualização: Posso ter reduzido alguns detalhes sobre a sessão, mas a ideia é que ela
refresh_token
não seja acessível ao javascript do cliente.