Does that work with gitea? I was able to get it working with Authentik but wasn’t able to get it working on Keycloak.

That doesn’t sound too bad, thanks for the instructions. I’ll probably give keycloak another try too.

Do you know what kind of cpu memory usage it has? I saw the newer versions are supposed to be lighter, but haven’t tested it yet.

Thanks (grazie?)! I was looking for something similar and kanidm looks great feature wise and simple to deploy!

Thanks, kanidm looks promising. I’ll try it out this weekend

Does this do it all? It seems that it holds all your users like LDAP and can auth that way too. But it can also do simple oidc integrations too? Basically just want to see if it is the all in one. Looks like it does which is why i wonder why you use oauth2-proxy in addition.

I’ve otherwise been trailing keycloak/authelia as the oidc portion and lldap/freeipa as the ldap Backend that actually holds the users. Would love to simplify if possible.

OIDC does indeed work fine too.

I use it on nextcloud and immich and a few others.

You will be much more hard pressed to find apps that support SSO and oidc than oidc that authelia is broken on.

Hmm I thought authelia could only act as an oidc provider, I didn’t think it could allow logging in through a Google account for example?

I’ll take a look at the docs again, thanks!

This. 100%

You can change the logon flow to make the username and password on the same page There is a comparability button as well on the login flow that allows bitwarden and other to auto fill correctly.

Thanks for the tips, I found the compatibility button and will try it out. I’m not sure I see how to change the username/password to be on the same page though. Do you have to create a whole new login flow?

The latest update to authelia 4.38 was a little bit cumbersome, because you hat to manually adjust the configuration. But all in all I like authelia, too.

Most of the apps I use support external authentication using popular standards (OAuth for most part). This means the clients will also support the said standards out of the box. Having a standardized authentication flow makes logging in much easier as well.

I also don’t want to deal with passwords… because I don’t trust myself to handle passwords. So before settling down on Authentik, I used FusionAuth to do OIDC via Google. Then I discovered I could do WebAuthn / Passkey with Authentik, so the portal really only ever need to know my public key, and approves access based on private keys, which are gated by my devices’ biometric features. This is way more secure than other solutions and I don’t even need to remember a password.

The one edge case I’ve encountered is a couple of apps recently transitioning to mandating authentication, but doesn’t have OIDC integration of their own. Fortunately, there’s a hidden config flag in XML that I can use to tell them that I have externally managed authentication, and I gate access to them via a middleware in my reverse proxy. As for client, my client of choice allows me to add custom HTTP headers, so I have a special “API key” kind of header that my reverse proxy looks at, which allow me to bypass authentication, so everything works nicely together.

In my mind, using the vanilla out of the box authentication feels less secure than me gating things via OIDC or middleware. This is because everyone knows they could Google for “Powered by WordPress” or similar phrase to target specific apps with known authentication exploit. However, by switching it up and using a different mechanism, the common exploit vectors might not be as effective against my deployment.

As long as it’s a web app, it’s usually fine and can provide an extra layer of security. The app does need to have some support for sso if you want it to be seamless though, without logging in twice.

Most of my services are internal only, but sometimes I want to give access to someone on the internet without also giving them VPN access. If the app doesn’t support any kind of login, having an Auth proxy in front of it really helps for that use case.

Remembering lots of passwords isn’t a big deal if you have a password manager, but not having to log in to each app separately is nice. It’s also nice to be able to put Auth in front of things that don’t support it natively.

Mostly for convenience and standardizing your security procedure. Most apps popular for self hosting now supports OIDC, so it’s no brainer to setup. On the other hand, most apps don’t support 2fa, or support it in a weird way (e.g. no recovery code). By using an identity service, you can be sure all your apps follow the same login standard you setup.

For those apps that don’t support OIDC, you can simply slap oauth2proxy in front of it and it’s done.

Making it easier for users to remember passwords leads to them using better passwords and practicing better password hygiene generally.

You can also change your password across multiple systems easily if your password is compromised.

Login is a dangerous and difficult thing to implement, are you sure that all of your services:

• Store passwords hashed and salted
• Have brute-force prevention
• Etc

It’s safer to have one service focused on that and other services can rely on that one to implement it correctly.

That’s essentially what I am doing. Everything is on the LAN by default. I have two instances of Traefik. One that runs only on internal VPN ips, and another on remote servers using public ips. So I can choose which services are accessible over lan/vpn or public (routed through a vpn to lan).

That doesn’t solve the authentication problem if I want to expose something to the internet though, or even sso inside the lan.

I was going to suggest Nginx with phpAuthRequest but your solution seems more inline with what the OP is asking for.

Thanks, I’ll take a look! It might be helpful even if I use a different idp

Authelia is a oidc provider, but does not support oidc as a provider, only local file and ldap. So it really depends on your use case

Did you move to Keycloak, or something else?

Canaille looks pretty interesting and simple too, thanks for the link!