Choosing a flow

This page helps you pick the right authorization flow based on who is calling, whether a user is involved, and whether a browser is available. It also marks the actual level of support for each flow in wicket v0.1.4. The support levels come from reviewing the source and running the code, not from what the discovery document declares — the two disagree in a few places.

Decision table

Scenario	Typical examples	Recommended flow	SetAllowedGrantTypes	v0.1.4 status
Machine to machine, no user	Scheduled jobs, internal microservice calls	Client credentials	wicket.GrantTypesClientCredentials	Works; verified end to end
Server-side web app with a user	Traditional web back office, BFF	Authorization code + PKCE (confidential client)	wicket.GrantTypesCode	Works; the host must provide the login page and the login cookie handler
SPA / mobile app with a user	Single-page apps, iOS / Android apps	Authorization code + PKCE (public client, RequireClientSecret = false)	wicket.GrantTypesCode	Works; same as above
Staying signed in long term	Any of the user scenarios above	Add refresh tokens (offline_access)	Set AllowOfflineAccess on the client	Can be issued and used, but v0.1.4 does not yet implement expiration or rotation policies; the host must add safeguards
Devices without a browser or with limited input	TVs, CLI tools, IoT	Device authorization	wicket.GrantTypesDeviceFlow	Not for production: no built-in device authorization endpoint, and issued tokens lack scopes
Backend-initiated, user confirms on another device	Service counters, call-center identity checks	CIBA (poll only)	wicket.GrantTypesBackchannelAuthentication	Works; you must replace the default user validator, and the host implements user confirmation
User sign-out	All user scenarios	Sessions and logout	—	/connect/endsession works; front-/back-channel notifications and checksession have no effect

Quick decision

1. Who does the token represent? Only the service itself → client credentials. A user → continue.
2. Can the user act in the initiator's browser right now? Yes → authorization code + PKCE. No → continue.
3. Does the user confirm on another device while your backend initiates? Yes → CIBA. If it is a terminal without a browser → device authorization (in v0.1.4, use the alternatives listed on the device authorization page instead).

Discouraged or disabled-by-default flows

Flow	Notes
Implicit flow (response_type=token / id_token)	Still supported in code, but tokens travel through the browser address bar; use authorization code + PKCE for new apps. SetAllowedGrantTypes does not allow combining implicit with authorization_code
Resource owner password (password)	Rejected by default: without an injected validator, an "unsupported" placeholder implementation is used, and it does not appear in the discovery document's grant_types_supported. If you really need it for legacy compatibility, inject a validator with cfg.SetResourceOwnerValidator
Hybrid flow (code id_token, etc.)	Still supported in code; new apps have no reason to use it

Discovery document vs. actual implementation

Client libraries usually configure themselves from /.well-known/openid-configuration. Several entries in the v0.1.4 discovery document do not match reality. When integrating, rely on the flow pages on this site:

Discovery field	Declared	Actual
device_authorization_endpoint	/connect/deviceauthorization	Not registered; requests fall through to the host handler
revocation_endpoint	/connect/revocation	Not registered; requests fall through to the host handler
frontchannel_logout_supported / backchannel_logout_supported	true	Neither actually sends notifications
check_session_iframe	/connect/checksession	The page exists, but authorization responses do not return session_state

For a full description of the fields, see Discovery document.

Conventions shared by all flows

• The token endpoint POST /connect/token accepts only form-encoded bodies; client authentication supports client_secret_basic and client_secret_post.
• In v0.1.4, token endpoint errors always return HTTP 400 (including invalid_client). The response body is JSON with error, error_description, and a custom field.
• Successful responses always contain the id_token and refresh_token keys; when not issued, their values are empty strings.

Related reading

• Core concepts: how clients, resources, and scopes relate
• Clients and resources: Client field reference
• Protocol endpoints: all registered endpoints