Repository navigation
Accept dashboard API tokens in Authorization: Bearer, and let users set token expiry #57
Description
Context:
I had today conversation with Antonio on possibility to integrate ThatOpenPlatform with external applications people develop using ThatOpenEngine. They could potentially integrate platform CDE and allow their developed apps to read .frag files form CDE or put some files there too.
I did small, local and private test using platform's dashboard API key and such integration is rather easy, as it allows to pull files from CDE. I am now aware that such integrations will be subject of separate terms of use and rules how to allow them, but my test has revealed potential improvement for API:
Current state:
- Dashboard API tokens only work as a ?accessToken= query parameter. The same token sent as Authorization: Bearer gets 401. For example, on GET /api/built-in//bundle: no auth returns 401, ?accessToken= returns 200, and Bearer returns 401.
- These tokens also don't expire: the tokens I have tested carry no exp claim, platform also does not allow to set it.
Why this matters for potential 3rd party integrations
- No tokens in URLs: 3rd party apps run on servers with access logs, reverse proxies, monitoring and error trackers, and URLs end up in all of them (query param will be treated as part of URL and logged)
- Standard: HTTP clients, API gateways and server frameworks expect the token in the header as a standard. The query form needs custom handling everywhere.
Proposal:
a) non-breaking:
Accept dashboard tokens in Authorization: Bearer in addition to ?accessToken=. Nothing breaks: the CLI, the Revit/Rhino plug-ins and published cloud components keep using the query parameter until they update.
b) switch to bearer token (breaking, if all of these Revit plugins integration and others uses api key in query param).
PS: I also propose to set up some private channel for reporting security related questions or issues. Thanks!
Activity
DigitalDwight commentedon Oct 8, 2026
We're hitting the same thing on @thatopen/services 0.19.0, where it now blocks the CLI as well as direct API calls. The 0.19 CLI sends the dashboard token only as
Authorization: Bearer, sothatopen login,thatopen publish, the beta npm credentials andthatopen mcpall fail with a token the query form accepts.The token is a dashboard API token (Data > API Tokens) with every Apps, Components and Storage permission ticked and no URL restriction. Against https://platform.thatopen.com:
GET /api/item?itemType=APP&accessToken=<token>returns 200 and lists our apps.GET /api/item?itemType=APPwithAuthorization: Bearer <token>returns 401,{"statusCode":401,"message":"Unauthorized"}.GET /api/npm-registry/credentialsis the same, 200 on the query form and 401 on Bearer.thatopen mcp(serverthatopen-platform0.19.0) starts and listsplatform-statusandsend-app-command, butplatform-statusreturnssubscribed: false, error: Unauthorized. That path sends the token in the Socket.IO auth payload rather than as Bearer, so it looks like the MCP channel refuses the token too.We get the same result with a token made on 26 Sep and a fresh one made on 7 Oct.
docs/platform-token.mdanddocs/ai-quickstart.mdin 0.19.0 describe Bearer as the main form and the query string as legacy. The quickstart also says to tick the "API" permission when creating the token, but the Edit Token dialog only offers Apps, Components and Storage, so there is no API permission to tick.Two questions:
If it helps, we can test a fix on our side as soon as one is deployed.