Lemmy: OAuth (2.0)

[tentacleuno]

Is your proposal related to a problem?

Implement OAuth so, instead of the application deriving a JWT from email / password, the server does. This has obvious (substantial) privacy and security benefits. Tokens can be revoked, while an email / password combination requires a more involved approach: manually changing the password. With OAuth, the application will never know the password.

Describe the solution you'd like

An OAuth endpoint, along with clear scoped permissions. This would be a browser endpoint, with a clear button for consent. If the user agrees, they are either:

• Redirected to the redirect_uri, if provided, or...
• Returned a code in plaintext to enter into the application.

---

Please note: I have searched for this in here and I'd just like to reiterate: this is NOT about authenticating with external services.

Keywords: oauth, auth, sso, token, jwt

[dessalines]

application deriving a JWT from email / password, the server does

What's the application you're referring to?

[tentacleuno]

Applications that use the Lemmy API.

[tentacleuno]

Remember: handing out your email / password combination to random clients is a substantial security risk. OAuth can prevent that. Most projects like Mastodon and Reddit have implemented this! 😄 I'm building a client for Lemmy, but sadly I'm worried people won't trust it due to no OAuth. I actually have OAuth coded into the application. It feels wrong to have to revert code just to add insecure functionality which can easily be abused.

Since you need a legitimate use-case, let me give you one: let's say I do build this client. Someone else hosts it, minifies the build, and injects some cute listeners for the password / email fields. Who, aside from developers, would know the difference?

Another point: remember email phishing? Those random sites that ask you for your Google email & password, and call it 'Google Login'? Who in their right mind would trust some random person with their email and password, when they have been taught to do the exact opposite?

So, instead of telling people 'Yes, you need to enter an email & password specifically for Lemmy clients, nobody else does this, and your client may or may not acquire them', it would be better to get people used to using normal OAuth, and raise suspicion when a website asks for an email & password.

Anyway, I think I've made my point. This is obviously very bad for security, especially when people are building clients. 😄 Additionally, it would be possible to add support for other authentication schemes (like a Smart Card, self-hosted SSO, etc.) without forcing everyone to keep adding support for these authentication methods.

Mastodon does this really well. Firstly, you create an Application. This gives you client_secret and client_id combination. Then, you open a new tab in the user's browser (something like /oauth/acquire?client_secret=[...]&client_id=[...]&redirect_uri=[...]). When the user clicks accept, they are redirected back to the redirect_uri set in the URL.

TL;DR: not adding OAuth could allow bad actors to do some serious harm.

[asonix]

fwiw i've played with implementing an OAuth2 server in Actix Web before and can offer assistance for this (just not during business hours). I suggest taking a look at the oxide-auth crate, which does the bulk of the heavy-lifting

[Mart-Bogdan]

Hello, @tentacleuno. What kind of client is it? It's web-UI or a mobile one?

Mastodon does this really well. Firstly, you create an Application. This gives you client_secret and client_id combination. Then, you open a new tab in the user's browser (something like /oauth/acquire?client_secret=[...]&client_id=[...]&redirect_uri=[...]). When the user clicks accept, they are redirected back to the redirect_uri set in the URL.

That's strange. CLient secret shouldn't leave server of an app.

And for mobile apps/spas there are flow without secret, PKCE. But I've read about it quite a while ago, so don't remember what benefit over implicit flow it has.

[Mart-Bogdan]

I am wondering what server would handle OAuth and accept cookie/login+pass. Current lemmy-ui? Or a real static html page on the backend?

[dessalines]

I'd prefer a simple static html page on lemmy. I'll also probably need a good amount of help with this as I'm not too familiar with oauth.

[Mart-Bogdan]

This is really secure to have a static page without JS as this negates any malware inside npm libs. But this isn't a popular option, and not so user-friendly, without AJAX, lol.