hey everyone, what is the best way to handle the authorization of a user based on the role he has in the db??

Use custom authorizer lambda.

mm ok great, thanks 😉

+1 for custom authorizer

I usually handle the authentication in the authorizer lambda, but do authorization inside the handler lambda, since it better knows what the user is trying to do

Right, if the logic is generic across all routes and if you don’t want to authorize on every request (ie. caching), custom authorizer makes sense. Otherwise, you can wrap the authorization logic around the Lambda handlers themselves.

Yeah if you’re able to make the authorization decision based on what the authorizor knows, better to do it there (e.g. based on route/method). Otherwise for something like graphql or authorising based on which entity is being operated on etc, has to go in the handler

@Adrián Mouly or @Frank any sample available?

@Joel Corona here are 2 examples for using Lambda authorizers: • https://github.com/serverless-stack/serverless-stack/tree/master/examples/api-auth-lambda-authorizer-iam-response • https://github.com/serverless-stack/serverless-stack/tree/master/examples/api-auth-lambda-authorizer-simple-response

Thx, I'll try!

@Manuel Villafañe If (1) your roles are static, that is you're not working with user-defined roles, (2) if you don't have tons of them, and (3) you're talking about resource authorization, the resource being what the API gateway has knowledge of like the endpoint + method, then you can also inject your roles as claims using the pre-token generation trigger from Cognito. The lambda attached to that trigger will look up your DB and shape the returned JWT accordingly. Then you simply use a JWT authorizer with the right authorizationScopes. Now, If (1) your roles are user-defined, then you'll have to use custom authorizers to fetch, inject, and authorize on the fly. You may, of course, have one single custom authorizer for your whole system, if you have a centralized role management sub-system. If (2) you have tons of roles, then by injecting them into your JWT tokens, you might be clogging all your API requests. If (3) you want to perform action or data access control, then you'll (also) need to perform fine-grained authorization in your lambda handler. You, of course, have one single custom "middleware" for authorization and have something like : *request > request validation > action authorization > data authorization > * model run * > data authorization > response validation > response* Finally, if may also want to embed some data-level access control into your model. For instance, for DynamoDB you may attach a dynamic permissions to your request to limit the access to attributes or entries : https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html

@Joel Corona does every route have unique parameters? (ie. [‘admin’, ‘user’])

yes @Frank, each route has the "roles" that are allowed for that route, i.e. they will not be repeated at that endpoint

I see. the authorizer function has access to the full event object. The route is in there I think.

And how can I modify the event per endpoint?

What are u thinking to modify?

I don't think I have explained myself correctly

So the custom authorizer can read the route, and return some context https://github.com/serverless-stack/serverless-stack/blob/master/examples/api-auth-lambda-authorizer-iam-response/src/authorizer.js#L26-L28

1 - I want to make some sort of middleware 2 - pass it an array of roles 3 - in the handler look for the user in the DB and check if it has any of the roles that I pass by argument 4 - in case it does, let it make the request, otherwise send a http 403