If you're ok with open-sourcing your repo (scroll further down in this answer if not), you can do this without needing to authenticate if you make a workflow that creates a release upon each commit, then builds your artifact, then uploads that artifact to the release. The trick is to be clever with your release tag's name, which is used in the release URL. A sample workflow is described here. I've modified this slightly to match your sample repo's scenario, and I instead use the first 8 characters of the commit hash in the tag name to generate a predictable but unique URL:

on:
  push:
    # Runs on every pushed commit

name: Upload Release Asset

jobs:
  build:
    name: Upload Release Asset
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

        # For the sake of simplicity, we'll name the tag and the release with
        # the first 8 chars of the commit SHA:
      - name: Get short SHA
        id: short_sha
        run: echo "::set-output name=sha8::$(echo ${GITHUB_SHA} | cut -c1-8)"

      - name: Build project # This would actually build your project, using zip for your example date artifact
        run:  |
          date > date.txt
          zip -rT app.zip date.txt
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          # Using short SHA from 2nd step for tag and release name.
          tag_name: ${{steps.short_sha.outputs.sha8}}
          release_name: ${{steps.short_sha.outputs.sha8}}
          draft: false
          prerelease: false
        # Now we upload the artifact we generated in the first step to
        # the release we created in the 3nd step
      - name: Upload Release Asset
        id: upload-release-asset 
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }} # This pulls from the CREATE RELEASE step above, referencing its ID to get its outputs object, which include a `upload_url`. See this blog post for more info: https://jasonet.co/posts/new-features-of-github-actions/#passing-data-to-future-steps 
          asset_path: ./app.zip
          asset_name: app.zip
          asset_content_type: application/zip

Then, finally, your asset will be available at a URL with the pattern: github.com/orgname/reponame/releases/download/${short_sha}/app.zip, where short_sha is the first 8 characters of your commit. Since it has this known format, it's easy to generate the URL on the in-house user's side if they have access to the repository (pull from repo, get SHA at head, do some string interpolation, print URL to console).

Test repo workflow

Test release asset

In case your repo must stay private within your org:

Someone wrote up a nice Gist with some shell scripts to grab a release from a private repo - you'll need an access token.

If you don't want to pollute the releases of your repo:

You could modify the above workflow's tag_name and release_name to include an intermediate prefix so it's clear that it's not an actual release. Your URL format will be different if you take this route, though - the bit after /download/ will be your new tag name.