hedgedoc
hedgedoc copied to clipboard
hedgedoc
Auth of public API routes in 2.0
The authentication in the public API of 2.0 will be done by sending an auth token. The question is if we want to allow guests (without an auth token) to access some routes of the API. A pro argument for restricting it is that is not so easy to abuse but this would be possible through the private API anyway.
From my perspective it doesn't make any sense to have some routes that are unauthenticated in the private API but need a token in the public API.
So only use tokens in the public API where it's needed.
Wouldn't it make sense to just have an API endpoint to request a token, any for guest-enabled instances these tokens can be obtained without authentication?
This would reduce the amount of unauthenticated endpoints to one.
Also might have look at Matrix.org, they disabled guest access at some point, maybe they have some lessons learned written somewhere.
We could also use this to make some controller routes accessible to anonymous https://stackoverflow.com/questions/53249800/optional-authentication-in-nestjs
Rate-limiting would be greatly simplified if all requests must have a token, as we then can just use that token to identify the user and apply rate-limits per token.
If we allowed requests without a token, we would have to use the IP address to rate-limit everywhere, which is less reliable.
To allow anonymous tokens, we would have to adjust our database schema, as it currently requires a User for each token and change a few methods that currently don't handle a missing user.
After that, we have to make sure that all the other code handles res.user == null.
Isn't the idea to have a pseudo user anonymous anyway, then you could assign the access tokens to this pseudo user and remove a lot of the special handling.
Besides, you still need to rate-limit the token issuing for anonymous users by IP address. Otherwise it's trivial to break the rate-limit. So it just moves the target a bit. But generally speaking I agree that the overall API should be rate-limited by token.
This is already implemented. In the end each request of the public API must be authorized by an bearer token.