The workflow_run approach is certainly interesting, and may actually help a lot, thank you! (though I’d still advocate for a little more formalized approach like I outlined)

Using GITHUB_TOKEN had occurred to me, but I was hesitant to send a secret like that in a request body or header, outside the system it’s meant to be encapsulated by. If there’s an argument for this being ok, we actually already have places in accepting the upload that attempts verification for systems that allow for it that such an operation could be slotted into

(though I’d still advocate for a little more formalized approach like I outlined)

I agree! Hopefully, someone from GitHub sees this but their Roadmap is very full so it’s probably worth moving forward with a workaround if you need to deliver this in the next few quarters.

…I was hesitant to send a secret like that in a request body or header, outside the system it’s meant to be encapsulated by. If there’s an argument for this being ok…

I think there are arguments in favour and arguments against. The key argument against this is that these tokens are not designed to be used externally and a security audit from an especially cautious customer might flag it as a concern, “why is this Action exfiltrating our tokens?”.

Personally, though, I think there is a strong justification for using these tokens externally if done so with security in mind. The tokens are described as a way to “authenticate on behalf of GitHub Actions” which is the intent of your implementation. The permissions configuration for these tokens enables a Workflow administrator (i.e: your customer) to confidently restrict the scope of the token down to the same level that a GitHub App has by default.

jobs:
  do-app-task:
    runs-on: ubuntu-latest
    permissions:
      metadata: read
    steps:
      - uses: app/action@v1
        with:
          token: ${{ github.token }}

From the GitHub Apps Permissions documentation (emphasis mine):

The metadata permission provides access to a collection of read-only endpoints with metadata for various resources. These endpoints do not leak sensitive private repository information.

My conclusion is that it’s justifiable, the key points that lead me to that conclusion:

1. The tokens immediately expire at the end of a Workflow Run, this is behaviour controlled by GitHub and so a customer is not dependent on you to be a responsible custodian of the tokens
2. GitHub are very conscious of the threat that these tokens present, so much so there is security research published about secure use of these tokens and this approach does not contradict any of that advice
3. The token permissions can be restricted by the Workflow administrator to provide the same level of permissions that a GitHub App has already
4. The metadata endpoints available are explicitly described by GitHub as not leaking sensitive data – something that should give users confidence

That is a very comprehensive analysis, thank you! based on what you’d provided, I’m leaning towards using the token, at least as a first iteration to improve upon the current situation.

You definitely don’t want to use the GITHUB_TOKEN like this it isn’t secure. There are lots of reasons, but the base of it is, anyone in all of github can create a token that may have the same attributes as the GITHUB_TOKEN and therefor indistiguishable.

It isn’t official yet, but it may be the case you can generate a JWT using this action

curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL" | jq -r '.value' > $AWS_WEB_IDENTITY_TOKEN_FILE

And from there pass the JWT to your app to verify it. If the token doesn’t have what you need you can configure it further using third party services such as Vault or Authress.