OAuth2

Definição

OAuth2 (Open Authorization 2.0) é o padrão mundial de autorização delegada: permite a um aplicativo de terceiros acessar recursos protegidos em nome de um usuário, sem manipular sua senha.

É o que está por trás do botão "Entrar com o Google" — e o protocolo que todas as APIs DSP2 usam para materializar o consentimento do PSU e emitir os tokens de acesso aos TPPs.

OAuth2 vs OpenID Connect vs OAuth1

OAuth2 — autorização ("autorizo este app a ler minhas contas"), o protocolo de base.
OpenID Connect (OIDC) — camada de autenticação posta sobre o OAuth2 ("este app sabe que sou realmente eu"), usada para o SSO de grande público.
OAuth1 (2010) — padrão antigo, mais complexo, praticamente abandonado.

Na DSP2, é OAuth2 em todo lugar, às vezes enriquecido com blocos OIDC para autenticar o PSU.

O fluxo DSP2: Authorization Code + PKCE

O TPP monta uma URL de autorização e redireciona o PSU para a página de autenticação do ASPSP.
O PSU se autentica (login + SCA) e consente o perímetro solicitado.
O ASPSP redireciona o PSU de volta ao callback do TPP com um código de autorização de uso único.
O TPP troca esse código (do lado do servidor, via mTLS + QSealC) por um access token e um refresh token.
O TPP usa o access token (em Authorization: Bearer) a cada chamada.

O PKCE (Proof Key for Code Exchange) protege contra a interceptação do código e é obrigatório na DSP2.

Os conceitos-chave

Resource Owner — o PSU (proprietário do dado).
Client — o TPP (o aplicativo que pede o acesso).
Resource Server — a API do ASPSP (que hospeda o dado).
Authorization Server — o servidor do ASPSP que autentica e emite os tokens.
Scope — o perímetro do consentimento (accounts.read, payments.write).
Access Token — token curto (de 5 a 60 min) para chamar a API.
Refresh Token — token longo (até 180 dias no AIS) para renovar o access token sem refazer a SCA.

O que o OAuth2 não faz

Não autentica o usuário: isso é o OIDC ou a SCA do lado do banco.
Não assina as requisições: isso é o QSealC na DSP2.
Não protege o transporte: isso é o mTLS com QWAC.
Não define os scopes de negócio: cada ASPSP e cada padrão (STET, Berlin Group) os define.

Especificidades da DSP2

O OAuth2 "puro" não basta; ele é sempre complementado por:

mTLS + QWAC no nível de transporte;
HTTP-signature + QSealC no nível de aplicação;
PKCE obrigatório no Authorization Code Flow;
SCA disparada pelo ASPSP no consentimento (e a cada 180 dias para o AIS);
refresh token longo para o AIS (até 180 dias desde a evolução dos RTS em 2022).

No ecossistema PSD2

O OAuth2 é o mecanismo de consentimento universal da DSP2: sem ele, não haveria nenhuma forma padronizada de um PSU autorizar um TPP a acessar suas contas sem entregar sua senha.

Exemplos concretos

Conexão de um AISP: ligar o Bankin' ou o Pennylane ao seu banco é exatamente o Authorization Code Flow + PKCE — a janela de redirecionamento para o seu banco corresponde às etapas 1 a 3.
Refresh token longo: desde 2022, um AISP mantém um refresh token por até 180 dias sem refazer a SCA, o que permite atualizar suas contas todos os dias durante 6 meses.
Erro frequente: confundir code_verifier e code_challenge (o challenge = SHA256(verifier) enviado na autorização, o verifier enviado na troca) → invalid_grant.
Bibliotecas: openid-client (Node, PKCE + mTLS), Authlib (Python), Spring Security OAuth2 Client (Java) — preferíveis a uma implementação caseira.
Scopes: os nomes diferem (aisp/pisp/cbpii vs accounts.read/payments.write) — é preciso ler a spec de cada ASPSP.
Evolução FIDA: o OAuth2 continua sendo o protocolo pivô do consentimento, enriquecido com um Permission Dashboard unificado e scopes ampliados (seguros, crédito, poupança).