Content
View differences
Updated by Jan Sandbrink 4 months ago
Without additional request parameters OpenProject only ever returns a WWW-Authenticate header indicating Basic as the authentication method, leaving out additional details that the Bearer response header implements.
Comparison:
```text
Basic realm="OpenProject API"
vs
Bearer realm="OpenProject API", resource_metadata="http://test.host/.well-known/oauth-protected-resource", scope="api_v3", error="invalid_token", error_description="A detailed description why the token is invalid."
```
Especially the resource\_metadata and scope are useful for clients to understand where and how to get a token. In addition to that, users sometimes see an errorneous authentication form, which appears whenever frontend code forgot to send a special request header and at the same time had an expired session.
We should follow one of two possible pathes forward:
* Respond with the header multiple times (once per authentication method supported)
* this should be supported as per spec
* possible downside: not sure how well clients support that; unintended auth forms will still show up
* Only ever respond with Bearer WWW-Authenticate, nothing else
* possible downside: Clients don't see that Basic auth would be an option
* Upside: All authentication can happen through Bearer tokens today, so it would technically not be wrong
The higher level goal is to improve compatibility with third-party clients that use a lot of auto-discovery, such as MCP clients.
Comparison:
```text
Basic realm="OpenProject API"
vs
Bearer realm="OpenProject API", resource_metadata="http://test.host/.well-known/oauth-protected-resource", scope="api_v3", error="invalid_token", error_description="A detailed description why the token is invalid."
```
Especially the resource\_metadata and scope are useful for clients to understand where and how to get a token. In addition to that, users sometimes see an errorneous authentication form, which appears whenever frontend code forgot to send a special request header and at the same time had an expired session.
We should follow one of two possible pathes forward:
* Respond with the header multiple times (once per authentication method supported)
* this should be supported as per spec
* possible downside: not sure how well clients support that; unintended auth forms will still show up
* Only ever respond with Bearer WWW-Authenticate, nothing else
* possible downside: Clients don't see that Basic auth would be an option
* Upside: All authentication can happen through Bearer tokens today, so it would technically not be wrong
The higher level goal is to improve compatibility with third-party clients that use a lot of auto-discovery, such as MCP clients.