> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Third Party Application Access Policy

> Demo of GitHub third party application access policy showing how to create a GitHub App, set permissions, install into an organization, and admin workflow for approving pending installation requests

This guide demonstrates how GitHub’s third‑party application access policy affects installing a custom GitHub App and how organization administrators can review and approve installation requests. It walks through creating a GitHub App from a user account, configuring permissions, and the admin workflow for reviewing pending installation requests when an organization enforces a restrictive policy.

Prerequisites

* A GitHub user account (for this demo: `Dev2`).
* Organization admin privileges (to review/approve installation requests).
* A basic understanding of GitHub Apps and the permissions model.

## 1. Create a custom GitHub App (from the Dev2 account)

1. Sign in as the `Dev2` user.
2. In Dev2, open **Settings → Developer settings → GitHub Apps** and click **Create a new GitHub App**.
3. Enter the app’s basic details:
   * App name: for example, `demo-bot-dev`
   * Description: for example, “GitHub App test”
   * Homepage URL: your app’s website (for this demo we use `https://example.com`)

![A dark‑themed screenshot of the GitHub "Create GitHub App" page in Developer Settings, showing fields like "GitHub App name" filled with "demo-bot-dev" and a description box. The Homepage URL field contains "https://example.com" and sections for identifying/authorizing users and redirect URIs are visible.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-Third-Party-Application-Access-Policy/github-create-app-demo-bot-dev.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=cfe4707970c00804b991640bc7c54d82)

4. Configure identifying/authorization options required by your app. (In this demo we do not enable additional user identification settings.)
5. Disable webhooks if your app does not require them.
6. Set granular permissions according to the principle of least privilege. For example:
   * Actions: read & write (if the app needs to manage Actions runs)
   * Pull requests: read (if it only needs to view PRs)
   * Commit statuses: read & write (if it sets build/check statuses)

Be deliberate about permissions — only grant the minimum required for the app to function.

7. Select “Where can this GitHub App be installed?” according to distribution (for example, any account).
8. If your app does not use OAuth redirects, you can leave the Redirect URL fields empty.
9. Click **Create** to register the application.

After registration, the app settings page displays critical details such as App ID, Client ID, and links for installation and generating client secrets.

![A dark‑mode screenshot of the GitHub Developer Settings page for a GitHub App named "demo-bot-dev." The About section is visible, showing the App ID/Client ID, a public link, and options to revoke tokens or generate client secrets.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-Third-Party-Application-Access-Policy/github-app-demo-bot-dev-settings.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=8046e03d20ffb74ef68e70c138cba847)

## Quick reference — Example permission mapping

| Permission area | Typical use case | Example setting |
| - | - | - |
| Actions | Manage or inspect Actions runs | `Read & write` |
| Pull requests | View PR details | `Read` |
| Commit statuses | Set CI/build checks | `Read & write` |

## 2. Installing the app into an organization

To install the app in an organization, use the public installation link or the **Install App** button from the app settings page. During installation you choose:

* The target account (your organization)
* Which repositories to grant access to (e.g., select only the `App Backend` repository)

If the organization enforces a restrictive third‑party application policy, installations initiated by non-admin members may not be applied immediately. Instead, GitHub will generate a pending installation request that requires organization administrator approval.

When an organization’s third‑party application access policy is set to **Access restricted**, member-initiated app installations become pending requests. An organization admin must review and approve those requests before the app gains access to organization repositories.

## 3. How organization admins review pending installation requests

An organization administrator can review and manage installation requests as follows:

1. Go to the organization’s **Settings**.
2. Scroll to **OAuth apps / Third‑party application access policy** to confirm the organization’s current policy and view any already approved applications.

![A screenshot of the GitHub organization "game-devstudio" Settings page showing the "Third-party application access policy" set to "Access restricted." The page lists an approved "OKTA SCIM Integration" application.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-Third-Party-Application-Access-Policy/game-devstudio-access-restricted-okta-scim.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=2592e73ac02e19331b7c18023293de8e)

3. Open **Installed GitHub Apps** (GitHub Applications) to see pending installation requests.
4. Inspect each pending request to review:
   * The app identity and App ID
   * The permission scopes requested
   * Which repositories the requesting user wants to grant access to

Pending requests are visible in the Installed GitHub Apps area so admins can make an informed decision.

![Screenshot of the GitHub organization "game-devstudio" settings page in dark mode. The Installed GitHub Apps section shows Imgbot installed and a pending "demo-bot-dev" installation request, with the settings sidebar visible on the left.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-Third-Party-Application-Access-Policy/github-game-devstudio-imgbot-demo-pending.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=8b45c15110d4423231d06e7d4b9a51c1)

5. Approve the request to allow the app to be installed on the selected repositories, or reject/cancel if the app should not have access.

Changing the organization’s third‑party application access policy to be less restrictive (e.g., allowing installations without admin approval) reduces friction but increases exposure to unvetted apps. Follow the principle of least privilege and document the rationale for any policy changes.

## Best practices and next steps

* Review requested permissions carefully and limit repository access to only those repos the app needs.
* Maintain an allowlist of approved apps and periodically audit installed GitHub Apps.
* For automation or integrations that need broad access, consider using a service account with limited scope and rotate credentials regularly.

Useful links

* [GitHub Apps documentation](https://docs.github.com/en/apps)
* [Third-party application access policy overview](https://docs.github.com/en/organizations/managing-access-to-your-organizations-resources/managing-third-party-access-to-your-organization)

This workflow ensures organizations retain control over which third‑party applications can access organization resources while allowing developers to use approved integrations.

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/d477d0b2-5ca0-43b2-aed7-7d82887400f7/lesson/326db53c-21ef-4a1a-bdfd-e4a0ade99fe9)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.