Registering a client and redirect URIs
What to submit, what credentials you receive, and the hard rules for redirect URIs.
Before writing a single line of code you must own a registered client. The authorization server only accepts registered client_id values paired with registered redirect URIs; any other combination is rejected outright.
The developer platform is not live yet
Self-service client creation is currently unavailable. Prepare the details listed on this page and submit them to MuoCeon operations for registration. Once done you receive the client_id, and confidential clients additionally receive a client_secret (shown only once — store it safely). When the platform launches, the flow and fields stay the same.
What to submit
| Field | Required | Notes |
|---|---|---|
| Application name | ✅ | Shown verbatim on the consent page; users judge "should I hand my account to this?" from it |
| Application type | ✅ | Third-party / server-to-server (first-party is registered internally by MuoCeon) |
| Redirect platform | ✅ | web_server / web_client / desktop / ios_macos / android; determines confidentiality and token lifetimes |
| Redirect URI | ✅ | Must satisfy the rules below; at least one per client |
| Required scopes | ✅ | Delegable scopes only; see Scopes and audiences |
| Homepage / privacy policy | Recommended | Reviewed during approval and helps users verify the source on the consent page |
| Application icon | Optional | Displayed on the consent page |
Client types
| Type | Used by | Has a user | Has a device identity |
|---|---|---|---|
first_party | MuoCeon's own applications | Yes | Yes (did) |
third_party | External developers — that is you | Yes | No |
machine | Server to server | No | No |
The type decides three things you cannot work around: whether client_credentials is allowed (only machine), whether the token carries did (first-party only), and whether self-management scopes may be requested (first-party only).
Redirect platform and token lifetimes
The platform is not a free choice — it directly determines the client's confidentiality level and the token TTL caps.
| Platform | Allowed redirect URI shape | Confidentiality | Access token | Refresh token |
|---|---|---|---|---|
web_server | https://host/path (path required); loopback may use http://localhost:3000/path | Confidential | 1 hour | 30 days |
web_client | Same address rules as web_server | Public | 30 minutes | 14 days |
desktop | Loopback address (path required) or a custom scheme (e.g. myapp://callback) | Public | 30 minutes | 14 days |
ios_macos | com.muoceon.<bundle-id>://auth | Public | 30 minutes | 14 days |
android | com.muoceon.<package>://auth/<signature hash> | Public | 30 minutes | 14 days |
One client, one confidentiality level
If a product has both a server side and a browser side, split it into two clients: the web_server
one holds the client_secret, the web_client one does not. Putting a secret into a browser, or letting
a public client share a confidential client's client_id, is publishing the secret.
Hard rules for redirect URIs
Each rule is checked at registration (failure rejects the registration) and checked again during the authorization request.
- Must be
https, or loopbackhttp(localhost/127.0.0.1/[::1]), and must carry a non-root path — an address without a path such ashttps://example.comis rejected. - No query, fragment, username or password (
https://example.com/cb?x=1,https://example.com/cb#frag,https://user:pass@example.com/cbare all rejected). - Scheme blocklist:
javascript,data,file,blob,about,vbscript. - Maximum length 2048 characters, and it must parse as a valid URL.
- For loopback addresses the port may vary (RFC 8252 §7.3); everything else must match exactly.
Matching rules
The redirect_uri in the authorization request is compared against registered values:
- Exact match: scheme, host, port, path and trailing slash must all be identical.
- Loopback exception: when the host is
localhost/127.0.0.1/[::1], only the port is ignored; the path must still match. - Missing
redirect_uri: falls back to the registered address only when the client has exactly one usable redirect URI; omitting it while multiple addresses are registered is an invalid request.
Details and common rejection causes are in Redirect URI policy.
Checklist after registration
- You have the
client_id; for confidential clients theclient_secretis stored safely (not in the frontend, not in the repo). - The redirect platform matches the product shape, with no single client mixing multiple shapes.
- Every requested scope is delegable and genuinely needed by the feature.
- Authorization requests always carry
redirect_uriexplicitly; do not rely on the fallback. - A persistable
statestore exists so the callback can be compared.