Expose HTTPS authorization and token endpoints

This check verifies that your authorization server metadata names an authorization_endpoint and a token_endpoint, and that both are absolute https URLs.

Check id endpoints. Results:

pass fail skipped

Why it matters

Sign-in needs two URLs, and agents take both from the authorization server metadata. The authorization endpoint is the page the user’s browser opens to sign in and approve access. The token endpoint is where the agent exchanges the authorization code for an access token, and later refreshes it. Nothing about your server is hard-coded in an agent, so if either field is missing the agent has nowhere to go and the sign-in never starts.

• ChatGPT names authorization_endpoint and token_endpoint among the fields that must be correct: they are the URLs it needs to run the authorization code flow with PKCE end to end (OpenAI: Authentication).
• Claude fetches the authorization server’s metadata to find its /authorize and /token endpoints (Claude: Lazy authentication).
• The MCP authorization specification requires every authorization server endpoint to be served over HTTPS (Communication security). Codes and tokens pass through these endpoints, so a plain http URL would expose them.

What MCP Tower checks

1. MCP Tower reads the authorization server metadata that the authorization server metadata check found and validated.
2. It looks at two fields, authorization_endpoint and token_endpoint. A field fails when it is missing, empty, not an absolute URL with a host, or not https.
3. If both fields are good, the check passes. If either fails, the check fails and the message lists every field that failed, in alphabetical order.
4. If discovery stopped earlier, the check is skipped with the reason of the step that stopped it.

A failed endpoints check means MCP Tower does not offer Sign in to scan, because sign-in cannot start without both URLs.

Results

Status	Message	Meaning	Fix
pass	Authorization and token endpoints are present.	Both fields are absolute https URLs.
fail	Missing or not https: <fields>.	<fields> is authorization_endpoint, token_endpoint, or both, comma-separated.	Publish both endpoints
fail	Missing or not https: <fields>.	The field is present but uses http, or is a relative path.	Use absolute https URLs
skipped	Needs the protected resource metadata.	Discovery stopped at protected resource metadata.	Fix that check first
skipped	Needs an authorization server.	Discovery stopped at authorization servers.	Fix that check first
skipped	Needs the authorization server metadata.	Discovery stopped at server metadata.	Fix that check first
skipped	Needs valid authorization server metadata.	The metadata’s issuer did not match; see server metadata.	Fix that check first

The next step for the failure is: “Publish <fields> as https URLs in the authorization server metadata.”, with the fields joined by “and”. For example: “Publish authorization_endpoint and token_endpoint as https URLs in the authorization server metadata.”

How to fix

An endpoint is missing

1. Fetch your authorization server metadata (see Check it yourself) and note which of the two fields is absent.
2. In your authorization server’s settings or code, add the missing field to the metadata document. Most authorization servers generate the document from their own configuration. RFC 8414 lets a server leave authorization_endpoint out when it supports no grant that uses it, so look for the setting that enables the authorization code grant.
3. Make sure the URL in the document is the one that actually serves the endpoint, then scan again.

A metadata document that passes:

https://auth.example.com/.well-known/oauth-authorization-server

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"]
}

An endpoint is not an https URL

1. Replace any http:// URL with its https:// form, and serve the endpoint over HTTPS with a certificate that public clients trust.
2. Replace a relative path, such as "/token", with the absolute URL, "https://auth.example.com/token". RFC 8414 defines these fields as URLs, and MCP Tower treats a value without a scheme and host as missing.
3. If your authorization server runs behind a load balancer or reverse proxy that terminates TLS, configure it to build URLs from the public scheme and host, for example by trusting the X-Forwarded-Proto and X-Forwarded-Host headers the proxy sends.

Caution

The endpoints may live on a different host from the issuer, but every one of them must be https. Agents call them from their own servers, so they must also be reachable from the public internet.

Check it yourself

Fetch the metadata and print the two fields:

curl -s https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{authorization_endpoint, token_endpoint}'

The problem is fixed when both are absolute https URLs:

{
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token"
}

A null means the field is missing. If your issuer has a path, use the metadata URL that the server metadata check reported as found. Then select Scan again on the server’s page.

References

• RFC 8414 §2: the authorization_endpoint and token_endpoint metadata fields
• RFC 6749 §3.1 and §3.2: the authorization and token endpoints, and their TLS requirement
• MCP authorization 2026-07-28: Communication security
• OpenAI: Authentication, “Publish OAuth metadata from your authorization server”
• Claude: Lazy authentication, “Serve the discovery documents”