Auth Issues and Feature Requests in HttpApi

[chrisoverzero]

Description:

I apologize, I don't know where the boundary between SAM issues and API Gateway v2 issues is, so some of this may be on their side of the line.

1. "openIdConnect" Type Authorizer Is Not Created

Given:

OpenIdAuthorizer:
  IdentitySource: $request.header.Authorization
  JwtConfiguration:
    audience:
    - #audience#
  OpenIdConnectUrl: https://#provider#/.well-known/openid-configuration

...no authorizer is created. It validates, and the transform looks reasonable:

"securitySchemes": {
  "OpenIdAuthorizer": {
    "type": "openIdConnect",
    "x-amazon-apigateway-authorizer": {
      "jwtConfiguration": {
        "audience": [
          "#audience#"
        ]
      },
      "identitySource": "$request.header.Authorization",
      "type": "jwt",
      "openIdConnectUrl": "https://#provider#/.well-known/openid-configuration"
    }
  }
}

...but I couldn't say whether it's right or wrong.

2. Protected Route Fails to Accept Bearer Token

Given an "Authorization" header like Authorization: Bearer T0k3n, a protected route responds with a "WWW-Authenticate" header like:

WWW-Authenticate: Bearer scope="" error="invalid_token" error_description="tokenstring should not contain 'bearer '"

This is incorrect. It should contain such a prefix. (I think I know which library produced this error message, and the header value should be split into scheme and parameter before attempting decoding.)

3. Authentication Failures Cannot be Customized

Given no "Authorization" header, a protected route responds with a "WWW-Authenticate" header like: WWW-Authenticate: Bearer. Which is a great step up from API Gateway v1! But there appears to be no way to customize what comes after "Bearer " for such a response. Something as full-blown as Gateway Responses may not fit the API Gateway v2 spirit, I get. But maybe a "Challenge" property? I'm no expert; something-something VTL?

A template for recreation.

---
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: A sample for recreation.
Globals:
  HttpApi:
    Auth:
      Authorizers:
        OpenIdAuthorizer:
          IdentitySource: $request.header.Authorization
          JwtConfiguration:
            audience:
            - #audience#
          OpenIdConnectUrl: https://#provider#/.well-known/openid-configuration
  Function:
    Handler: index.handler
    Runtime: nodejs10.x
Resources:
  Closed:
    Type: AWS::Serverless::Function
    Properties:
      InlineCode: |-
        exports.handler = async () => ({
          statusCode: 200,
          body: JSON.stringify('You are authenticated!')
        });
      Events:
        Get:
          Type: HttpApi
          Properties:
            Method: GET
            Path: /closed
            Auth:
              Authorizer: OpenIdAuthorizer
  Open:
    Type: AWS::Serverless::Function
    Properties:
      InlineCode: |-
        exports.handler = async () => ({
          statusCode: 200,
          body: JSON.stringify("It's wide open!")
        });
      Events:
        Get:
          Type: HttpApi
          Properties:
            Method: GET
            Path: /open

[keetonian]

No worries, and thanks for posting this! The ApiGateway HttpApi resource is still in a Beta, so there could be issues on both sides that need to be resolved. I'll pass this along to the APIGW team and see what they say.

[keetonian]

Found it. It's a SAM issue with the openapi implementation. securitySchemes needs to be nested under components.

[keetonian]

This one's on me, it (oddly) deploys fine, which is how it got past me. PR submitted with a fix.