RFC: Get rid of JWTs

[RemiBardon]

Tip

TL;DR: Read only what's bold.

Context

After a long discussion with @Jurek in #dev-pod on 2024-07-26, I continued thinking about how we handle authentication and authorization in Prose and how we could improve it.

@Jurek's argument was that we could simply use Prosody's OAuth 2.0 module directly instead of having our own token system. To that I answered that we didn't do it for the following reasons (I added more details here):

• We don't want the Prose Pod API to be tightly coupled to a specific XMPP server, as we might want to allow users to use a different XMPP server other than Prosody if they want to in the (distant) future.
• The Prose Pod API has its own role-based authorization and will have more granular access control in the future.
  • This means the Prose Pod API has to be the source of truth for API requests authorization.
• For now we don't scope Prosody OAuth 2.0 tokens to specific actions, which means the Prosody token has more privileges than the Prose Pod token.
  • While no one should be able to access the Prose Pod Server's HTTP interface directly, if a malicious user manages to do it the Prosody token could be used to bypass some Prose Pod API authorization logic.
• The Prose Pod API doesn't —and will never— store user credentials or access tokens. This means we have to send the Prosody access token to the user so they can store it on their end (i.e. include it in the HTTP Bearer token).
• Prose Pod API roles are stored in its database and not in the JWT¹, which means the Prose Pod API needs to know who a token belongs to. As it doesn't store Prosody access tokens, it has to send the user's JID along with it. The token returned by mod_http_oauth2 in fact contains the user's JID, but that's just an implementation detail and we should not rely on it.
• To avoid tampering of the user's JID, we use signed JWTs.
• To avoid "leaking" the Prosody access token, we planned on encrypting the JWTs.
  • When exploring this I realized that it made packaging harder as the only crate I found for it depended on OpenSSL.

Now here is what made me realize we could do differently:

• The Prosody access token could not be used for privilege escalation, as it uses Prosody's permissions system. This means we could send it unencrypted to the user.
  • Note that this is true only if all the modules we use perform authorization checks using mod_tokenauth, and not implement a custom logic.
    • mod_admin_rest, which we use for non-XMPP actions (e.g. reloading Prosody), was created before Prosody's permissions system and mod_tokenauth. I've already proposed that we move away from the unmaintained mod_admin_rest and create a brand new "module-agnostic mod_admin_rest" with modern role and permissions management.
• We configured Prosody's OAuth 2.0's access tokens to expire after 3 hours (with no refresh token), which means the likelihood of it being exploited is very low.
• We could still encrypt the Prosody access token if we wanted to, with a key only known to the Prose Pod API.
  • We'd either have a static key defined in the environment variables, or one that's created at runtime when the Prose Pod API starts. In the latter scenario, sessions would be lost when restarting the Prose Pod API, but @Valerian said it's acceptable (and common). We wouldn't want to implement some logic to restore those sessions, as it would mean storing the private key somewhere, potentially introducing a vulnerability.
• OpenID Connect (OIDC) has a UserInfo Endpoint, which could be used to retrieve the user's JID from an OAuth 2.0 access token.
  • mod_http_oauth2 supports OpenID Connect's UserInfo Endpoint. It returns the user's JID.

What I suggest

Since OIDC's UserInfo Endpoint can be used to derive a user's JID from an OAuth 2.0 access token, we have no reason to bundle the Prosody access token in a JWT. Therefore, I suggest (credits to @Jurek) that we send Prosody's access token, unencrypted, as the HTTP Bearer token instead of a custom JWT. To get the user's JID when receiving a token, we query Prosody's OIDC UserInfo Endpoint. The rest of Prose Pod API's authorization logic remains unchanged.

Benefits

• No need to define a JWT signing/encrypting key in the environment variables.
• We can get rid of JWT-related libraries.
  • Which means we don't need OpenSSL.
  • And the attack surface is smaller (no vulnerability introduced by JWT or its libraries).
• Since OAuth 2.0 exposes standard routes, we wouldn't need to write and maintain yet another adapter when adding support for a new XMPP server.
  • That won't be frequent anyway.
• We don't have to make sure Prose Pod API and Prosody access tokens have the same lifetime, as only the latter is used.
  • Which means one source of truth for expiry and no unexpected situation where one token is valid and not the other.
• We could leverage all of mod_http_oauth2, which means:
  • We could use a different login method that's not password-based.
    • We may even be able to "Log in via Prose"! (I don't know if that's feasible, but I don't see why it couldn't be possible.)
  • We could easily support 2FA if mod_http_oauth2 does.
  • We could expose Prosody's OAuth 2.0 UI if we need, or tweak it to make our login screen out of it.

Drawbacks

• We need to make at least one request to the XMPP server for every request to the Prose Pod API.
  • Which is okay because the XMPP server is (in case of a Prose Pod) on the same machine and able to support a heavy load of requests (it's used for IM in large teams).
• The Prose Pod API couldn't work with an XMPP server which does not support OAuth 2.0.
  • Prosody and ejabberd support it (and likely others, we haven't checked).

Footnotes

1. To avoid needing a log out/log in to apply the new role, and avoid potentially keeping a role with more privileges for the remaining lifetime of the JWT. ↩

[RemiBardon]

MattJ just submitted XEP-xxxx: OAuth Client Login
, I don't have time now but it might be worth taking a look at 👍