https://serverless-stack.com/ logo
Join Slack
Powered by
Hey guys, I’ve been running in to some issues with...
# help
b
Hey guys, I’ve been running in to some issues with using UserPools and API auth - I’m hoping someone here has some insight and can point me in the right direction on one of the two problems… So I’ve got an 
Api
construct that I’m trying hide behind an authorizer. Problem 1 I initially set up to use a UserPool authorizer, and all was well until I tried to use a JWT that I knew had expired - api returned with a 200 and everything processed as though the JWT was valid. I did some reacding around and fixing for about 8 hours and found out that Cognito doesn’t revoke access tokens unless a global sign out is triggered, obvious not what I want. I couldn’t find any settings in the AWS Console or in the CDK (or SST) docs that would help me with rejecting the request if the JWT was expired. Problem 2 So I started looking at using a Lambda authorizer instead, more work but at least I can guarantee it handles the token as I expect. I got a lambda in place, it’s being called and is kicking out a 
callback("Unauthorized");
response. The api, however, returns a 500 response instead of the 401. I’m at a complete loss on both of these approaches. Any thoughts/feelings?
r
Not sure about 1 but with 2 you need to return an IAM policy
b
From what I’ve read I should be invoking the supplied callback with “Unauthorized” as the sole argument when the auth fails?
c
We're using UserPools and 100% having expired tokens reject properly. I thought it was the API GW doing this but it must be some backend code, I'll have a look how we are doing it and let you know
Even get a helpful message:
Yeah we're not doing anything special in the backend that I can see (its written in go and I am terrible at go). I don't even think the request is reaching our lambda
Yeah I can confirm that API GW is dropping requests with an expired token in our setup:
Copy code
API-Gateway-Execution-Logs_fga9pxb11l/prod 50f4aa6af842e8cdd66992c877d5c19d (32738d7a-4c0a-49ad-85ab-c889a8ac3d4f) Extended Request Id: Hf0j-HVtvHcFjMw=
API-Gateway-Execution-Logs_fga9pxb11l/prod 50f4aa6af842e8cdd66992c877d5c19d (32738d7a-4c0a-49ad-85ab-c889a8ac3d4f) Starting authorizer: 1ikffo for request: 32738d7a-4c0a-49ad-85ab-c889a8ac3d4f
API-Gateway-Execution-Logs_fga9pxb11l/prod 50f4aa6af842e8cdd66992c877d5c19d (32738d7a-4c0a-49ad-85ab-c889a8ac3d4f) Unauthorized request: 32738d7a-4c0a-49ad-85ab-c889a8ac3d4f
r
Maybe moot if you get it working like Chad but from my experience a lambda authorizer must return an Allow or Deny IAM policy
b
@Chad (cysense) Hmm, ok. I’ll go back to the the UserPool stuff and see what’s up. Maybe I missed somehting in the SST config for the Api or Auth constructs… @Ross Coundon I would have thought so too but literally all documentation and examples I’ve found, whether by AWS teams or randoms on the internet, have all used the 
callback(string)
method for rejecting the request. A DENY policy might just be the way to get it working though.
r
I haven't used the callback mechanism before, I always use promises but you'd expect the result to be the same. For reference, here's an example of a Basic Auth lambda auth I wrote.
b
Fair play - it was annoying me that I couldn’t find an example using Promises that aligned with the callback way of dealing with it. Promises are definitely my preferred way of working, I’ll have a play. thanks for the help 🙂
r
No worries
(and line 33 should be)
Copy code
if (!authToken) {
    return Promise.resolve(generatePolicy('user', 'Deny', event.methodArn));
  }
b
Aaaaand... the user pool authorizer just started working... no changes made from my last attempt. thanks again guys.
f
@Ross Coundon @Chad (cysense) thanks a lot for helping up guys!
8 Views
Open in Slack
PreviousNext
Powered by