redirect endpoint returning a 302 redirect to AWS S3 - generating an auth problem

I have a download endpoint in my API which is redirecting the user to a AWS S3 presigned URL

Here is the swagger file describing my endpoint:

openapi: 3.0.0
info:
  title: My API
  description: API
  version: 2.0

servers:
  - url: myapi.com
    description: API v2.0.
components:
  securitySchemes:
    Auth:
      type: apiKey
      in: header
      name: Authorization
security:
  - Auth: []
paths:
  /download/:
    get:
      summary: Download
      description: Download
      responses:
        '302':
          description: Redirects to a location for downloading
          content:
            application/gzip:
              schema:
                type: string
                format: binary

My problem is when the SwaggerUI (version 3.14.2) it trying the endpoint it does get the redirect order, but when it tries to go the redirect location it for some reason sends the “Authorization” header to that URL although it’s not on the same domain.

This problem is causing AWS S3 to omit the following error because it’s receiving both “Authorization” header and the “AWSAccessKeyId” get parameters.

<?xml version="1.0"?>
<Error>
  <Code>InvalidArgument</Code>
  <Message>Only one auth mechanism allowed; only the X-Amz-Algorithm query parameter, Signature query string parameter or the Authorization header should be specified</Message>
  <ArgumentName>Authorization</ArgumentName>
  <ArgumentValue>Token TTTTTTTTTTTTT</ArgumentValue>
  <RequestId>RRRRRRRRRRRRRR</RequestId>
  <HostId>HHHHHHHHHHHHHHHH</HostId>
</Error>

Any idea how to solve this issue?

[shockey]

@kobymeir @MaxHo1234, upon further inspection, this is a limitation within the browser. The request is being transparently followed, with no way to control the behavior from within a web application like Swagger UI. Postman gets around this with their Interceptor extension, which is not subject to the same constraints.

I’m going to keep this open: if there’s sufficient interest, we could consider building a similar extension that allows users to circumvent browser limitations.

[kobymeir]

Hi @shockey

There is no reason to pass on the authorization headers as you have no idea where the redirect it going, thus potentially exposing the authorization token to a 3rd party that we might not want them to receive the token.

Hope that my answered helped 😃