3

I have a question regarding the way Http API gateways validate jwt signatures. I use a cognito user pool hosted in eu-west-1 as an identity provider/ token issuer. And I have an Http API gateway deployed in eu-west-1 and in us-east-1. Im using SAM to set things up, and the api part looks as follows:

HttpApi:
   Type: AWS::Serverless::HttpApi
   Properties:
      DisableExecuteApiEndpoint: true
      StageName: !Ref StageName
      DefinitionBody:
         'Fn::Transform':
            Name: AWS::Include
            Parameters:
               Location: api.yaml
      Auth:
         DefaultAuthorizer: OAuth2Authorizer
         Authorizers:
            OAuth2Authorizer:
               IdentitySource: $request.header.Authorization
               JwtConfiguration:
                  issuer: https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_xxxxxxxx
                  audience:
                     - xxxxxxxxx

Everything works fine, however when I did some performance testing I found that adding authorization to a route hugely increases latency. The latency for the api hosted in eu-west-1 increases from 75ms to 100ms, but the latency for the api hosted in us-east-1 increases from 160ms to 550ms (tests are run from the Netherlands results are averages for over 50 calls per test). These results seem to indicate that to validate the jwt bearer token in the Authorization header, the api gateway makes a call to the .well-known/openid-configuration endpoint of the issuer, which is in eu-west-1, for every single request. My knowledge on Oauth is limited but I thought the .well-known/openid-configuration needs to be checked only periodically, so the api gateway can validate tokens without making an extra network call. Im not sure where to go from here, because I dont know if this is just how things work, or if this is in Oauth thing, or if its something else entirely. Any feedback would be much appreciated.

1 Answer 1

4

The authorizer will make at least occasional calls to Cognito, to get the token signing public keys from the JWKS endpoint. The authorizer returns a policy document and you should also be able to configure an option for authorization caching, so that subsequent API calls with the same access token avoid calls to the authorization server.

An authorizer is not the only option and it is also possible to do the JWT access token validation and claims based authorization within each lambda. This helps to ensure that a malicious lambda cannot access unauthorized data. My Serverless API code sample follows this approach and uses DynamoDB to cache the JWKS.

Sign up to request clarification or add additional context in comments.

1 Comment

Thanks for your anser. Sounds solid. However it seems that for an OAuth2Authorizer with JwtConfiguration, as in my SAM template above, there is no caching option. I do see the option in the console for lambda authorizers, however the option just isnt there for jwt configuration. So it seems that I will have to create a lambda authorizer to get caching and reduce the calls to the jwks endpoint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.