Feature Proposal

Description

serverless allows us to configure an API Gateway authorizer by referencing the methodArn this feature will allow us to execute a common authorizer a cross other deployed services. No need to redeploy a custom authorizer per service.

lists:
    handler: functions/index.handler
    events: 
      - http:
          path: lists
          method: POST
          authorizer: arn:aws:execute-api:{region}:{accountId}:{restApi}/${stage}/${method}{path}

Similar or dependent issues:

• None

Additional Data

• None

To support Custom Authorizers we need to adjust authorizer/index.js to support multiple authorizers.

We also need to develop a cognito module that will authorize the authorization information sent in a request.

This article may provide some information on how we can add support for a cognito authorizer.

Serverless will also have support for the AWS_IAM authorizer, so ideally that'd also be good to have.

I've forked the project and looking at the source now and I'd like to get your opinions. Should we add an extra parameter to authorize() authorizer/index.js or is there a way of figuring that out from the context?

Also I'm not sure if this is a bug, but the authorizer middleware passes 4 parameters to authorizer/index.js which only receives three. I think it might be a bug 😕

Also I'm not quite sure how to get the restApiId parameter which is required to validate an incoming JWT.

Hi @hassankhan thanks for looking at this. You're right it does look like a bug. Is that something you can look at while you're adding cognito support.

In regards to determining the authorizer, it should be chosen from the context. You'll need to update the config.js module to return an authoriser type. That will be added to the http context for the endpoint, which is passed into the authorizer function. This will then let you select which type of authorizer to invoke. Does that make sense?

I'm not sure how to get the restApiId either. Being a local simulation, it's not aware of a real API Gateway. Is this something that can be simulated? Can you check the JWT expiry but ignore the signature validation instead? A signature validation probably isn't required locally.