Move Global OAuth Client Management to Superuser/Admin Section

Background

Currently, global OAuth clients are created through the same flows as user/project OAuth clients and are “owned” by the creating user. This leaves administration in a difficult position because in the event a client id or secret needs to be changed; only the person who created the credential can do it. Global OAuth clients should be managed exclusively by superusers, with no individual owner, and only from a dedicated admin section.

Problems to Solve

• Global OAuth clients are “owned” by a user, which restricts visibility and editability.
• Global OAuth client creation is available in user/project credential flows.
• There is no central place for superusers to manage global OAuth clients.
• No audit trail for which superuser created/edited a global client.

Proposal

1. Remove Global OAuth Client Creation from User/Project Flows

• The “Make client global” checkbox and any related UI should be removed from all user and project credential creation/editing forms.
• Only project-specific or user-specific OAuth clients can be created from these flows.

2. Add a Dedicated Admin/Superuser Section for Global OAuth Clients

• Add a new section/page in the Admin/Superuser menu for managing global OAuth clients.
• Only superusers can access this section.
• This section should allow superusers to:
  • List all global OAuth clients.
  • Create new global OAuth clients.
  • Edit and delete existing global OAuth clients.
  • View all details of global OAuth clients, including client ID, client secret, scopes, and any other configuration fields.

3. Ownership Model for Global OAuth Clients

• Global OAuth clients will always have a user_id, which represents the creator of the client (not the owner).
• All superusers can manage (view/edit/delete) global OAuth clients, regardless of who created them.
• The user_id field should always be populated for all OAuth clients (global or not).

4. Update Permissions and Visibility

• Only superusers can create, edit, or delete global OAuth clients.
• Regular users cannot create or manage global OAuth clients, even by forging requests (enforce in backend).
• Regular users can select global OAuth clients when creating a new credential, but cannot see or manage the global clients themselves.
• Global OAuth clients should not appear in the user’s or project’s credential list.
• Global clients cannot be changed to be non-global, and vice versa.

5. Audit Trail

• All actions (create, edit, delete) on global OAuth clients should be logged with the acting superuser’s ID for audit purposes.

Acceptance Criteria

• The “Make client global” option is removed from all user/project credential forms.
• Only superusers can access the global OAuth client management section in the admin menu.
• Only superusers can create, edit, or delete global OAuth clients.
• Superusers can view all details (including scopes, client ID, client secret, etc.) of global OAuth clients.
• Global OAuth clients always have a user_id (the creator).
• Regular users cannot create or manage global OAuth clients, even by forging requests.
• Regular users can select global OAuth clients when creating a credential, but cannot see or manage them directly.
• All actions on global OAuth clients are audited with the acting superuser’s ID.
• Database and Ecto schema enforce that user_id is always required for all OAuth clients.

No files, tests, or entry points are named. Start by tracing the user/project credential forms, the admin/superuser menu, backend permission checks, and the Ecto schema/database constraints; done means the acceptance criteria are met, including audited global-client actions and enforced creator IDs.