# Seletor de fluxo OAuth

> Que tipo de app, existe usuário, precisa de acesso offline - e o grant certo volta com citação de RFC, com implicit e ROPC aposentados pelo nome conforme a RFC 9700.

- Tool: https://ronutz.com/pt-BR/tools/oauth-flow-chooser
- Family: Identidade e tokens

---

# Seletor de fluxo OAuth

A primeira pergunta de toda integração OAuth ou OpenID Connect - PingFederate, PingAM, PingOne, ou qualquer outra - é *qual fluxo*. Esta ferramenta codifica a resposta moderna como uma decisão determinística, e cita a RFC por trás de cada linha.

## Três perguntas

Que tipo de app é (web server-side, SPA, nativo, serviço-a-serviço, ou um dispositivo de entrada limitada)? Ele precisa saber **quem** é o usuário (esse é o trabalho do OpenID Connect, em camada sobre o mesmo fluxo)? Precisa de acesso com o usuário ausente (refresh tokens)?

## As respostas que ela dá

Apps server, SPA e nativos recebem todos **authorization code** - confidencial com segredo onde existe backend, público **com PKCE** (RFC 7636) onde não existe, e a regra do navegador-do-sistema da RFC 8252 explicitada para nativos. Serviço-a-serviço recebe **client credentials** (RFC 6749 §4.4) com a nota de que refresh tokens NÃO DEVEM ser emitidos ali. TVs e quiosques recebem o **device grant** (RFC 8628) com sua dança do user_code num segundo dispositivo.

## A metade que importa tanto quanto

Todo resultado inclui a lista de *evitados*: **implicit** e **ROPC (password)** aposentados pelo nome, conforme a Best Current Practice de Segurança do OAuth 2.0 (RFC 9700), com os motivos - tokens em fragmentos, credenciais dentro de apps - ditos com clareza. Clientes públicos pedindo acesso offline recebem a exigência de **rotação** de refresh tokens; pedir identidade de usuário final a um fluxo máquina-a-máquina gera um aviso de contradição em vez de uma resposta errada.

Tudo é decidido localmente; as três respostas não carregam segredos e nada é transmitido.

## Standards and references

- [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749)
- [RFC 7636 - Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636)
- [RFC 8252 - OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252)
- [RFC 8628 - OAuth 2.0 Device Authorization Grant](https://www.rfc-editor.org/rfc/rfc8628)
- [RFC 9700 - Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700)

## Related reading

- [Fluxos OAuth: escolhendo o grant em 2026](https://ronutz.com/pt-BR/learn/oauth-choosing-the-grant.md): Uma decisão inicia toda integração: qual fluxo. A resposta moderna é curta - authorization code + PKCE para humanos, client credentials para máquinas, device grant para TVs - e as razões pelas quais implicit e ROPC morreram valem saber de cor. A RFC 9700 finalmente escreveu tudo isso.