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.
### QA Notes
A thing that could be checked is that the application still works (as) well (as before) in places that use the API, especially also in the cases where you logged out in another tab.
A big nono would be to see a browser pop-up asking you to enter a username and password.
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.
### QA Notes
A thing that could be checked is that the application still works (as) well (as before) in places that use the API, especially also in the cases where you logged out in another tab.
A big nono would be to see a browser pop-up asking you to enter a username and password.