OIDC single sign on

[samuk]

For front end issues, use lemmy-ui

Is your proposal related to a problem?

I manage a load of users in a Keycloak instance. I'd like to add Lemmy to our intranet offering. I want to make it easy for them to log in (and potentially ban them across all services if they misbehave on one)

(Write your answer here.)

Describe the solution you'd like

OIDC support so I could add a 'login with keycloak' button

Describe alternatives you've considered

https://webauthn.io/ would be an additional nice-to-have

Additional context

(Write your answer here.)

[Nutomic]

How is this different from OAuth? #1368

[samuk]

Similar,
"OIDC is an extension of OAuth2 that focuses on user authentication rather than user authorization. Once OIDC authenticates a user, it uses OAuth2 specifications to perform authorization."

https://www.transmitsecurity.com/blog/oidc-vs-oauth2

[dessalines]

We don't have time to work on this, but if anyone else wants to, PRs are welcome.

[derivator]

How is this different from OAuth? #1368

Just to clarify a bit:

OAuth allows a resource owner (a user) to grant an application (confusingly called client) access to a resource that they own at some service, without sharing their login credentials with the application.

In the context of #1368, the resource is the user's account on a Lemmy instance. The application could be a mobile app like Jerboa, an alternate web frontend or a bot that posts to Lemmy whenever you open your smart fridge. Think "Do you want to allow Jerboa to post to lemmy.ml on your behalf?" That's OAuth in the context of #1368.

OIDC builds on top of OAuth, but the resource you are granting access to is your identity. So in the context of this issue, #933 and #489, Lemmy would be the client application, using OAuth to ask an OIDC provider for a user's identity, so it can automatically create an account and sign them in. Think "Log in with Google".

The protocol is OAuth in both cases, but the implementation in Lemmy is very different.

[elijahnyp]

To add some additional clarity, the 'resource server' is the lemmy back-end, the application is a lemmy front-end, mobile client, etc.

The resource server 'trusts' the authorization server through signatures. OAuth is very similar to SAML in this regard. The resource server trusts that a token (including identify information) signed by the authorization server is authoritative. This trust is established by the service administrator. If the signature matches (aka signed by the private key), then it's valid on its face so the resource server (aka lemmy back-end) should create a session for the user OR create a user and then create a session.

Think of it as an introduction to a bank. You (the bank) trust me, therefore if I tell you a 3rd party is named Fred and is authorized to open an account you create an account named 'Fred' and give him access to it. Every time Fred comes into the bank (including the very first time when you don't know who Fred is), he brings with him a cryptographically signed note from me saying 'Fred is coming into the bank at this time to access his account but he may be 5 minutes early or late'. 'Somebody' walks in within that 10 minute window and presents the note. You slap a nametag on him that says 'Fred' with Fred's account number and a timestamp (the resource server's 'session') and he does what he needs to do.

Now Imagine he leaves the bank, takes off the nametag, and walks back in. He presents the same note but now the times don't match (this is a replay attack). You tell him 'hey, your note says you would arrive 20 minutes ago - go back and get a new note that's valid for this time'. Likewise, if he leaves the nametag on (session cookie), when he walks in you have your own 'tag' on him so you know who he is and how old the 'tag' is (your session timeout). It's now entirely on you to determine if you trust your own tag or if you force 'Fred' to go back and get a new 'letter of introduction' (OIDC token).

These days, supporting OIDC (OpenID Connect) is basically table stakes for mass adoption. You'll lose a certain percentage of potential users simply by not having a 'login with google' option. This is why 'login with google/facebook/apple' is ubiquitous on blogs, e-commerce sites, forums, etc.

As a final thought, implementing OIDC also reduces the risk associated with running a public lemmy instance. The objective of OIDC is to enable a consistent identity across services without compromising that identity if an individual services is breached. A "resource server" that only authorizes connections based on OIDC contains no passwords or private authorization keys that would enable an attacker to spread beyond that single resource server. In effect, the login security is out-sourced to a player with deeper pockets (like google or facebook). It also eliminates the need to maintain robust authentication schemes within lemmy since that entire layer can be delegated to dedicated projects like keycloak. Implementing OIDC would instantly provide lemmy with federated identity, webauthn, and MFA capabilities.

[samuk]

I've just noticed Kbin supports OIDC so I'll probably investigate that.

[Danacus]

Perhaps this crate could be used: https://docs.rs/openidconnect/latest/openidconnect/?

It seems to be actively maintained, and could do a lot of the heavy lifting.

[csm10495]

My terminology with SSO isn't great but here goes nothing:

Could this also support a situation where an app could allow 'authentication via Lemmy' .. sort of like using Lemmy as an SSO provider?

My rationale is kind of funny: We were talking about having local community members (but not random people) do a poll, but then realized we didn't have a way to verify that someone has an account on the given server.. or a way to verify that they only voted once. If we could 'auth via Lemmy' to a polling website like strawpoll (or insert more-friendly poll website here), we could have a way to verify that the given user has an account on a given Lemmy instance.

[derivator]

Could this also support a situation where an app could allow 'authentication via Lemmy' .. sort of like using Lemmy as an SSO provider?

@csm10495 that is more along the lines of #1368, but then Lemmy should become a full OIDC provider, and you could use scopes to restrict access so the client application only gets e.g. the username but can't post or modify any of your data.

[perillamint]

@Danacus Implemented OIDC consumer using that before, quite painless.

Lemmy just have to store the authentication results in separated table, like,

CREATE TABLE oidc_table (
  id: UUID,
  owner: UUID, ;; FKEY to the owner ID
  provider: text, ;; provider name to look up, for multiple providers
  oidc_id: text, ;; Identification ID from the OpenID Connect
);

and implement OIDC redirect endpoint and UI components to expose OIDC login to the UI.

[erlend-sh]

For reference: https://matrix.org/blog/2023/09/better-auth/

[thepaperpilot]

This issue is very important to me, and I don't know rust but I'd like to help get this implemented. For an MVP I'd rather not mess with the current ways everything is authenticated, so OIDC would just be used to obtain the JWT all the other requests then use. Frontends will handle sending the user to the idP, so on the backend side we just need the redirect endpoint. Instead of adding an entry in the table like perillament described above, I think we could just directly generate and pass along the JWT to the user. Minimal changes to support OIDC.

[thepaperpilot]

Looking into the problem a bit more, and I think implementing this issue will also resolve #1368 and #489, since all clients, mobile included, will need to use an endpoint to determine the available auth methods, and using an external auth (OIDC or just oauth) will mean logging into the app without giving the app your username and password. Although it'll still give them a token that can do anything with their account, but that will be for a proper roles system (later).

So the first thing I'm going to work on is a way to configure external auth methods in lemmy-ui, and expose them via an endpoint so clients can see them. Something like GET /auth/methods. It'll include "basic" in the list of methods, so in the future we can allow instances to disable basic auth if they want to use the other methods instead. After that I'll work on getting the full external auth flow working, and at that point I think we'll be ready for review etc. But a feature I'd like to include before that version goes out would be supporting registering users via the external auth, which means supporting users without a password.

[kerkmann]

I've written a relative simple leptos_oidc client. This solution is working with SSR and CSR out of the box. All you need to do is to add a public client into your keycloak instance. May I help you with that? :)

I can of course help you as well setting it up, also please reach out to me if there are important features missing. :)

[raskyld]

As discussions are not enabled on this repository, I guess we should go on and exchange on the Matrix server because from my understanding, IAM in Lemmy needs a complete refactoring and will have severe impact on users 😬
I am not familiar enough with Matrix but could we have a channel dedicated to the IAM area? (like SIGs in Kubernetes) cc @dessalines @Nutomic you are probably the ones with the right to create channel on Matrix or maybe you have an opinion on how we should structure the work around IAM?

[thepaperpilot]

My PR will not have a severe impact on users. It's intentionally limited in scope to be as easy to implement both server-side and client-side, and is ultimately just a new way of obtaining the auth token already used for all the rest of the requests. (Although I don't have a timeframe for my PR, because I'm still learning Rust/lemmy). But if the discussion is moving to matrix, I'm keen to participate.

[raskyld]

Sorry I was too ambiguous, what I meant is:

There are a lot of issues on IAM on the repository and I am not sure all users are on the same wavelength because the IAM ecosystem is vast and complex, every spec use different terms so the first step would be to make users feel confident with terminologies like:

1. https://openid.net/specs/openid-connect-core-1_0.html#Terminology
2. https://auth0.com/docs/glossary
3. https://datatracker.ietf.org/doc/html/rfc4949

Then, we should make sure we want to same thing:

1. Make Lemmy an IdP (or OP in OIDC terms)?
2. Make Lemmy accept claims coming from external issuers (what @samuk seems to really ask there).

Just re-structuring a bit the issues and orchestrate the work being done on IAM!

I am learning lemmy aswell as I am pretty new to the codebase :)
Would be happy to collaborate and chat with you on Matrix!

[Nutomic]

@raskyld There is a dev chat on Matrix, or the /c/lemmy community also works. But its good to keep discussions on Github so they can easily be found in the future.

[Mrs-Feathers]

as a sysadmin of a community that uses authentik to give SSO access to all of our community members, i remind people here how important it is for communities to give their members easy (only one account needed to access everything, via OIDC and SAML and other SSO methods or even user object databases like LDAP).. because we wanna share the fediverse with our members. mastodon supports OIDC and i hear MissKey supports it now and i know its not a big thing in the fediverse to have OIDC, but on the horizon is a future of using the fediverse to get away from twitter and facebook. inexperienced users are looking to us, community leaders litterally everyone here who is trying to set up lemmy for their own use or group to be able to give them access. and with OIDC you can easily give them access to nextcloud, mastodon, and other community tools that are becomming more and more intune with the fediverse. i didn't know it, but nextcloud is federated now. theres so many options that its reasonable that most people who host lemmy are also hosting something else. being able to join apps together via OIDC or SAML are important to userfriendliness.

the bottom line is that it can only truely help the fediverse by getting people to move over from reddit and twitter and all that because it helps us admin focus on userfriendliness and ease of access.

this is my message of support for OIDC in lemmy.