Swagger UI Authorize Not Sending the Bearer Token

Swagger UI adds an Authorization header only when a security requirement in the spec applies to the operation you execute. Clicking Authorize and entering a token stores the token, but if the operation does not reference the security scheme, the request goes out without it. We tested nine spec setups in Swagger UI 5.33.1 and recorded the header the server received. Five of them sent no header. In three of those the spec never asked for one, and in the other two a mistake in the spec broke the connection.

What we tested

Each setup was a one-operation OpenAPI 3.0.3 spec that called a local server. We stored the token the way the Authorize dialog does, through Swagger UI's preauthorizeApiKey method, then clicked Try it out and Execute in the page and logged the headers on the server. The server allowed the Authorization header in its CORS settings, so a missing header here is never a CORS side effect. Swagger UI 5.33.1, Chrome 152.

What each result means

A scheme that is defined is not a scheme that is applied

Setups B and C both declare the bearer scheme and show an Authorize button, and both sent nothing. In OpenAPI, components.securitySchemes only describes the available schemes. A request carries credentials when a security requirement references a scheme, either in a top-level security list that covers every operation or in the security list of one operation. Setup C shows the second case: only /star had a requirement, so executing /full sent no header, which is correct. The Swagger bearer documentation shows both forms:

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

# Applies to every operation
security:
  - bearerAuth: []

# Or applies to one operation
paths:
  /orders:
    get:
      security:
        - bearerAuth: []

An empty security array makes an operation public

In setup D the document had global security, yet the operation sent no header. The operation set security: [], which is the documented way to remove a top-level requirement. The OpenAPI 3.0.3 specification says: To remove a top-level security declaration, an empty array can be used. If an endpoint you expect to be protected sends no token, search the operation for an empty security list before you suspect Swagger UI.

The requirement must name the scheme exactly

In setup E, both operations showed padlock icons, which suggests they are protected, yet the server received no header. The global requirement named bearer, while the scheme was defined as bearerAuth. The OpenAPI Specification requires every name in a security requirement to correspond to a scheme declared under components. Swagger UI still showed the padlocks and attached no header. A padlock tells you a requirement exists. It does not prove a header will be sent.

Bearer scheme or apiKey scheme decides what you type

With type: http and scheme: bearer (setup A), we entered abc123 and Swagger UI built Authorization: Bearer abc123 on its own, so enter the raw token. With type: apiKey in the Authorization header (setups F and G), the header carries exactly what you type: abc123 produced Authorization: abc123, and Bearer abc123 produced Authorization: Bearer abc123. An API that expects Bearer rejects the first form. If your API expects Bearer, prefer the http scheme so the prefix is added for you. Setup H shows that scheme: Bearer with a capital B also worked in 5.33.1. The specification points to the HTTP authentication scheme registry for this value and the Swagger examples use lowercase, so use lowercase to stay consistent.

Swagger 2.0 keys do nothing in an OpenAPI 3 file

Setup I put securityDefinitions, the Swagger 2.0 key, in an OpenAPI 3.0.3 file. Swagger UI showed no Authorize button and sent no header. OpenAPI 3 reads schemes from components.securitySchemes. This is easy to do when you convert a Swagger 2.0 file by hand and change only the version line. Swagger vs OpenAPI shows the old and new security syntax side by side.

Confirm the header leaves the browser

curl -i https://api.example.com/orders \
  -H "Authorization: Bearer $TOKEN"

Common reasons for a 401 with a header present are an expired token, a token issued for a different audience, and an API that expects another scheme such as Token or Basic. The bearer token glossary entry and the OpenAPI authentication example show how the pieces fit together.

When the Authorization header makes the request fail

Adding an Authorization header turns a plain GET into a preflighted request. If the server does not list authorization in Access-Control-Allow-Headers, Chrome blocks the call and Swagger UI shows Failed to fetch, even though you set the token correctly. In our separate CORS test, a server with Access-Control-Allow-Origin: * blocked every request that carried an Authorization header. If your symptom is an error and not a missing header, read Swagger UI Failed to Fetch: causes and fixes.

Check your token and spec in APIForge

APIForge reads security the way the specification defines it. For each operation it uses that operation's own security list when one exists, including an empty list, and otherwise the top-level list. In the API testing workbench, the Run API panel then shows either "The spec asks for:" with the scheme, or "The spec declares no security for this operation." That message corresponds to setups B, C and D above, and to setup E, where the requirement names a scheme that does not exist.

You can still send a token to any operation. Enter a workspace default token, which APIForge sends as a Bearer token on every request that has no other auth and no Authorization header, or set auth on a single request. We sent a bearer token through APIForge's proxy to our test server and it arrived as Authorization: Bearer abc123. That separates a spec problem from a server problem: if the call succeeds in APIForge, the API accepts the token, and the fix belongs in the spec. For the larger picture, see API security best practices.