Register and administer OAuth applications from Developer settings
Before an application can request tokens, an organization admin registers it. Registration and
day-to-day management happen in the Chamelio web application:
Open Developer settings
Create applications, manage scopes and redirect URIs, and rotate secrets
There you can create an application, choose the scopes it may request, register its redirect URIs,
view its client_id, and rotate or revoke its credentials.
You need the admin role to manage OAuth applications.
Shown to users on the consent screen. Must be unique in your organization
Description
Free-text note about what the application does
Client type
confidential for applications that can keep a secret (a backend service), public for those that cannot (mobile, desktop, browser). Public clients get no secret and rely on PKCE alone
Redirect URIs
The exact callback URLs allowed at /oauth/authorize. Required for the authorization code flow
Allowed scopes
The ceiling on what the application may ever request. See Scopes
Grant types
authorization_code, client_credentials, refresh_token. A public client cannot use client_credentials
Token lifetime
Leave unset for non-expiring access tokens. Setting it produces short-lived tokens and enables refresh tokens
The client_secret is displayed only once, when the application is created or its secret is
rotated. Chamelio stores only a hash, so it cannot be shown again - save it to your secret manager
immediately.
Allowed scopes are a ceiling, not a grant. They cap what the application may ask for; the scopes
a token actually carries are the ones a user approves at consent time.
Changing allowed scopes does not affect existing tokens. Removing a scope does not revoke tokens
already carrying it, and adding one does not widen tokens already issued - users must authorize again
to grant a new scope. To retire access immediately, revoke the token with
/oauth/revoke or delete the application.
Deleting an application revokes every token it ever issued. Any integration using it stops
working immediately. Its client_id is retired, and both /oauth/authorize and /oauth/token then
reject it as an inactive client.
Rotating a secret does not revoke tokens. Access and refresh tokens already issued keep working;
only new /oauth/token requests need the new secret. The old secret stops working the moment the
rotation succeeds, so deploy the new one promptly.
Register separate applications for staging and production. That keeps redirect URIs clean and lets
you retire one environment without disturbing the other.
