Skip to main content

Managing Applications

note

Managing applications requires a role with the applications:read/ applications:create/applications:update/applications:delete scopes — see Using o2idctl for how to log in, and Managing Roles for how to create and assign roles.

Use o2idctl to manage applications (OAuth 2.0 clients) through the API:

./o2idctl applications create --name "My App" --callback-url https://myapp.example.com/callback
./o2idctl applications list

Pass --public to create a client with no secret, or --client-secret <secret> to create a confidential client. OAuth requests reference the application's clientId, not its internal id.

Allowed scopes​

An application's tokens can never carry more than the RBAC scopes it's been explicitly granted, regardless of what its logged-in user's own role permits — the effective scope of any issued token is the intersection of the application's allowed scopes and the user's role scopes. New applications are created with no allowed scopes (deny-by-default): a user logging in through a freshly created application can't exercise any management-API permission through it until an admin grants some.

./o2idctl applications create --name "My App" \
  --callback-url https://myapp.example.com/callback \
  --scope users:read --scope applications:read

Repeat --scope to grant more than one. Passing --scope to applications update replaces the full list — it isn't merged with the existing one, the same replace-not-merge semantics as --callback-url. Grant --scope "*" for every scope, present and future (this is what the seeded o2idctl CLI application itself is granted, so command-line management keeps working for any user regardless of which scopes get added later). See the API Reference for the scope each management endpoint requires, and Managing Roles for the role/scope model this intersects with.

Resource server authorization​

Separately from allowed scopes, an application can be authorized to mint or introspect tokens for one or more registered resource servers, each with its own granted subset of that resource server's own scopes — see Managing Resource Servers for how to grant this and Getting a Token for a Resource Server for how an application then uses it.

See the CLI Reference for the full applications command list, and the API Reference for the underlying /applications API.