How To Use It with SAM (Serverless Application Model)

This authorizer is somewhat configurable, and the nature of API Gateway means that the configuration happens at the use site – that is, in the template defining the service using the authorizer.

• Platform Authorizer must be configured as the 'TOKEN' flavor of authorizer. (This is the default.)
  • The identity validation expression (identityValidationExpression) should be /^Bearer +[-0-9a-zA-Z\._]*$/. This allows a request with a malformed Authorization header to be failed without invoking even the authorizer.
• A 401 UNAUTHORIZED Gateway Response is recommended, so that response authorization headers can be set correctly.
  • Don't forget response CORS headers, as well.

None of these requirements are particularly complicated, and can be configured via CloudFormation or SAM templates.

Here are excerpts from an example SAM template. This first one installs the authorizer from the Serverless Application Repository into your application.

"Authorizer": {
  "Type": "AWS::Serverless::Application",
  "Properties": {
    "Location": {
      "ApplicationId": "arn:aws:serverlessrepo:us-east-1:820870426321:applications/platform-authorizer",
      "SemanticVersion": "3.0.0"
    }
  }
}

Almost certainly choose the latest version for "SemanticVersion". Inside the "AWS::Serverless::Api" element of the template (or the global "Api"), the lambda is made an authorizer of the API:

"Auth": {
  "Authorizers": {
    "PlatformAuthorizer": {
      "FunctionArn": { "Fn::GetAtt": [ "Authorizer", "Outputs.AuthorizerArn" ] },
      "Identity": {
        "ValidationExpression": "^Bearer +[-0-9a-zA-Z\\._]*$",
        "ReauthorizeEvery": 300
      }
    }
  }
}

Now "PlatformAuthorizer" can be used in any event of type "Api".

For a service using Lambda Proxy integration, the authorizer.principalId is available on the request context to be read directly.