I'm still trying to get my head around the different types of auth in a SST context having only used basic features of Cognito in the past. I'm curious to know how people are arranging their API stacks when they want to offer different roles/permissions. Say I wanted to restrict a POST endpoint to admin users but allow less privileged (but still authenticated) users access to the GET endpoint. Is this even possible with Cognito? Would that be a different authoriser on the API route?

my opinion here is subjective but imo cognito is just going to continue to give you hell when trying to do things like this

Hmm, thanks for your honesty. You'll probably see from my other help requests that I've been playing with Auth0 both federated and JWT. I'm not too keen on Auth0 either, for a few different reasons. You put in another thread about UserFront which I'm also looking at. How does that work with the API Gateway HttpJwtAuthorizer? And the same question applies, how with SST can I apply different permissions to different endpoints?

I also feel that the api gateway authorizers provide little benefit. They add another step of latency when you can just do a check in your function code

This is really useful, thank you. Basically you're saying that API level would just be authentication and then within the functions check for authorisation. Let me know when you make that library available 😄

yep! yeah we're definitely going to put some time into refining this pattern and release it

So, back to UserFront.... Can you point me in the direction of how I can use this for API authentication?

I would just follow their guide and import the libraries into my function, skip cognito all together

How would I setup the API stack in this case though. This is what I've done (following the examples) for Auth0.

const api = new Api(stack, 'Api', {
      authorizers: {
         jwt: {
            type: 'jwt',
            cdk: {
               authorizer: new apigAuthorizers.HttpJwtAuthorizer('Authorizer', '<https://dev-8rchfy1d.us.auth0.com/>', {
                  jwtAudience: ['<https://aw6lgqy70i.execute-api.us-east-1.amazonaws.com>'],
               }),
            },
         },
      },
      defaults: {
         authorizer: 'jwt',
      },
      routes: {
         'GET /private': 'functions/private.handler',
         'GET /public': {
            function: 'functions/public.handler',
            authorizer: 'none',
         },
      },
   });

I'm not familiar enough with CDK to know what needs to be done here.

You wouldn't do anything in CDK, you'd just drop the authorizers section and do the check in your function

Ahh, I get you. So in terms of the SST stack everything would be public.

yeah exactly

Thanks for your help. I'll let you get back to some actual work now 😆

this is my actual work!

@thdxr While I also see the benefit of your approach, there is 1 potential concern of having all API routes public. I've seen a lot of scans happening in some cases in the past and using throttling is probably a good protection to consider, especially when everything is open. In the past I used my own custom authorizer function (which which retrieving allowed things from a role access db + linked these directly to the issued access token). Then I'd check the token permissions again for each of the critical actions (which would not only verify the use of the route, but also permissions of the object being operated on). It seems a bit similar to your context levels though.

yeah that makes sense, dealing with API limits is an issue

Just to join the party… I’ve tried using custom authorizer for APIs, and like @thdxr suggested, I ended up make deeper calls, and have route specific permission logic, ie.

// authorizer.ts
if (route.path.startsWith("/user/id/")) {
  assertFriendPermission(userId, friendId);
}
else if (route.path.startsWith("/public")) {
  // always grant permission
}
else {
  assertUserPermission(userId);
}

I've been thinking about this approach overnight and I'm curious as to how this affects performance and billing. My understanding isn't great in this area but is there not a situation where API gateway is used and a Lambda invoked just to get to a point to say that the caller isn't authenticated? Is there a hybrid approach where the frontend app (not the user) is authenticated at the API level before it goes any further. This would restrict any unwanted traffic on the API.

Yeah if you don't use a custom authorizer than it's entirely managed so there's no lambda to invoke. But if you do need custom logic it gets invoked on every request. ApiG does have a seperate throttling config if you're worried about bad actors

As with most things, the more you look into it the deeper you can go to cater for every conceivable scenario. I'm going to keep it 'simple' for now. Currently looking at doing a custom authoriser for verifying a UserFront issued JWT. This is all still very new for me and I haven't researched this fully but is it possible to pass in additional parameters into the custom authoriser function? I'm thinking this could be a neat way to pass in route specific roles within the API construct itself.

You could pass that through as an env variable right?

I was thinking something like this

authorizers: {
      myAuthorizer: {
        type: "lambda",
        function: new Function(this, "Authorizer", {
          handler: "src/authorizer.main",
        }),
        resultsCacheTtl: "30 seconds",
      },
    },
routes: {
      'GET /private': {
        function: 'functions/private.handler',
      },
      'GET /public': {
        function: 'functions/public.handler',
        authorizer: 'none',
      },
      'GET /admin': {
        function: 'functions/admin.handler',
        role: 'admin',
      },
    },

Oh you meant per route hm

The other way that I can see is to have a separate authoriser for each route that has a different set of privileges... privateAuthorizer, adminAuthorizer etc.. But there's going to be a lot of repeated code here and doesn't offer much flexibility when multiple roles might be required.

@Neil Balcombe https://www.alexdebrie.com/posts/lambda-custom-authorizers/ discusses some scenarios to consider if you need a custom approach

Funnily enough, already working my way through that article.

😜

For what it's worth, I ended up doing a CustomAuthorizer that basically checks the JWT and then get the list of roles or permissions for that user from the database (or if you don't need anything granular, you can also just use cognito groups) and then pass that onto the lambda function handler. Then the handler just has a middleware/wrapper that checks against an array of permissions to make sure it's allowed to access that endpoint. The only issue I've found is because the custom auth response is cached, if you ever change someone's permissions, it may take a few extra minutes before it starts to work, but that's fine in most of my use cases anyways.