Which OpenID Connect flows exist, and when is each one appropriate?
Authorization code flow (the code is exchanged for tokens at the token endpoint, usually with client authentication; the standard choice), implicit flow (all tokens from the authorization endpoint, no client authentication; not recommended) and hybrid flow (a combination: the ID token goes straight to the client, the backend gets the tokens via the back channel).
| Flow | response_type |
Where tokens come from | Use |
|---|---|---|---|
| Authorization code | code |
Token endpoint, back channel | Web clients with a backend; with PKCE also SPAs and native apps. Allows long-lived access via refresh tokens. |
| Implicit | id_token or id_token token |
Authorization endpoint, in the redirect | Originally for browser-script clients that cannot keep secrets. Simplest (one request), but only the redirect URI is checked. Not recommended. |
| Hybrid | code id_token, code token, code id_token token |
Some from the authorization endpoint, the rest from the token endpoint | The front end gets an ID token immediately; the backend receives and manages all tokens via the back channel. |
For native apps (Android, iOS), the authorization code flow runs in the system browser, and a draft extension (OpenID Connect Native SSO) lets several apps from the same vendor share a single login. Well-known OpenID Providers include Apple, Google and Microsoft. Facebook's classic login is plain OAuth plus its own Graph API, although Meta now also publishes an OIDC configuration for its "Limited Login" that returns ID tokens.
Go deeper:
OpenID Connect Core 1.0: Authentication — the table mapping response_typevalues to flows and their characteristics.- OpenID Connect Core 1.0: Hybrid Flow — how tokens are split between the two endpoints.
- RFC 8252: OAuth 2.0 for Native Apps — why native apps must use the system browser and PKCE.