Spike authentication between self-hosted instance and customers app

Overview

As part of self hosted paid signup, we'd like to build a user flow where a user of a self-hosted instance is able to checkout and become a paying customer from within their self-hosted instance without ever having to be redirected to the customers app.

On Gitlab.com, we've already built this functionality in our Gitlab.com paid signup flow. However, the solution we architected for Gitlab.com was made with the assumptions that Gitlab.com acts as a trusted and persistent instance which we control. When moving to a self-hosted instance, we'll need to re-architect a solution where we treat the instance as untrusted, non-persistant, and out of our control.

How Gitlab.com paid signup flow works

Customers App Data Model

customers table

uid (references Gitlab.com user_id)
access_token (references Gitlab.com oauth access token)
authentication_token (generated by customers app for customers app API access)

admins table

authentication_token (references Gitlab.com EE SUBSCRIPTION_PORTAL_ADMIN_TOKEN)

Steps

Environment variables are set on Gitlab.com SUBSCRIPTION_PORTAL_ADMIN_EMAIL and SUBSCRIPTION_PORTAL_ADMIN_TOKEN.
Environment variables are set on Customers app
On Customers app, an admin user is manually created using the Gitlab.com SUBSCRIPTION_PORTAL_ADMIN_EMAIL and SUBSCRIPTION_PORTAL_ADMIN_TOKEN. This is stored on the Customers app admin table as an authentication_token.
On Gitlab.com, a user signs up.
Once Gitlab.com receives this request, it calls the customers app API for Zuora iFrame parameters using the Gitlab.com SUBSCRIPTION_PORTAL_ADMIN_TOKEN. The customers app returns the requested parameters. Gitlab.com renders the Zuora iframe in the user's browser.
...