Troca o código de autorização, renova o token do usuário final ou emite o token M2M
O backend do seu produto troca o código que o widget entregou (authorization_code, com o code_verifier do PKCE) e renova (refresh_token). O cliente M2M pede o próprio token por client_credentials com Authorization Basic, sem a chave secreta (aí o escopo auth:token não se aplica). Sempre Cache-Control: no-store. Exige uma chave secreta criada COM o escopo auth:token (chaves sem restrição não o têm).
Autorizações
Chave secreta (unifokal_live_ em produção, unifokal_test_ no sandbox: 64 hex mais CRC-32) no Authorization: Bearer. Só no seu servidor: nunca no browser ou app (o widget monta apenas com o id vs_ da sessão). Não existe chave publishable.
Corpo
- Option 1
- Option 2
- Option 3
Três concessões (RFC 6749): authorization_code (com a chave secreta e o code_verifier do PKCE S256), refresh_token (com a chave secreta) e client_credentials (cliente M2M por client_secret_basic, sem a chave secreta). Aceita application/x-www-form-urlencoded ou JSON.
Resposta
Tokens emitidos. AuthTokenResponse na troca do código, AuthRefreshResponse na renovação, M2mTokenResponse no client_credentials.
- Option 1
- Option 2
- Option 3
Resposta da troca do código (authorization_code). Sempre Cache-Control: no-store.
JWT de acesso (RFC 9068, typ at+jwt, RS256). Verifique localmente pelo JWKS do emissor.
"Bearer"Segundos de vida do token de acesso.
Refresh opaco com rotação: cada renovação devolve um novo; reapresentar um antigo derruba a sessão.
Segundos até o fim da sessão (o menor entre o prazo ocioso e o absoluto).
^ses_[0-9A-HJKMNP-TV-Z]{26}$Métodos de autenticação usados (RFC 8176): pwd, otp_email, otp_sms, totp, recovery.
aal1, aal2 A verificação do cadastro com KYC no mesmo flow; null no login.