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 Answers1

3

The authorizer should make occasional calls to Cognito, to get the token signing public key from the JWKS endpoint.

In the AWS console you then need to ensure that Authorization Caching is enabled under API Gateway / Authorizers, and that it points to the HTTP Authorization Header as a key to cache by. This will ensure that subsequent calls with the same access token do not cause Cognito lookups. At least I would hope that the OAuth2Authorizer works like that - it would be unusable otherwise.

RESOURCES OF MINE

I have some stuff on this that might help you to better understand the mechanics:

My case is a little different since I'm using the REST endpoints (as opposed to HTTP) and also implementing a custom authorizer. Hopefully you can avoid this since it is pretty unpleasant. It is worth understanding that a policy document is the mechanism that makes result caching work.

FUTURE

The authorizer mechanism in AWS is pretty limited, eg it does not work with secure cookies. I therefore expect to update my code to do the OAuth work within each lambda, along with a separate cache.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • 1
    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. – Henk-Jan Uijterlinde Sep 29 '21 at 13:34