GitHub App

[moop-moop]

Name of app / service GitHub App

Link to developer documentation

• https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#github-app-installation-access-tokens
• https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation#about-authentication-as-a-github-app-installation
• https://github.com/peter-murray/workflow-application-token-action

Here is how we do something similar with bash:

#!/bin/bash

# requires `jq`

set -o pipefail

re='^[0-9]+$'
if ! [[ $1 =~ $re ]] ; then
   echo "error: App installation ID needs to be a number" >&2; exit 1
fi

installation_id=$1

# Change these variables:
app_id=1
app_private_key="
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
"
api_base="https:///api.github.com/api/v3"

# Shared content to use as template
header='{
    "alg": "RS256",
    "typ": "JWT"
}'
payload_template='{}'

build_payload() {
        jq -c \
                --arg iat_str "$(date +%s)" \
                --arg app_id "${app_id}" \
        '
        ($iat_str | tonumber) as $iat
        | .iat = $iat
        | .exp = ($iat + 300)
        | .iss = ($app_id | tonumber)
        ' <<< "${payload_template}" | tr -d '\n'
}

b64enc() { openssl enc -base64 -A | tr '+/' '-_' | tr -d '='; }
json() { jq -c . | LC_CTYPE=C tr -d '\n'; }
rs256_sign() { openssl dgst -binary -sha256 -sign <(printf '%s\n' "$1"); }

sign() {
    local algo payload sig
    algo=${1:-RS256}; algo=${algo^^}
    payload=$(build_payload) || return
    signed_content="$(json <<<"$header" | b64enc).$(json <<<"$payload" | b64enc)"
    sig=$(printf %s "$signed_content" | rs256_sign "$app_private_key" | b64enc)
    printf '%s.%s\n' "${signed_content}" "${sig}"
}

github_api_url="${api_base}/app/installations/${installation_id}/access_tokens"
curl -s -X POST \
    -H "Authorization: Bearer $(sign)" \
    -H "Accept: application/vnd.github.v3+json" \
    "${github_api_url}" \
    | jq -cr .token

Is lack of support preventing you from building workflows, or do you have a workaround? There are less ideal work-arounds. Authentication as a GitHub application would allow better security for organization level security. It is easier to maintain than personal account connections or machine accounts. We use this approach in our GitHub Actions. Someone even created a nice GitHub action for it specifically. See third link above: peter-murray/workflow-application-token-action

Are there specific actions, or triggers, you'd like to see for this app? Please let us know here or use the Action and Trigger issue templates to open requests for each! Nearly all GitHub actions should work with GitHub App authentication, if the correct permissions are assigned to the GitHub App. It's a little more complicated to set up overall, but independent of any individual accounts.

[sergio-eliot-rodriguez]

Hi @moop-moop

Thanks for your request. Just double checking, as per this comment:

Nearly all GitHub actions should work with GitHub App authentication, if the correct permissions are assigned to the GitHub App.

you are saying the current GitHub app is not ideal to your case right? This is the current Pipedream app for GitHub> https://pipedream.com/apps/github

I-d appreciate your confirmation, just to see if I understand properly the request.

[moop-moop]

Hi @moop-moop

Thanks for your request. Just double checking, as per this comment:

you are saying the current GitHub app is not ideal to your case right? This is the current Pipedream app for GitHub> https://pipedream.com/apps/github

I-d appreciate your confirmation, just to see if I understand properly the request.

Yes. I want to authorize pipedream through my simple custom GitHub app. Using Pipedream's GitHub App still requires my account:

[moop-moop]

Using a simple custom GitHub App with defined permissions and repository access would not require an account.

[sergio-eliot-rodriguez]

noted. thanks for input! we'll keep you posted

[dannyroosevelt]

@moop-moop to confirm, you'd expect to input your app's access token as the means of authorizing, is that correct?

Would using your own GitHub OAuth client be an acceptable solution as well, or does a GitHub app specifically better suit your needs?

[moop-moop]

I was thinking more of the this: Authenticating as a GitHub App installation https://docs.github.com/en/enterprise-cloud@latest/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation

So the inputs would be:

• application id
• application's private key
• webhook secret (optional)

This approach is arguably better for organizational level system to system interactions. https://docs.github.com/en/enterprise-cloud@latest/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps

Using our own Github OAuth client would still essentially use the persmissions of a user.

[sergio-eliot-rodriguez]

Nathan -

That's a very strategically put approach to the authentication, so to speak.

One question, regarding GitHub App, do you see possible being able to invoke the GitHub workflow to get the access token externally from a Pipedream workflow?

Curious to read your answer, honestly, I'm not very familiar with GitHub workflows part.

[moop-moop]

I don't think it requires the use of any GitHub Workflow. It could should be all native to Pipedream. My original post just included examples of how to implement an approach:

1. GitHub Action that does (very thoroughly) what I am suggesting Pipedream could do (using )
2. Bash script to do the same.

And also the GitHub documentation includes examples using Ocktokit JS library: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation#using-octokitjs-to-authenticate-with-an-installation-id

[moop-moop]

I would glady implement it myself, I just don't have time right now. So I made a suggestion for enhancement.

[sergio-eliot-rodriguez]

It could should be all native to Pipedream.

I agree. Just checking possibilities. Thanks for clarifying!