OAuth provider

[oplik0]

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

• Write API v3 support stateless jwt  #9429 - I'm not really sure if JWT would be preferred for the tokens, both because JWT is a kind of terrible token format that should never have gained the popularity it did and because stateless tokens are not really needed here. Current stateful API tokens can work just fine, they'd just need to be extended to include scopes in the database. But doing OAuth+JWT is fairly common, so... Maybe?
• OpenWebAuth (see FEP-61cf) - it's a protocol with a somewhat different purpose (signing in to another instance/service via the account on yours, without giving the target any permissions to take actions on the home instance), but also relating to authentication outside the service. It's also quite a bit simpler and can more feasibly be implemented via a plugin.

Community forum reference

No response

[julianlam]

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.

[oplik0]

Obviously basic read, write (and write:sameorigin for fedi compat), but something more granular would be nice.

Probably most of the scopes that would be useful:

• user scopes
  • most important part IMO - separate user read access
  • but something like mute and follow scopes would be useful too (write:mutes, read:follows etc.)
• posts/topics (could probably be a single scope)
• chat
• separate admin action scopes
  • e.g. admin:write:categories, admin:write:groups, admin:write:users, admin:write:privileges (so generally allowing an app to manage a specific aspect of the forum without necessarily giving it full admin access - use case might be something like a forum template that creates premade categories and groups, but doesn't really need any more access)
  • admin:write:settings
• flags (for some moderation tooling)
• analytics
• search
• files

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...