It doesn’t seem that HTTP API JWT authorization is...
# sst
b
It doesn’t seem that HTTP API JWT authorization isn’t supported for api routes at this time, or am I missing something? Any “easy” workaround?
f
I think it’d be quick for us to add support for it. Are you using Amazon Cognito as the issuer?
b
Yeah
f
I can put it in today or tomorrow. Would that work for you timeline wise?
b
Uh, wow, yes it would!
s
+1 for this feature. I'm using Cognito and JWT to protect an HTTP API endpoint. My service is currently running on Serverless Framework, but I'm trying it out with SST for comparison
b
Ya’ll need a link to a “Buy me Coffee” and tip/sponsor!
s
no rush on timeline, just adding my use-case!
f
Lol thanks guys!
s
🍻
f
I’m looking at the JWT doc on AWS Doc:
Copy code
aws apigatewayv2 create-authorizer \
    --name authorizer-name \
    --api-id api-id \
    --authorizer-type JWT \
    --identity-source '$request.header.Authorization' \
    --jwt-configuration Audience=audience,Issuer=<https://cognito-idp.us-east-2.amazonaws.com/userPoolID>
Do you guys know when using with Cognito are
identity-source
and
jwt-configuration
always the same format?
(apart from replacing
audience
and
userPoolId
)
b
(And region)
But yeah, that’s the format, I do believe it stays the same
f
Got it!
Btw, are you guys using Cognito Identity Pool at all with your User Pool?
b
I’m not, no
f
yup that makes sense
s
I am
Hoping to implement federated identities at some point, but not quite there yet.
f
When u have Identity Pool in place, you will switch from JWT to IAM for authorizing ur API, correct?
s
I honestly can't remember why I landed on this particular setup. The auth portion of my API was based on the serverless-stack demo. At some point, I started using HTTP APIs, which only supported JWT when it was first released. Now that it supports IAM, I suppose I could revisit my use of JWT
f
Ah that makes a lot of sense. Yeah, we usually recommend the IAM approach. But I do see JWT being often used, especially when migrating from an existing setup.
Just wanted to make sure I have a good understanding of you guys’ use cases.
s
Cognito was a real pain point. Once I got it working, I never really looked back. Now that HTTP APIs support IAM, I should revisit
f
Yup a REAL pain. We want to make sure the
sst.Api
and
sst.Auth
handle most the cases out of the box.
@Ben Kraus @Seth Geoghegan Quick update from my side, I should be able to wrap up the JWT support soon, and cut a release later today.
@Ben Kraus @Seth Geoghegan Here you go guys v0.9.8
To update:
Copy code
$ npm install --save --save-exact @serverless-stack/cli@0.9.8 @serverless-stack/resources@0.9.8
b
Awesome! Thanks a million! I owe you a beer!
f
Sounds good. I’m keep a note of it🤓
s
Awesome!
I've been investigating IAM as well, since I like pain and I figured Cognito was a good way to make sure I feel the most pain possible 😆
I realized what sent me down the JWT path after all. I was using Serverless Framework to build my REST API (apig v1). When I heard about HTTP API (apig v2), i was excited to give it a try. HTTP APIs only supported JWT at the time, so I went down that path in Serverless. When HTTP APIs introduced IAM authorization at the end of 2020, the Serverless Framework had not yet supported that feature (still only IAM), so I continued using JWT.
Side rant: someone needs to talk to AWS about their naming of REST API (apig v1) and HTTP APIs (apig v2) in API Gateway. Those are awful names, considering I can build a RESTful API using HTTP API or REST API in Api Gateway.