Hello all. In my stack definition, I use HttpUserPoolAuthorizer by default and that works fine on all protected routes. On one of those routes instead of receiving the token as usual via the request Headers I need to receive the token as part of the GET parameters in the url (in the form http://my_url?auth_token=xxx). Is there any way to do that with SST/gateway API ?

You would set identitySource to be

$request.querystring.auth_token

see: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html#http-api-lambda-authorizer.identity-sources

@Erik Robertson i think you’d need to create a new authorizer for this route with the identity source suggested by Garret.

Thanks. I understand what we want out of API Gateway. For this to happen, is it within the route definition that I can do authorizationType : new HttpLambdaAuthorizer(...) ?

You might want to keep the

authorizationType

the same ie.

ApiAuthorizationType.JWT

and use different authorizers

Not too sure of your usecase @Erik Robertson or application, but just in case you haven't thought about it, putting auth material in the URL is bad security practices. Specifically, the auth material will be logged in web logs, browser histories and referrer header (so any analytics systems you use could also have access to the auth token). Probably, the most disruptive (and again I don't know your application but just sharing this as an FYI), if you in the future have a penetration test or security assessment of your application, this will be raised as a high issue and could lead to refactoring and business delays. If interested you can read more here: https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url But if this is not a business critical app and I should just mind my own business, then I apologies 😛

Thanks for all your replies. Yes Chad I'm aware of that risk indeed but this route is a callback I pass onto a 3rd party component that doesn't include any security options. I'll have to see if I can take a better overall approach down the road. @Frank your suggestion totally makes sense. I however run into an error when implementing it :

There is already a Construct with name 'UserPoolAuthorizer' in HttpApi [Api]

Here is my code excerpt :

const tokenInUrlAuthorizer = new HttpUserPoolAuthorizer({
      userPool: userPool,
      userPoolClient: userPoolClient,
      identitySource: ['$request.querystring.atk'],
    })

    const defaultAuthorizer = new HttpUserPoolAuthorizer({
      userPool: userPool,
      userPoolClient: userPoolClient,
    })

    const api = new sst.Api(this, "Api", {
      defaultAuthorizationType: sst.ApiAuthorizationType.JWT,
      defaultAuthorizer: defaultAuthorizer,
      routes: {
        "GET /fetch_csv": { function: "src/fetch_csv.main", authorizer: tokenInUrlAuthorizer },
        "GET /private": "src/private.main",
...

Can you try passing in

authorizerName

?

UserPoolAuthorizer

is the default name.

That worked ! Thanks @Frank