Implement OIDC

[m-baertschi]

This is a simple OIDC implementation. It's very basic and just logs the user in. Access control needs to be done on the IDP side.

[knadh]

Thanks @m-baertschi! I'll review this over the weekend.

[waza-ari]

Thanks for your work! Just want to advise that depending on the IDP you're using the guiding principle there might be that access control should be done on the application level (Keycloak being a prominent example). That being said, I'd rather implement a workaround in those providers than not having OIDC at all

[MaximilianKohler]

I'm curious what the use case is for this?

[waza-ari]

I'm curious what the use case is for this?

Lets say you setup listmonk for any kind of organization - whether its a company, a non-profit or anything else for that matter - they usually have their identities (user accounts) managed in one central place (usually called an Identify Provider). Could be Azure AD, could be Keycloak, could be any IdP really.

Instead of having local user accounts (which need to be properly managed, e.g. deactivated if a user leaves the org) and also for the user to have one account / password only, OIDC allows to delegate authentication (WHO is the user) to the external system. Authorisation (WHAT this user can do, e.g. permission management) can then rely on this identity.

[waza-ari]

@m-baertschi how does the API work when OIDC is implemented?

[m-baertschi]

OIDC just replaces the BasicAuth middleware if configured. I have not tested the API separately, but i will look into it. It is probably possible to check if the authorization header is present and perform basic auth.

[m-baertschi]

The API now works with the admin credentials, even if oidc is configured. The Application now checks if the basic auth header is present and then validates it.

But this also means that if the docker container is configured with environment variables the default admin login still work. To fix this, the config file should not include any credentials at all.

[kSzajo]

Could you add readme? I'd like to test it

[knadh]

@m-baertschi, apologies for the delay. The implementation looks good!

1. The coreos OIDC lib vs. https://github.com/zitadel/oidc, have you evaluated the latter? Just wanted to figure the lightest one as the coreos lib somehow adds ~300KB to the build.

2. The Settings UI for the OIDC credentials is yet to be done, right? I can work on this and add it to your PR.

[m-baertschi]

1. I have not evaluated the zitadel oidc library. But it has a lot more imports in the go.mod then the coreos lib, so i don't think it will be smaller.
2. Yes, there is no settings UI or documentation.

[m-baertschi]

@kSzajo There are 3 options you need to set. The provider is the URL of your IDP for example: https://id.example.com
The client id and secret are from you registration of the app in your idp.

Environment variable (Docker):

• LISTMONK_app__oidc__client_id
• LISTMONK_app__oidc__client_secret
• LISTMONK_app__oidc__provider

[titansmc]

So have you also implemented multi-user ? In the sense that I log in to listmonk and start writing an email, and then someone else logs in as well, would they see the email I am writing ? or it would be a totally different session?

[knadh]

@titansmc no, that's not possible without listmonk getting a built in user/permission system which it currently doesn't have.

[titansmc]

so no multi user, does it mean that everyone with login details will be able to see the email others have wrote ? So if someone writes a campain and saves it, would the rest see it?

[knadh]

I've ended up extending this OIDC implementation towards multi-user support. Will see if we can have list-based ACLs on top of it in the upcoming version.

[matmair]

@knadh are you aware of polar.sh for Open Source funding? I would like to contribute a few dollars for this PR as it will help me with my SSO-everywhere goal.

[knadh]

Thank you for the kind offer @matmair, but I'm not looking for funding. We should have multi-user + SSO support in the next release.

[knadh]

Closing this PR as the work in progress here #543 now supersedes it. Thank you for kick starting this @m-baertschi