oidc VS lldap

Zitadel OIDC library code is very well-writen and informative.

Highly encourage everyone jump into source code and explore how IntrospectionResponse struct work with all related code around

https://github.com/zitadel/oidc/blob/main/pkg/oidc/introspec...

// IntrospectionResponse implements RFC 7662, section 2.2 and

// OpenID Connect Core 1.0, section 5.1 (UserInfo).

// https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2.

// https://openid.net/specs/openid-connect-core-1_0.html#Standa....

type IntrospectionResponse struct {

I started with https://github.com/zitadel/oidc/tree/main/example/server/storage

oidc: github.com/zitadel/oidc (certified by OIDC)

I had to set up a OIDC server so our website could act as OIDC provider, and was really surprised how hard that is to do if you simply need the most basic setup. In fact it would seem that everybody would just keep a Keycloak or whatever— in their cluster and would keep it up-to-date with whatever user schema they would have in their app. This felt like too much work for me (I didn't want to maintain a whole extra service to just be able and provide a couple Oauth scopes from our API back-end.) so instead I went on and implemented the server directly in our app using https://github.com/zitadel/oidc. In fact this was the only fully-functioning OIDC implementation in Go that I could just plug in and make it work. So big props up to the Zitadel guys, the only worry would be from my side that the server implementation could be more generic and could rely on a set of interfaces that the users would be able to implement easily, without having to import a bunch of code from 'examples/server' like we have to do at the moment?

I just wanted to spread the word, that we moved the library to a new home in the ZITADEL GitHub organisation to ease some of the confusion around the name of the company (CAOS) and the project (ZITADEL).

But to ease the pain of this we release personal access tokens in March and are currently prepping to support client credentials as well, thanks to a contribution.

Good to hear, I think it'll make many users happy. For me, I've migrated back to Authelia. I moved to authentik because at the time Authelia had no user management. After all of authentik's sharp edges, I've found lldap[0], and was able to implement a pilot in a few hours. I haven't looked back, since everything was converted.

[0]: https://github.com/lldap/lldap

I wrote LLDAP (https://github.com/lldap/lldap) after struggling to install and configure openLdap on my homelab.

I've recently installed and configured LLDAP (Lightweight LDAP) - More details here if you've never heard of it before: GitHub - lldap/lldap: Light LDAP implementation

I've an LLDAP instance running to make managing users easier.

I'm trying to integrate LDAP into my small homelab but I'm extreme noobie in it. So far I've tried: 1. OpenLDAP - not so resource heavy but I found it difficult go get working correctly with NextCloud, Keycloak and Jellyfin. Maybe someone could recommend an easy to follow guide? 2. LLDAP - honestly it's almost prefect. Nice clean UI, great guides how to setup with everything I need, but it's a read-only LDAP, so I cannot create or manage users with Keycloak or NC, that's about the only downside and probably bugs me more than it should. 3. 389ds - has everything I need (and probably some more), super easy to setup with this guide but the elephant in the room is that it uses 700MiB of RAM (whereas LLDAP uses only 7-8MiB). That's a big difference which really makes me question whether I want to use this particular solution.

Note that if you want to use KeyCloak for the OpenID but want to still have a LDAP source of truth, you can use LLDAP + KeyCloak together, with LLDAP as the source of truth and KeyCloak giving you the fancy features: https://github.com/lldap/lldap/blob/main/example_configs/key...

To be fair, their respective documentations (here and here) are pretty comprehensive.