The only workaround I’m aware of is to use a cljs lambda (fast cold starts) to proxy the http-direct request. It can merge the data from the “requestContext” into the main request body which is seen by the Ion. Is this what you mean by the workaround?
This approach would log all the information you are proxying. I am not sure you want that.
In the custom case, we don’t really have much input to provide until amazon calls the ion. However, if I understand you correctly-- in both cases (cognito user pool case and custom lambda case), you don’t have the information you need to correlate to the user on the backend. An approach that I have seen to do this-- you can specify a custom HTTP header to include the JWT (in the api-gateway config). You then can pull the JWT from the HTTP header and you can split the JWT (which has n concatenated chunks that are base64 encoded) on a period .. Then you base64 decode each result looking for whatever information you are seeking. In this user’s experience they found they could count on the information you are seeking being in whatever (nth) chunk you find it in --every time.
Regardless if its a custom lambda or cognito authorizer, if you use your own Header the JWT contains all the information you are after.
I believe when you supply the Cognito identity token (not the access token --specific to the Cognito client side SDK/Amplify Cognito SDK), that the identity token is a JWT and can be decoded. Similarly, you can also supply that as an HTTP header.