Client types and the permission model
The differences between confidential web apps, public SPAs, and service-to-service calls, and how permissions are declared.
A PandaAuth client registration has three dimensions: client type (whether it holds a secret), declared permissions (which endpoints and grant types it may use), and the callback allowlist (redirect and post-logout callbacks, matched strictly).
Three client types
| Type | Typical scenario | Grant types | PKCE | Secret |
|---|---|---|---|---|
| Confidential web client | Traditional server-rendered web apps | Authorization code + refresh token | Recommended | Yes (kept server-side) |
| Public client | SPAs, mobile, desktop | Authorization code + refresh token | Required | None |
| Service-to-service (M2M) | Background services, daemon jobs | Client credentials | Not applicable | Yes |
Key points:
- Public clients hold no secret; their security rests entirely on the authorization code flow + PKCE. Production deployments require PKCE globally, and PKCE is a mandatory requirement when registering a public client.
- A confidential client’s secret should only ever exist on the server side; secrets can be rotated by an administrator, and once rotated the old secret stops working immediately.
- M2M clients have no user context; their tokens represent the client itself, and scopes are constrained by the registered permissions.
Declared permissions
A client registration declares what it may do; endpoints and grant types that were not declared are always rejected. Declarations are grouped:
- Endpoints: authorize / token / end-session / revocation / introspection;
- Grant types: authorization_code / client_credentials / refresh_token;
- Response types: only
codeis currently enabled; - Scopes:
openid,profile,email,roles,offline_access, and custom business scopes (such asapi).
Callback allowlist
redirect_uri and post_logout_redirect_uri are matched strictly against the
registered allowlist (as absolute URIs); requests that do not match simply fail.
Allowlist changes go through the administration channel and are recorded in the audit log.
Next steps
- For flow details, see the Quickstart;
- For token contents and validation, see the Endpoint reference and Security facts.