Autenticação
OAuth 2.0 client credentials, escopos e validade do token.
A API usa OAuth 2.0 com o fluxo client credentials: o seu servidor troca o client id e o client secret por um access token (JWT) e o envia em toda chamada:
Authorization: Bearer <access_token>Gerando o token
curl -s https://auth.u2dtecnologia.com.br/realms/u2d-pay/protocol/openid-connect/token \
-u "$CLIENT_ID:$CLIENT_SECRET" \
-d grant_type=client_credentials- As credenciais vão no header
Authorization: Basic(o-udocurl), como recomenda a RFC 6749. - O token vale 5 minutos (
expires_in: 300) e não tem refresh token: perto de expirar, peça outro com as mesmas credenciais. - Guarde o token em memória no servidor e reaproveite-o. Pedir um token por chamada deixa a integração mais lenta sem ganho de segurança.
O secret nunca vai para o navegador ou app
O fluxo client credentials é para servidor. Não use o secret em front-end, app mobile ou repositório de código. Se ele vazar, peça a troca pelo Atendimento.
Escopos
O que cada token pode fazer depende dos escopos liberados para o seu client:
| Operação | Escopo |
|---|---|
Consultar cobranças (GET /payments) | pagamentos:read |
Criar cobranças (POST /payments) | pagamentos:write |
Lojista do token
Cada client pertence a um lojista, e a API usa o token para saber de quem é a chamada. Você nunca envia o id do lojista: toda cobrança criada fica com o lojista do token, e uma consulta só enxerga as cobranças dele.
Erros de autenticação
| Status | Quando | Header WWW-Authenticate |
|---|---|---|
401 | Token ausente | Bearer |
401 | Token inválido, expirado ou de outro ambiente | Bearer error="invalid_token" |
403 | Token válido, mas sem o escopo da operação | Bearer error="insufficient_scope" |
Num 401 com invalid_token, gere um token novo e repita a chamada uma vez. Se persistir, confira as
credenciais do ambiente.