New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth provider #12431
Comments
What scopes were you thinking would be required? I agree that the current system is a little all-or-nothing in terms of scoping, but I am hoping we would be able to support this as a plugin. |
Obviously basic Probably most of the scopes that would be useful:
This is a bit more, but after making that list and looking through the API it does feel a lot more doable in a plugin, especially since the admin settings API is fairly limited. Most of these are fortunately organized well enough to not need to maintain a very specific list... |
Description
What and why?
Currently NodeBB API only supports a very coarse cookie and static bearer key authentication schemes. This makes interacting with an instance from outside fairly difficult - attempts will at best end up with access to an entire account via a statically generated API key, and if they elect to use cookies instead it won't even be practically feasible to differentiate an automated action from a real user action outside of voluntarily provided metadata (e.g. an User Agent).
As #11580 is moving forward, NodeBB is starting to open up to the rest of the world, and especially with things like external moderation tooling (e.g. FediCheck starting to pop up, and the Fediverse seems to be, unsurprisingly, standardizing on OAuth 2.0 for authentication - so if we want to support C2S API at some point (or maybe even the somehow much more popular Mastodon API; apparently C2S clients/servers are starting to pop up tho!) supporting it will likely be a requirement (and more specifically it'd probably be a good idea to follow FEP-d8c2).
However, even outside the federated world, user-friendly authentication to a NodeBB instance may allow for more external tools and integrations beyond the plugin ecosystem.
Why not do this via a plugin though?
Well, before #8708 I'd say forking the write-api plugin and adding OAuth there would be a feasible solution. However, proper implementation would require adding scope-based authorization within the API, which means such plugin would have a fairly large scope and need to closely track API changes. Properly doing this in core should result in lack of authorization for e.g. new endpoints being at least easier to notice, and at best hard to do accidentally.
Related
Community forum reference
No response
The text was updated successfully, but these errors were encountered: