API v2: autenticação por par de chaves

Sua integração autentica com um par de chaves. A privada fica com você e assina cada requisição; nós guardamos só a pública. Não existe client_secret.

Nada que vaze do nosso lado permite se passar por você, porque não há nada do nosso lado para vazar. Um token roubado sozinho não serve: toda chamada precisa ser assinada por uma chave que nunca temos.

PASSO 1

Gere o par de chaves

EC P-256, na sua própria infraestrutura.

PASSO 2

Registre a pública

Uma credencial = uma chave, uma conta, um perfil.

PASSO 3

Obtenha um token

Curto: 60 segundos, para qualquer perfil.

PASSO 4

Assine cada requisição

Uma prova DPoP por chamada, presa ao método, URL e corpo.

REFERÊNCIA

Erros

O que cada recusa significa e como resolver.

VINDO DA v1

Migração

Lado a lado com a integração atual.

O que muda da v1

	v1	v2
Credencial	client_id + client_secret	client_id + sua chave pública
Pedido de token	segredo no corpo	JWT assinado pela sua privada
Validade do token	2 horas	60 segundos
Token roubado	funciona até expirar	inútil sem a chave privada
Prova por requisição	não existe	prova DPoP, presa a método, URL, query e corpo
Revogação	desabilita o segredo	irreversível, e vale em cerca de um segundo

A v1 continua funcionando. A v2 é uma superfície separada, em /v2/*, então você migra uma integração por vez.

Os endereços

Ambiente	Autenticação	API
Sandbox	https://api.sdb.lbpay.com.br/v2/oauth/token	https://api.sdb.lbpay.com.br/v2/*
Produção	https://api-secure.lbpay.com.br/v2/oauth/token	https://api-secure.lbpay.com.br/v2/*

Como é uma requisição

O que você precisa construir

Dois JWTs curtos, ambos assinados em ES256 com a sua chave privada: a client assertion e a prova DPoP. Qualquer biblioteca que assine JWT dá conta, e a biblioteca padrão da sua linguagem também. Os exemplos desta seção não usam dependência nenhuma para a parte de assinatura.