mcp-audits/audits/atlassian/README.md at main · korrel-dev/mcp-audits · GitHub
//blob/show" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//blob/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
korrel-dev
mcp-audits
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
FilesExpand file tree
main
/README.md
Copy path
Blame<br>More file actions
Blame<br>More file actions
Latest commit
History<br>History<br>History
203 lines (171 loc) · 9.52 KB
main
/README.md
Top
File metadata and controls<br>Preview
Code
Blame
203 lines (171 loc) · 9.52 KB
Raw<br>Copy raw file<br>Download raw file
OutlineEdit and raw actions
Atlassian's MCP server: no RFC 9728 discovery path resolves
Audit 04. Atlassian Remote MCP Server. 2026-05-18.
Atlassian's remote MCP server at https://mcp.atlassian.com/v1/sse<br>returns a WWW-Authenticate: Bearer challenge on unauthenticated<br>requests, which is what RFC 6750 requires. The challenge does not<br>carry the resource_metadata parameter RFC 9728 §5.1 defines for<br>PRM advertisement, and neither well-known URL form RFC 9728 §3.1<br>specifies returns anything but 404. A conformant client following<br>the spec's discovery chain reaches a dead end on the first probe.<br>Downstream of that, the audit cascade short-circuits: probes for<br>Authorization Server metadata, Dynamic Client Registration, PKCE<br>enforcement, and token hygiene cannot run because there is no AS<br>to discover. This is the fourth shape in the series and the<br>first where the load-bearing question is whether discovery works<br>at all, not how its outputs behave.
This is the fourth in a weekly series auditing remote MCP servers<br>against the OAuth 2.1 authorization requirements of the Model<br>Context Protocol specification. Audit 01<br>looked at GitHub, where compliance rested on pre-spec OAuth<br>infrastructure. Audit 02 looked at Linear,<br>where new infrastructure tripped on RFC 7591 §5. Audit 03<br>looked at Supabase, where split-host architecture cleared the<br>discovery and AS-metadata bars but the registration endpoint<br>inherited the same §5 gap as Linear. Atlassian is the fourth<br>shape: a server that emits a Bearer challenge and stops there.
All findings link to raw HTTP evidence committed in<br>evidence/. Methodology is documented in<br>METHODOLOGY.md.
What Atlassian got right
Unauthenticated requests get a 401 with a Bearer challenge.<br>A POST to https://mcp.atlassian.com/v1/sse with no Authorization<br>header and a minimal MCP initialize payload returns:
HTTP/1.1 401 Unauthorized<br>WWW-Authenticate: Bearer realm="OAuth", error="invalid_token",<br>error_description="Missing or invalid access token"
RFC 6750 §3<br>requires that the resource server respond with a WWW-Authenticate<br>header on unauthenticated requests and that the auth-scheme be<br>Bearer. Atlassian's edge returns both. Out of the 14 probe steps<br>in the audit, this is the one that runs cleanly. It is also the<br>only one that does.
Evidence: evidence/01-discovery.http
What's missing
Two findings. The first is the load-bearing one; the second has<br>appeared in every audit in the series so far.
No RFC 9728 discovery path resolves. The Bearer challenge<br>above carries no resource_metadata parameter, so the RFC 9728<br>§5.1 advertisement vector is unused. RFC 9728 §3.1 specifies the<br>well-known URL retrieval path a client derives from the resource<br>identifier itself. The section covers two cases: when the<br>resource identifier has no path component, the request goes to<br>the host-rooted form /.well-known/oauth-protected-resource;<br>when the identifier contains a path or query component, "any<br>terminating slash (/) following the host component MUST be<br>removed before inserting /.well-known/ and the well-known URI<br>path suffix between the host component and the path and/or query<br>components."
The Atlassian MCP endpoint is https://mcp.atlassian.com/v1/sse,<br>which contains a path component. A conformant client therefore<br>queries the path-insertion form first:
GET /.well-known/oauth-protected-resource/v1/sse HTTP/1.1<br>Host: mcp.atlassian.com
Response: HTTP 404, body Not Found. The top-level form<br>(/.well-known/oauth-protected-resource) also returns 404.<br>Both are served by AtlassianEdge, so the 404s are reaching<br>Atlassian's infrastructure rather...