Registering a client
How to obtain a client_id, confidential vs public clients, whether client_secret may live in the frontend, and why the developer platform is not live yet.
What is the first step
Register a client to obtain client_id (plus client_secret for confidential clients), then follow Quick start to run one complete flow. The developer platform is not live yet; registration is currently handled manually by operations.
Confidential or public client
| Type | Suitable for | Has client_secret |
|---|---|---|
Confidential (server-side web_client, service) | Has a trusted backend that can keep a secret safe | Yes |
| Public (pure frontend, mobile, desktop) | Cannot keep a secret | No — client_id + PKCE only |
There is exactly one criterion: can this runtime keep the secret away from the user. Frontends, mobile binaries and desktop apps cannot.
Can client_secret live in the frontend
No. Shipping it in a browser or a mobile binary is publishing it. If you need a browser-side client, register a separate secretless client and keep the token exchange on the server.
Can one application register several clients
Yes, and usually it should: Web, mobile and test environments each get their own registration, so redirect URIs and types do not interfere. Revoking or rotating a secret then only affects that one client.
Related
- Registration fields and flow: Register a client
- Redirect URI requirements: Redirect and code flow
Integration and debugging
Developer-side FAQ — registering a client, redirect URIs, code exchange, refresh and validation, grouped by integration stage.
Redirect and code flow
Redirect URIs rejected as unregistered, testing callbacks locally, and why implicit flow and the password grant are unsupported.