Auth at the edge for API with Compute@Edge

We want to cache requests that vary based on the user’s subscription status. 

Here’s the flow we are currently experimenting with: 

• The user makes a request. The request includes an Authorization header with an opaque token.
• Fastly parks the original request and makes a preflight request to "/api/auth/fastly_edge_auth_user_info". The preflight request includes an Authorization header copied from the original request.
• A response to the preflight response includes the user’s subscription status. Example: { id: 1, subscriber: true }.
• Fastly clones the original request and modifies the clone by removing the original Authorization header and by adding edge auth header x-edge-auth-subscriber with the value derived from the preflight response.
• Fastly sends the original request to the backend.
• The backend sends a response to Fastly. The backend uses `x-edge-auth-subscriber` to detect whether it should include content that is available only for subscribers. The response includes the header `Vary: x-auth-subscriber`, so Fastly can create two cache variations: one for subscribers and another one for non-subscribers.
• Fastly cleans Vary headers and sends the response back to the user.

A few notes:

• We’d like to use Compute@Edge with Javascript, however, we can use another runtime if needed.
• We would like to cache preflight requests to `/api/auth/fastly_edge_auth_user_info` on Fastly. While it’s basically a per-user cache, it still can be effective because our application makes tens of requests per relatively short session. Cache invalidation happens by a surrogate key via Fastly API when users purchase subscriptions.
• We currently have a VCL-based solution with JWT tokens, but the JWT-based solution does not allow us to deliver subscription-only content immediately after the purchase of the subscription. 
• The traffic to origins comes only from Fastly, thus the backend can trust to the edge auth. 

Questions:

• Any concerns about this approach in general?
• Any potential issues with caching the preflight auth request to "/api/auth/fastly_edge_auth_user_info"? What will be the best "Cache-Control" header in this case? (Cache only on Fastly and the content is private).

We currently set header `Cache-Control: max-age=0, public, s-maxage=3600`. It would feel better to set `private` instead of `public`, but with `private` Fastly seems does not cache the response. 

If the public directive is the only option, then we can completely hide the endpoint "/api/auth/fastly_edge_auth_user_info" from the outside and keep it open only for communication between Fastly and our backends.

Any advise and options are welcome, thank you!