Using `permission-*` option with `actions/create-github-app-token` does not restrict token permissions

[waqaskayani]

I'm using the actions/create-github-app-token action and trying to leverage the permission-<permission name> inputs as defined here to request a token with a reduced set of permissions compared to what the App installation has been granted.

Expected Behavior:

Based on the action's documentation and the standard behavior of the GitHub API (POST /app/installations/{installation_id}/access_tokens), providing specific permission-* inputs should result in an installation access token that has permissions limited to the intersection of the requested permissions and the permissions granted to the App installation.

Actual Behavior:

Even when specifying a subset of permissions using permission-* inputs, the generated token appears to retain all the permissions originally granted to the App installation. It does not seem to be restricted to the subset requested in the workflow.

Steps to Reproduce:

1. Configure a GitHub App with the following permissions granted to its installation:
   • contents: write
   • pull-requests: write
2. Use the actions/create-github-app-token action in a workflow, requesting only read permissions for pull-requests and contents:

name: Test App Token Permissions

on: [push]

jobs:
  test-token:
    runs-on: ubuntu-latest
    steps:
      - name: Generate restricted token
        id: generate-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}
          permission-contents: read
          permission-pull-requests: read

      - name: Create Pull Request
        # This step should ideally fail if permissions were restricted correctly
        uses: peter-evans/create-pull-request@v7
        with:
          token: ${{ steps.generate-token.outputs.token }}

3. Observe that operations requiring permissions not explicitly requested in the workflow step (i.e. pull-requests: write) still succeed when using the generated token. In my specific case, I was able to create Pull Requests using the token generated with only checks: read and contents: read requested.

Is this the intended behavior, or is there potentially an issue with how the permission-* inputs are processed and passed to the GitHub API? According to the documentation, I would expect the token's permissions to be strictly limited to those requested via the inputs.

[gr2m]

See also #236. Something is not right. I have my check in with @parkerbxyz tomorrow, we'll look into it to see what is happening.

The first step would be to verify that the REST API endpoint to create an installation access tokens works as expected:
https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app

Optionally, use the permissions body parameter to specify the permissions that the installation access token should have. If permissions is not specified, the installation access token will have all of the permissions that were granted to the app. The installation access token cannot be granted permissions that the app was not granted.

It's unlikely, but it's possible that the API itself doesn't work as advertised.

If we confirm that it works, we will look into verifying that our request sent to that endpoint is correct.

These are the two possible causes I can think of right now.

[waqaskayani]

Thank you @gr2m for the quick response.

I've had a chance today to verify the behavior by interacting directly with GitHub API using curl, and can confirm that it does correctly restrict the permissions of the generated installation access token according to the permissions body parameter provided in the request.

In my case, the token created with pull-requests: read and contents: read permissions, when used to create pull requests in a subsequent step, fails with a 403 access denied.

Steps to reproduce:

1. Define your app ID, installation ID, and private key path for the GitHub app:

app_id=<APP_ID>
installation_id=<INSTALLATION_ID>
key_path="secret.pem"

2. Use python script provided in documentation to get the JWT token:

jwt_token=$(python3 get_jwt.py $key_path $app_id | sed 's/^JWT: //')

3. Get the installation access token following docs, specifically with pull_requests: read and contents: read permissions:

iat=$(curl -sL \
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $jwt_token" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/app/installations/$installation_id/access_tokens \
  -d '{"repositories":["REPOSITORY"],"permissions":{"pull_requests":"read","contents":"read"}}' | jq -r '.token')

4. Attempt to create pull request with Read-Only token:

curl -L \  
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $iat" \                                    
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/OWNER/REPOSITORY/pulls \
  -d '{"title":"Amazing new feature","body":"Please pull these awesome changes in!","head":"some-test-ref","base":"test-base"}'
{
  "message": "Resource not accessible by integration",
  "documentation_url": "https://docs.github.com/rest/pulls/pulls#create-a-pull-request",
  "status": "403"
}

The API returns a 403 error, as expected for insufficient permissions. This confirms that the installation access token generated with a narrower scope ('read'), despite the GitHub app having 'write' access, is correctly restricted, indicating the core GitHub API functionality works as expected here.

[gr2m]

Fix is in v2.0.4