# OAuth flow chooser

> What kind of app, is there a user, offline access needed - and the right grant comes back RFC-cited, with implicit and ROPC retired by name per RFC 9700.

- Tool: https://ronutz.com/en/tools/oauth-flow-chooser
- Family: Identity & tokens

---

# OAuth flow chooser

The first question of every OAuth or OpenID Connect integration - PingFederate, PingAM, PingOne, or anything else - is *which flow*. This tool encodes the modern answer as a deterministic decision, and cites the RFC behind every line of it.

## Three questions

What kind of app is it (server-side web, SPA, native, service-to-service, or a limited-input device)? Does it need to know **who** the user is (that is OpenID Connect's job, layered on the same flow)? Does it need access while the user is away (refresh tokens)?

## The answers it gives

Server, SPA, and native apps all get **authorization code** - confidential with a secret where a backend exists, public **with PKCE** (RFC 7636) where one does not, and the RFC 8252 system-browser rule spelled out for native. Service-to-service gets **client credentials** (RFC 6749 §4.4) with the note that refresh tokens SHOULD NOT be issued there. TVs and kiosks get the **device grant** (RFC 8628) with its user_code-on-a-second-device dance.

## The half that matters just as much

Every result includes the *avoided* list: **implicit** and **ROPC (password)** are retired by name, per the OAuth 2.0 Security Best Current Practice (RFC 9700), with the reasons - tokens in fragments, credentials in apps - stated plainly. Public clients requesting offline access get the refresh-token **rotation** requirement; asking a machine-to-machine flow for end-user identity raises a contradiction warning instead of a wrong answer.

Everything is decided locally; the three answers carry no secrets and nothing is transmitted.

## 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

- [OAuth flows: choosing the grant in 2026](https://ronutz.com/en/learn/oauth-choosing-the-grant.md): One decision starts every integration: which flow. The modern answer is short - authorization code + PKCE for humans, client credentials for machines, the device grant for TVs - and the reasons implicit and ROPC died are worth knowing by heart. RFC 9700 finally wrote it all down.