Hey everyone! I am using AWS Api Gateway and I wou...
# support-questions-legacy
j
Hey everyone! I am using AWS Api Gateway and I would like to use the authorizer function described here: https://supertokens.com/docs/thirdpartyemailpassword/serverless/with-aws-lambda/authorizer I do not want to hit my Supertokens server with every request though. Therefore I was wondering what endpoint does
await Session.getSession()
hit and is it possible to cache that response with AWS Cloudfront that sits in front of my Supertokens server?
r
Hey @jonasalexanderson
The getSession function is stateless.
So the verification is super fast anyway
j
But is has to hit my Supertokens server to request encrytion keys somehow
I want to deploy my server only in one AWS region and have the keys distribute with Cloudfront to their edge locations
r
Oh right. Yea. That happens every time the serverless function starts. Once. So if the authoriser is kept “hot” it won’t make requests again and again.
j
What do you mean by "once"? I expect that the keys are rotated eventually, right?
r
Yes. I think once every 24 hours. So when the keys are rotated, the getSession queries once again. But relatively speaking, this is a rare operation
So 99% of the getSession won’t make a network call anyway as long as the authoriser is kept hot. Which I think AWS does on its own.
j
I do not know about that. If you have a cold lambda function that has to make a trip around the world to get keys, you do have some noticable delay in response times
I looked at the supertokens-node repo. The getSession function eventually makes a call to
/recipce/handshake
. Is it safe to tell Cloudfront to cache that response or does its response depend on the payload that was send to it?
r
You shouldn’t cache that response
If you want to take control of the keys, I suggest that you switch to using the JWT based auth. In that, you can even hard code the public keys in the lambda itself. But then you won’t have key rotation.
j
Thank you. I could implement Method 1 (https://supertokens.com/docs/session/common-customizations/sessions/with-jwt/jwt-verification), because the jwks.json end point it a GET end point and looks like I could cache it
r
Yea. You could. The downside here is that you don’t have key rotation. So slightly less secure.
But we are working on a change where we will provide key rotation for JWT based auth as well. Coming sometime next month.
j
That is awesome. How would that work? Would you add another item to the
keys
array and start signing all new tokens with the new key and remove older keys from the array eventually?
r
Yes
j
👍
Thank you for your help. I know what to do now
c
Hey @jonasalexanderson , did you get this working with a jwt authorizer? I tried going this route and am now getting CORS issues from the OPTIONS calls to my auth endpoints, and have a feeling it might be due to my API Gateway setup somehow so wondering if you figured it out?
j
Hey @cbwhite920 , I did not implement it yet. What endpoint throws CORS errors for you?
c
Oh ok no worries, I found out it was because with an Http Api Gateway if you set up CORS settings on the gateway it overwrites the CORS headers so that was causing trouble
Found out the solution is to not set up anything for CORS on the gateway, allow the lambda itself to handle CORS headers explicitly, then also expose the OPTIONS method on your endpoint explicitly and I had to use a Lamba integration for that which basically just returns success
Then from the frontend I had to extract the jwt from the access token payload and set that in my Authorization header for my jwt authorizer to pass, and then my GET call to my api endpoint was getting hit
But, now I’m running into an issue where the lambda behind that GET call returns successfully with expected data, but the gateway is giving back a 500 server error with no additional info to troubleshoot with, so think I’m going to have to go back and try the Rest Api Gateway approach
sorry for the book lol. To answer your actual question though, the session refresh endpoint was throwing CORS errors, but it was because at first the Authorization header wasn't coming through, then it was because I was passing the supertokens access token payload and not the contained jwt