O rascunho RFC OAuth 2.0 para aplicativos baseados em navegador (publicado: 17 de janeiro de 2025) introduz o padrão BFF em 6.1. Backend para frontend (BFF) .
Aqui está a arquitetura:
O rascunho diz
o aplicativo JavaScript aciona uma navegação para o BFF (C) para iniciar o fluxo do Código de Autorização com a extensão PKCE (descrita na Seção 6.1.3.1), ao qual o BFF responde redirecionando o navegador para o ponto de extremidade de autorização (D).
Quando o usuário é redirecionado de volta, o navegador entrega o código de autorização ao BFF (E), onde o BFF pode então trocá-lo por tokens no ponto de extremidade do token (F) usando suas credenciais de cliente e o verificador de código PKCE.
Isso implica PKCE code_verifier, code_challengee code_challenge_methodtodos são calculados e armazenados no lado do servidor, mas por quê?
Tenho três perguntas:
No passo (E), o cliente envia um código de autorização para o backend. No entanto, como o backend pode identificar de onde
code_verifieresse código de autorização foi derivado? Acho que não tem como, porque o snippet não lê nada além de um código de autorização enviado no passo (E).Embora não mencionado no rascunho, esse problema de "como-identificar-o-verificador-de-código" pode ser resolvido emitindo uma sessão temporal como
HttpOnlycookie com antecedência e deixando o cliente enviá-la na etapa (E). Estou certo?Se eu estiver correto, por que se preocupar em usar sessão temporal (como
HttpOnlycookie)? Acho que apenas calcularcode_verifier,code_challengeecode_challenge_methodo lado do cliente removeria completamente a necessidade de sessão temporal. Na etapa (E), o cliente pode enviar,code_verifieralém disso, um código de autorização para o backend.
Do ponto de vista do OpenID-Connect, o módulo BFF se torna o cliente em relação ao Authorization Server. O PKCE é calculado no lado do servidor porque o ponto inteiro do BFF é mudar a lógica de autenticação do navegador para o backend. Também é importante lembrar que o BFF geralmente está localizado em um "servidor/serviço" separado do seu Authorization Server.
Além disso, o PKCE só é aplicável quando você usa o fluxo de código de autorização, que visa autenticar um usuário e trocar o código pelo token de forma segura.
Para responder à sua pergunta.
O BFF é registrado como um cliente no servidor de autorização e cada tentativa de autenticação do "BFF" obtém um code_verifier diferente gerado e normalmente armazenado em um cookie de navegador separado durante o processo de autenticação.
Geralmente é implementado como um cookie HTTP Only temporário.
A grande ideia com tudo isso é evitar qualquer lógica de autenticação no navegador. O navegador e os aplicativos móveis são clientes públicos. Ou seja, eles não podem manipular ou manter segredos.
Você pode encontrar mais informações sobre PKCE e OpenID-Connect em: OpenID Connect para desenvolvedores