LGTM, thanks again @sijintv !

What does this MR do and why?

This Merge Request adds the User Applications REST API, fulfilling the requirements described in #23054.

It introduces a set of CRUD endpoints located at /api/v4/user/applications that allow users to manage their instance-level OAuth applications. This is designed to enable programmatic management of user-owned OAuth applications, which proves extremely useful for dynamically deploying and un-deploying Review Apps without having to employ insecure wildcard redirect URIs.

Specifically, it creates the following endpoints:

1. POST /api/v4/user/applications: Creates an application, exclusively returning the secret during this action.
2. GET /api/v4/user/applications: Lists all applications owned by the authenticated user.
3. GET /api/v4/user/applications/:id: Retrieves a specific application.
4. PUT /api/v4/user/applications/:id: Updates an existing application (e.g. modifying the redirect_uri).
5. DELETE /api/v4/user/applications/:id: Removes the application.

Security Considerations

The implementation follows strict security best practices regarding credential exposure and bounded context:

• Secret Exclusivity: In accordance with OAuth 2.0 best practices, the application secret is explicitly and exclusively returned only on the POST create event. Subsequent GET or PUT requests will never expose the secret.
• Targeting Wildcards: The primary motivation for this API is to give developers a programmatic way to provision dynamic redirect_uri targets (such as ephemeral Review Apps). This eliminates the insecure practice of users resorting to wildcard redirect URIs to handle dynamic domains.
• Authorization Enforcement: The endpoint exclusively operates within the strict boundary of the current_user. The Authn::UserApplicationsFinder inherently scopes all GET, PUT, and DELETE requests to only OAuth Applications owned by the authenticated user, completely preventing Insecure Direct Object Reference (IDOR) or cross-user data leakage.
• Confidentiality Awareness: The endpoints explicitly support defining whether an OAuth application is confidential or public (e.g. for SPAs or Native apps), ensuring the system handles the client appropriately during the OAuth flow.

Database Queries

The User Applications API executes standard CRUD operations on the oauth_applications table, scoped to the current user. Here are the query execution plans:

1. Read (Finder)

EXPLAIN SELECT "oauth_applications".* FROM "oauth_applications" WHERE "oauth_applications"."owner_id" = 1 AND "oauth_applications"."owner_type" = 'User' AND "oauth_applications"."id" = 1 LIMIT 1;

 Limit  (cost=0.15..2.17 rows=1 width=237)
   ->  Index Scan using index_oauth_applications_on_owner_id_and_owner_type on oauth_applications  (cost=0.15..2.17 rows=1 width=237)
         Index Cond: ((owner_id = 1) AND ((owner_type)::text = 'User'::text))
         Filter: (id = 1)

2. Create (POST)

EXPLAIN INSERT INTO "oauth_applications" ("name", "uid", "secret", "redirect_uri", "scopes", "created_at", "updated_at", "owner_id", "owner_type", "confidential") VALUES ('test', 'uid', 'secret', 'url', 'api', NOW(), NOW(), 1, 'User', true) RETURNING "id";

 Insert on oauth_applications  (cost=0.00..0.02 rows=1 width=237)
   ->  Result  (cost=0.00..0.02 rows=1 width=237)

3. Update (PUT)

EXPLAIN UPDATE "oauth_applications" SET "name" = 'test2', "updated_at" = NOW() WHERE "oauth_applications"."id" = 1;

 Update on oauth_applications  (cost=0.15..2.17 rows=0 width=0)
   ->  Index Scan using oauth_applications_pkey on oauth_applications  (cost=0.15..2.17 rows=1 width=46)
         Index Cond: (id = 1)

4. Delete (DELETE)

EXPLAIN DELETE FROM "oauth_applications" WHERE "oauth_applications"."id" = 1;

 Delete on oauth_applications  (cost=0.15..2.17 rows=0 width=0)
   ->  Index Scan using oauth_applications_pkey on oauth_applications  (cost=0.15..2.17 rows=1 width=6)
         Index Cond: (id = 1)

References

• Resolves #23054

Screenshots or screen recordings

The API returns standard GitLab API JSON shapes, and correctly provisions the underlying Authn::OauthApplication record associated with the user.

Browser Dev Tools Verification

How to set up and validate locally

1. Ensure your GDK is up and running.

2. Open your browser developer console while authenticated as any user (e.g. root) on the GitLab dashboard.

3. Execute the following fetch command to provision an application:

   const csrf = document.querySelector('meta[name="csrf-token"]').content;
   fetch('/api/v4/user/applications', {
     method: 'POST',
     headers: {
       'Content-Type': 'application/json',
       'X-CSRF-Token': csrf
     },
     body: JSON.stringify({
       name: 'Browser UI Test App',
       redirect_uri: 'http://localhost/callback',
       scopes: 'api',
       confidential: false
     })
   }).then(r => r.json()).then(console.log);

4. Verify that the response returns a success with the secret and an application_id.

5. You can assert the creation of the Application by checking your /-/profile/applications interface.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Isaac Durham (6caec9a9) at 17 Mar 19:50

@z_painter , good to go!

@adil.farrukh , sorry for all the back and forth. I took another approach, and just linked to the deprecations page which will keep the original content. Does that work for you?

@eread, can you give this a look?

@axil, can you give this a look?

@phillipwells, can you give this a look?

Isaac Durham (2d9a7a5a) at 17 Mar 18:41

Isaac Durham (7ef064df) at 17 Mar 18:40

Isaac Durham (697aaa95) at 17 Mar 18:40

This one seems better with the all as we want to be explicit with something like this.

This seems to have gotten a little stale. Moving work over to Standardize API operation names (!220443 - closed)

What does this MR do?

Standardizes API operation names in search_admin and secure_files documentation to follow the RESTful API Style Guide.

Related issues

#585399

Changes

doc/api/search_admin.md

• Get an advanced search migration → Retrieve an advanced search migration

doc/api/secure_files.md

• Show secure file details → Retrieve secure file details
• Create secure file → Create a secure file
• Remove secure file → Delete a secure file

Broken link fixes

• Updated fragment link in doc/ci/secure_files/_index.md from #show-secure-file-details to #retrieve-secure-file-details

What does this MR do?

Standardizes the titles and introductions of several API documentation pages. This closes off work from the previous hackathon.

Related issues

#585399

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

What does this MR do?

Standardizes the titles and introductions of several API documentation pages. This closes off work from the previous hackathon.

Related issues

#585399

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

What does this MR do?

Standardizes the titles and introductions of several API documentation pages. This closes off work from the previous hackathon.

Related issues

#585399

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Isaac Durham (fd0f039c) at 17 Mar 18:29

... and 2 more commits

Isaac Durham (8193307c) at 17 Mar 18:28

... and 2 more commits

Isaac Durham (b6cb96d8) at 17 Mar 18:27

... and 1 more commit